Breaking Down User Stories

The objective that every sprint deliver valuable, working software, is not a requirement. It is a design principle of the Scrum process.

Agile is not about mandating processes, it is about getting better and faster. When you can’t reasonably decompose a story into something that can be delivered in a single sprint, don’t. You can have a sprint where you don’t deliver anything, because you only complete part of one thing. Yes, it will look bad on the burn-down chart.

Will it mess with your velocity? A bit. But who cares? Velocity is a measurement that helps inform projected delivery schedules. You may have one sprint with zero velocity, but in the next sprint, when you do deliver the “two sprint story”, you’ll have double the velocity. Magically, your running average is back to normal.

Don't let the rulers you use to measure the team’s output cause you to act irrationally.


Tyner Blain has got to be one of the best resources when it comes to Product Management learning. I was catching up on some of their recent (and older) posts and this one on breaking down user stories caught my eye.

Particularly the quote above. In our current release our team had to do exactly what is described, we had a zero velocity in Iteration 1 in order to get the core components of our feature in place but made that up by completing two large stories in Iteration 2. Since then we have been aggressively cutting down our feature set to focus in on the Minimum Marketable Product that will meet our users needs.

It feels like sometimes people forget that Agile is not just about being flexible in how you develop software but also adapting the process to meet the needs of the team and the user.

Some other Tyner Blain goodies I've been reading recently:

Writing Verifiable Requirements should be a rule that does not need to be written. Everyone reading this has seen or created requirements that can not be verified. The primary reason for writing requirements is to communicate to the team what they need to accomplish. If you can't verify that what the team delivered is acceptable, neither can the team. This may be the most obvious of the rules of writing requirements - but it is ignored every day.

Customer-Centric Market Model

Measuring the ROI of Design