mikkeman.nl

User Stories are a nifty concept to convey “what needs to be done” in an agile environment, where not all analysis and design activities have been done before coding has started.

User stories need to be clear and concise, and everybody (Product Owner and Team) should have a basic understanding of the story during the Sprint Planning. Just enough info to determine the approximate size of the beast.

After the Sprint Planning, there will be (should be) LOTS of conversation and confirmation. By definition. Because the requirement is still only briefly analyzed, it is a false expectation to be able to understand and code a user story right after Sprint Planning (of course, it happens, but it shouldn’t be the standard).

I sometimes come across teams that look back and conclude that they didn’t deliver what was expected and propose to be “more clear in the wording and details of the user stories”. Don’t try to go that path. It’s a slippery slope, and before you know it, you’ll be back reviewing detailed designs. You might say it’s an anti-pattern of agile.

I don’t care what the user story says.

Make sure everybody has a basic understanding at first and work together to deliver what’s expected. That’s my preferred strategy if you adhere to agile principles.

Photo taken from koalazymonkey’s photostream under Creative Commons license.

Recently I wrote an article (in Dutch) for Whitehorses that discusses technical debt. What is it, when (not) to use it and how to deal with it in environments that have lots of it.

Read it here: “Kort-door-de-bocht of elegant?“

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.