Ready, Ready to Done, Done
March 7, 2012
When stories are developed and groomed they need to be ready to implement before the sprint begins. The product owner should work with the team ahead of time to make sure that the stories are ready to be implemented by the team. They should be clear, concise, and most importantly actionable.
A good product owner should have enough stories in that state to fill up the next two sprints. Both the team and the product owner should spend 5-10% of their time in preparing stories for future sprints.
Here’s what happens if stories aren’t ready. The team is estimating and forecasting that they can finish vague and incomplete stories. They waste time and energy trying to get clarity from the Product Owner on exactly what the story means. People get frustrated and annoyed and run around in circles rather than getting down to work. Or that one vague story actually turns out to be five real stories once the work is actually begun. Or they work on the wrong thing, or the right thing in the wrong way, forcing the work to be re-done.
The stories at the top of the ordered product backlog, the stories the team will be pulling into the next sprint, have to be ready. Some companies actually require a detailed checklist to determine whether a story is “ready ready” not just kind of ready, or sort of ready. Simply getting your stories ready will have immediate, dramatic impact on the team’s productivity. But notice, while the product owner is responsible for putting the features and stories in the backlog, the team must work with the product owner to help him or her to get the stories into actionable shape. Because only then will the team be able to estimate how much work any one story will take, and how many stories they can take into a sprint.
The Dangers of Not Being Done
And that leads me to what done is. I wrote extensively in the last chapter about the importance of a definition of done. I want to re-emphasize it here. If some people think the work is done at the end of the sprint, but it really isn’t done, people are going to have to go back and re-do that work. We know that if you have to do the re-work it will take you at least twice as long to do it, and we’ve seen it take as much as twenty-four times as long. This type of waste is called technical debt in the software business. It’s the stuff that isn’t done that has to be done before you can ship your product. If you don’t get it done in the first place, when you were working on it to begin with, it will pile up and pile up, until there is no way the team can get that amount of work done before the planned release date.
Managers force people to go on death marches, the quality of the software slips, people get sick and depressed from the pressure, the date slips, the product that is eventually released is bad, and the customers are irate. This leads to the company failing and you losing your job, your children going hungry and a destructive spiral into the darkest depths of the human condition. Don’t do it. Get stuff done.
Jeff’s most recent book The Power of Scrum is available on Amazon both in print as well as a Kindle edition.