mikkeman.nl

Are you starting with Scrum? That’s good news!

• You have a Team: check.
• You have a Product Owner: double check.
• You have a Product Backlog:  …. right?

Product Backlog? Yeah, we have a list with things we could work on, and when (if?) we finish it, we’re done. But is that a Product Backlog?

The minimum viable product backlog (yes, I got inspired) is not just “all items we came up with that we could work on”. It is a filled, estimated and prioritized list of work items. There are three key points in this statement.

The backlog is filled

This means it should at least contain enough work items to fill the first sprint and include an extra work item to expand the product backlog. Most projects start out with a backlog with high level items for the entire system (that may be a dozen to a hundred or more).

The backlog is estimated

The team must have enough information to estimate the items on the backlog. The Product Owner should be able to explain the items, the team should be able to give them a relative size (using planning poker, for example).

The backlog is prioritized

The Product Owner should have a clear vision on the entire product (think big), but also on what to build first (act small). Not always easy. The book says “pick the story with the most business value” but that doesn’t make it easier for most Product Owners.

A useful technique in this respect is a story map. The story map works top-down from the high level work items. These high level work items are typically things a system MUST support in some way or another. It’s just the sophisticatedness of the solution that determines the size of a work item. When Product Owner and Team together work out the least sophisticated solution to all high level items, we have what we call the walking skeleton, or minimum viable product.

Building the walking skeleton is a very useful prioritization, because it proves the (functional and technical) feasibility of the product.

Why this post?

Too often teams “rush” into Scrum to find out after a few sprints that the product backlog requires major maintenance. This might cost more capacity than one would like, possibly affecting velocity and the sustainable pace of the team. To prevent it, make sure you have a minimum viable product backlog from the start, and make sure it remains viable throughout all development activities.

Some people like to compress these activities in a few days, other like it to extend it to an entire sprint (to get used to the rhythm). Some people like to call this preparation “sprint zero”, others argue that it might as well be the first sprint. I don’t care how you call it, just make sure you do the activities associated with a controlled start.

Image taken from yoppy’s Flickr stream under Creative Commons license.

Being a Product Owner (PO) is not the most easy role on a (Scrum) project. In fact, it might be the hardest role. POs are easily faced with months and months of requirements in the backlog. They are supposed to prioritize this huge list (“is requirement XYZ more or less important than requirement ABC?”), making sure that the needs of stakeholders are met.

And please make sure there is enough ROI, dear Product Owner!

And attend the daily scrum to clarify any issues the development team has within the current iteration!

And prepare the next set of requirements for planning.

And… And… And so on.

Jeff Patton wrote an excellent article about the assumption that the Product Owner must possess super powers: The product owner and the product-shaped hole. Unfortunately, most Product Owners do not possess super powers. I might even say that not a single PO has them (since they are still exclusively used in comics and the like).

This post deals with one of the challenges a PO has: how to prioritize my backlog?

When asked to prioritize every requirement on a scale of 1 to 3, the following usually happens:

• 80% will end up as priority 1
• 10-15% as a priority 2
• the rest (if any) is priority 3.

That is not very helpful to determine what requirement(s) to work on next.

A useful approach in this situation is to limit the number of requirements that are allowed in priority 1 and 2. For example:

• 10 requirements are allowed priority 1
• 20 requirements are allowed priority 2
• the rest is priority 3

All priority 1 requirements must be ready for immediate scheduling in the next planning meeting. Suppose that 8 requirements fit for the next iteration, then all you have to do is:

• promote 8 requirements from priority 2 to 1 and;
• promote another 8 requirements from priority 3 to 2.

That is just a minor task compared to the task “rank every requirement against all others”. When you put the priority 1/2/3 boards on the wall with brown paper and postits, it provides visual focus as to what to work on next as well as a transparent overview of “what’s next” and “what’s almost next”.

Try it, you might like it!