I’ve been thinking a lot lately about Scrum patterns. To that end, I’ve drafted a conceptual model, which is depicted in the below image. (You may want to click the image twice to see a bigger view of it)

“Sprint Progress Monitor” is my term for what used to be called the “Sprint Burndown.” In the 2011 Scrum Guide, Sprint Burndowns were no longer required but some way of monitoring sprint progress, via summing the remaining work, was still required. In the Scrum Guide, it is made clear that these practices can be implemented using several techniques, and “techniques may vary” from team to team. So, this is what inspired me to use the term “Scrum Technique Pattern.” A Scrum Technique Pattern(STP for short) implements the intentional gaps left by the Scrum Guide. Teams can inspect and adapt their technique patterns, while still fulfilling the Scrum framework. Said another way, there are intentional “variation points” in Scrum, and the STP’s are different ways of implementing those variation points.

“Optional Scrum Patterns” are patterns that can be used in conjunction with Scrum, but are not specific implementations of Scrum techniques as specified or required in the Scrum Guide. These can be just about anything, but they must follow and/or support Scrum principles in order to be considered as an Optional Scrum Pattern.

I also see the need for the ability to create a “mashup” of different Scrum patterns to create a set of practices and techniques for a particular team or context. For instance, we might start out with a Scrum Starter Kit that includes things like:

Holding a Release Planning meeting every 2-3 months (OSP)

2 Week Sprints (STP)

Using Story Points to estimate Product Backlog Items(STP)

Using Ideal Hours to estimate Sprint Backlog plan items(STP)

Doing a typical burndown chart to sum the remaining work for the sprint(STP)

Representing Undone Work(OSP)

Doing the typical “round robin” style of the Daily Scrum(STP)

Doing a fairly typical “Plus-Delta” retrospective analysis(STP)

Any of the above patterns could be interchanged with other patterns, and the Scrum implementation would still conform to doing correct Scrum. Presumably the change to different patterns would be an attempt to improve a team’s ability to delight their customers and users.

Who writes these patterns? Where do they come from?

In a word, anywhere. I’ve seen dozens of them on the internet and in books. I’ve documented a few original ones myself(though many of mine are adapted from others, and I would make every reasonable attempt to give credit where credit is due). I would not be attempting to create all of these patterns, but to assemble them and label them so Scrum practitioners can easily understand which of them are optional, and which are fulfilling required practices of Scrum. Of course, it will also become helpful to understand where these patterns fit into the grand scheme of Scrum, and I have some ideas along those lines, too.

I will keep iterating on this concept, and I hope to get back to you with more on this topic in the future.

A friend recently asked me this question:

What would you recommend in terms of the best book(s) to learn about Agile (Scrum) with XP practices? That is, if you had a team of developers who were newbies to Agile, Scrum, and XP, what books/articles would you give them to bring them up to speed on what they should be doing and how they should be doing it?

This question from my friend is a very tricky one, in that it is very broad and generic, and my friend gave me no extra team or organizational context to go on, so about all I can do is give a generic answer, and that is what I’ve done below. If you’re looking to combine Scrum with XP practices, be sure and see Kniberg’s book under “Scrum” below.

Don’t have time to read all of these? Well then, read the first couple from each category, and then continue working your way down each list.

Releases as Themes

Some teams uses release as themes, which his sometimes helpful with Release Planning and Release tracking via burndown charts. So, in our example above, we might decided to theme the current stories as follows (stories are listed in priority order)

Story/Epic

Associated Themes

Pay by MasterCard/Visa

Release Feb2011, Credit Card Payments, Online Payments

Pay by American Express

Release Mar2011, Credit Card Payments, Online Payments

Pay by Discover

Credit Card Payments, Online Payments

Pay via PayPal

Online Payments

So, looking above, we know that MasterCard and Visa are targeted for the February 2011 release, Amex is scheduled for the March 2011 release, and the last two stories have not been targeted for any particular release. Since the Epics are listed in priority order, it is perfectly acceptable that we haven’t yet scheduled the lower priority Epics for a release. Much like a product backlog, the Epics and Themes near the top of the list are more fine grained(have been broken down further) than the epics and themes near the bottom of the backlog.

At this point, given the theming above, we may decide that we really don’t need the “Online Payments” theme any more. At the highest level planning, it was useful because we were considering online payments alongside with other Epics like searching for products and allowing users to post reviews on products. Once we broke the Epics down further into themes with smaller Epics, conveying “online payments” vs. “credit card payments” or “pay via PayPal” didn’t provide a whole lot of useful extra information. By now, the Epics have been discussed in planning, and everyone knows that credit cards and PayPal are the online payments we’ve been discussing As such, at this point I would drop the “online payments” theme because we just don’t really need it any more.
So, now we might have our themes as follows:

Story/Epic

Associated Themes

Pay by MasterCard/Visa

Release Feb2011, Credit Card Payments

Pay by American Express

Release Mar2011, Credit Card Payments

Pay by Discover

Credit Card Payments

Pay via PayPal

Wait! How come “Pay via PayPal” doesn’t have a theme? Because it doesn’t really need one. Let’s go back to the definition of Theme – a set of related user stories. We’ve already said that due to the collaborations that have already occurred, everyone already knows what we mean when we say “Pay via PayPal”, so it doesn’t really need a theme. Not every story has to have a theme, and themes are generally only useful to external stakeholders and the Product Owner, and generally only highly useful at high level planning like product road mapping and Release Planning.

At this point, we’ve pretty much used Epic and Theme where it’s most useful — at the road mapping and Release Planning levels. There is one more usage though that might be interesting to some teams.

Let’s say your Scrum team is planning to do “Pay by MasterCard/Visa” soon. Because they’re doing it soon, they would like to slice the stories into smaller chunks to allow their testers to get a first crack at testing something end to end sooner. The team has decided to slice the story into “Happy/Sad/Bad” paths. The bad paths will represent a story where the user goes all the way through the purchasing process but finds out that the credit card processing system(a 3rd party service) is down. The sad paths will represent cases where the card is rejected for various reasons (over the limit, invalid card, invalid card verification #, etc). The happy path will represent the cases where the card is accepted and the user is able to proceed with their order. The team decides to assign these stories to their related theme “Pay by MasterCard/Visa”. So, now the stories and the backlog looks like this:

Story/Epic

Associated Themes

MC/Visa bad paths

Pay by MasterCard/Visa, Release Feb2011, Credit Card Payments

MC/Visa happy paths

Pay by MasterCard/Visa, Release Feb2011, Credit Card Payments

MC/Visa sad paths

Pay by MasterCard/Visa, Release Feb2011, Credit Card Payments

Pay by American Express

Release Mar2011, Credit Card Payments

Pay by Discover

Credit Card Payments

Pay via PayPal

This is a valid use of themes but I find it to be overkill. Here is what I would do instead:

Story/Epic

Associated Themes

Pay by MasterCard/Visa – bad paths

Release Feb2011, Credit Card Payments

Pay by MasterCard/Visa – happy paths

Release Feb2011, Credit Card Payments

Pay by MasterCard/Visa – sad paths

Release Feb2011, Credit Card Payments

Pay by American Express

Release Mar2011, Credit Card Payments

Pay by Discover

Credit Card Payments

Pay via PayPal

So, what I’ve done is just rename the stories, which I think is more useful than creating themes every time one has a whim to do so. You could even rename them “Pay by MasterCard/Visa part 1”, “Pay by MasterCard/Visa part 2”, etc. This is why I believe Themes and Epics are really most useful at the PO and stakeholder level when release planning or road mapping. Keep them as high level grouping mechanisms, because that’s what they were really meant for. While the Scrum Team is involved at the Release Planning level as well, they will generally not care that much about the Epic and Theme concepts. They still care most about the stories that they’ll have to implement the dirty details for.

Prioritizing at the Epic and Theme level

Another way to make Epics and Themes useful is to use them to do high level prioritization with stakeholders. Generally, stakeholders don’t want to get into the nitty gritty of small stories. They really only care most at the higher level view. As such, having them help prioritize a fine grained Product Backlog might not be useful, especially if there are huge amount of stories. In these cases, it is useful to discuss Themes and Epics when prioritizing, which will then give the PO useful information with which to prioritize the smaller Sprint sized stories.

This is not to say that discussing small or fine grained stories with stakeholders is altogether bad, just that it might be bad in certain situations. Obviously you’ll have to gauge the situation you’re in and use the appropriate level of detail for your audience.