Why I don’t use real hours for sprint planning

OK, so several of my friends and colleagues pointed me to Mike Cohn’s recent blog post about why he doesn’t use story points for sprint planning. I left a couple of comments on his blog, but I couldn’t wait until he moderates them… so I thought I’d post my thoughts here.

In my opinion, using either story-points or real-hours for sprint planning makes one assumption. The assumption is that it is somehow very important to get a sprint “just right”. In other words, it is important for a team to estimate a sprint’s worth of work well enough so as to make it fit perfectly within a sprint.

I believe that it’s not important at all. Here’s why.

First of all, the length of a sprint is picked by the team in a mostly arbitrary manner. Some pick 30 days, some pick 1 week. For the most part, it could be any number in between there. So if the duration is not that critical, then why should fitting work into it be? In any case, when a team happens to under-estimate, the undone work gets pushed into a future sprint. And when a team over-estimates, the stakeholders gleefully add more work to the sprint. So… what was the point of all the real-hours-based estimation?

Next, lets talk about predictability. Take an example of a basket-ball team. They can make a general statement about their long-term average, but can they predict what they’ll score in the next game? No… but even more critical, is it even important to try to make this prediction? The answer is not really, it is only important that they do their darned best. A software team can certainly spend time breaking stories down into tasks and then even more time estimating each in real hours, and then bargaining with the stakeholders to make sure whatever they pick all fits in… but it’s just more important that they work on the highest priority cards, with as less distraction and road-blocks as possible.

Whether they fit it all in, into that one sprint or not, is a mere detail.

Now, it’s not to say that having dates is not important. It is, but you can’t be scope-bound AND time-bound. Pick one. My default choice is time-bound with variable-scope. In other words, I like to set a release-date, and then ensure that the team is burning down the highest priority items at all times, as that date approaches. When the date is nigh, release! We’re all writing production-ready software, aren’t we? Then, repeat.

This approach then makes it possible to simply drive the whole project off the product-backlog… without strict sprint-backlogs. It allows velocity to be measured in story-points (from the product-backlog) and prediction is a matter of total-story-points divided by velocity-in-story-points. Simple. If anyone asks what will be done this sprint, the answer is the highest priority stories on the backlog, as many as the team can, here’s our best guess (average-velocity-in-story-points). This approach is actually faster than sitting and re-estimating individual stories in real-hours, because well, the team doesn’t have that distraction anymore.

In fact, from my experience, when the team gets comfortable doing this, they even ask… OK, so if the length of the sprint was set fairly arbitrarily, and as long as we work on the most important stuff at all times, then why are we bothering with the concept of sprints at all? These teams go beyond what I described above and eliminate the waste of iterations. Fun, eh?

If I talk about this stuff to people, sooner or later, someone brings up the happy concept of rhythm – how it is important for the team to have a pulse, a beat to which they work – sprint-planning, development, sprint-close, retrospective, repeat. It gives them satisfaction. It probably does, but I think we can do better. I prefer my teams to not just close an iteration based on some rhythm, but even push the software into production each time. Let the rhythm be set not by an arbitrarily picked number, but through customers getting their hands on the next release of the software. They still do the retrospectives regularly, and have team outings all the time. But the rhythm of the team is set through actual releases. When teams get better and better at this, and realize the critical importance of cycle-time, they do all they can to reduce it.

Anyway, I can talk about this stuff for a long time. Back to sprint-planning. My take is – do it like agile architecture/design. Think of it as evolutionary. We’ve eliminated the big-up-front-design, it is time to eliminate the big-up-front-sprint-plan. Prioritize the back-log constantly, always ensure that the team is working on the highest priority item. Ensure there are as less distractions and road-blocks as possible. And release quickly, as early and as often as possible – make a rhythm out of it.

And if the stake-holder asks when a particular story will be done, see where it stands in the prioritized backlog. The answer to the question is, of course, after all the ones above it are completed. Ask also if they would like to re-prioritize. That’s all there is to it!

10 thoughts on “Why I don’t use real hours for sprint planning

  1. There are a couple of reasons why a sprint planning meeting should not be considered overhead:
    1) The name is a misnomer or a simplification. The meeting is equally a product design and a technical design meeting. Teams should be discussing what to build (especially “next” and with the product owner). Teams should also discuss how they will build it. These discussions don’t need to take long but should occur. A good, experienced team doing two-week sprints can plan a sprint in around 2 hours and no more than 4 hours. For an investment in product and technical design I do not consider that waste.
    2) There are studies that show teams do best with “slightly aggressive but realistic deadlines.” I’ve put that in quotes because it’s the phrase I remember from one study. I’m traveling right now so I don’t have a reference handy but this shouldn’t surprise anyone. The purpose of sprint planning is not about hours and task decomposition. It is about making a commitment to deliver some set of functionality. Once the team makes a commitment to deliver some functionality they are more likely to deliver that much than a team that does not make a commitment. Should the team strive to perform better as in your basketball example? Of course. But the team that makes a commitment and tries to achieve it will outperform a team that does not.

  2. 1) The product owner attends the sprint planning meeting and sits through discussions of how the team will build it?
    2) “A team that makes a commitment and tries to achieve it will outperform a team that does not.” Sounds reasonable. Committing to a set of stories does not require that the stories be broken down into tasks that are estimated in hours. In my view this just adds extra work, and it provides a false sense of accuracy to those hour-based estimates. Teams can still commit when estimates are in points.

  3. I agree that designing the implementation is important. However, I believe this needs to be a just-in-time activity. If the team tries to design the implementation during the planning meeting, two things happen – 1. it takes forever, and 2. the value from that discussion will probably decay away before the card is even picked up. Or a developer who might not have been present may end up implementing it, or the requirement might change a little bit, and so on.

    This is not to say that the topic of design is not broached at all, of course. However, design is evolutionary, doing that in the planning meeting is sub-optimal.

    About the commitment, I agree with Adrian above, you don’t need detailed task breakdown or hours-based estimation to commit to something, as long as everyone on the team is mature enough to understand estimates are estimates, and there is value in getting something in the hands of the customers as quickly as possible.

  4. Removal of iterations seems to be just another improvement that some teams are able to make, perhaps linked to understanding of Lean concepts. It is not clear (to me at least) what the criteria are that make it a viable option.

    In any case, I don’t think anyone’s suggesting that a new sprint team start this way, and so far I have not seen anyone say that we should do away with regular team retrospectives.

  5. This is good thinking (and writing).

    About the only caveat I can think of is that for your scheme to work, you need a self motivated and talented team, who actually like writing software and are well above average in programming skill.

    As you know, these days I am very skeptical of methodologies, agile/lean whatever, but having worked on both “classic” iteration based agile/scrum projects and also on the “pick the top priority card and work on it, damn the estimates” style you outline above, I can confirm that the latter way of working was an order of magnitude more productive than the former.

    Cheers,

  6. Amit,

    Very well said. I’d like to take what you’re saying a step further. In my ideal world, we shouldn’t be required to estimate at all. Just keep picking the next important thing and get it done. If something starts taking too long, discuss alternatives.

    Obviously, high levels of maturity and trust are needed for this arrangement to work. In this life, maybe…

  7. So obviously I agree with you Amit. As you know I actually implemented this strategy, with lot of stealth. We used to be a team that used to do sprint planning in which we would discuss till the cows came home about how many hours a task takes, what it should look like etc. etc. Well with gentle persuasion, the team saw the folly of their ways. We realized that maintaining sprint backlogs and all the activities associated with it were causing pain and in-fact slowing us down. So today we maintain a prioritized list of product backlog user stories(broken down to a reasonable size, which is an art in itself that you get better at as you learn and adapt) and the team picks off the top of the stack. So for example, the team is mature enough to know that to get a list of items on the UI, they need a UI pick list, database table etc etc, and don’t feel the need to do this breakdown and estimate it. We do draw a line in the sand, your so called end of sprint. I still have to maintain a sprint backlog but no one on the team really cares about it. Over the past six months the team members felt it was a phony success and that real success was delivery as you pointed out. Obviously this comes with a mature team, but I think it is achievable. Also, obviously, there are teams that will find this too extreme and would like the rhythm approach. I guess every team finds their own path with this. I for one have become a fan of as Ravi Mohan pointed out: “pick the top priority card and work on it, damn the estimates”

  8. Oh yeah one more thing, this strategy has helped us even in very difficult times right now. I would not say we are perfect, far from it, but we have become good. Although things have gotten tough over the past couple of months with ever changing direction and much more, the team is still sort of together on this strategy, atleast I think. We did loose a little direction, but I think considering where we are as an organization this has really helped us keep our sanity.

  9. Bravo! You need to write the next book on Agile Estimation and Planning. Wholeheartedly agree with everything in this blog post.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s