As described in Agile Estimating and Planning, I’m a huge fan of using story points for estimating the product backlog. However, I also recommend estimating the sprint backlog in hours rather than in points. Why this seeming contradiction?
I’ve previously blogged on the reasons why I recommend using different estimation units (points and hours) for the different backlogs. But I’m often asked this related question I want to address here:
I’m curious why you aren’t using story points to do your sprint planning. I thought that the point of measuring story point velocity was partly to determine how much we can take on (or commit to) in a sprint. Do you only use story points for longer-term planning (e.g. release planning)?
I don’t use story points for sprint planning because story points are a useful long-term measure. They are not useful in the short-term. It would be appropriate for a team to say “We have an average velocity of 20 story points and we have 6 sprints left; therefore we will finish about 120 points in those six sprints.” It would be inappropriate for a team to say, “We have an average velocity of 20 story points so we will finish in the next sprint.” It doesn’t work that way.
Suppose a basketball team is in the middle of their season. They’ve scored an average of 98 points per game through the 41 games thus far. It would be appropriate for them to say “We will probably average 98 points per game the rest of the season.” But they should not say before any one game, “Our average is 98 therefore we will score 98 tonight.”
This is why I say velocity is a useful long-term predictor but is not a useful short-term predictor.
Velocity will bounce around from sprint to sprint. That’s why I want teams to plan their sprints by looking at the product backlog, selecting the one most important thing they could do, breaking that product backlog item / user story into tasks and estimating the tasks, asking themselves if they can commit to delivering the product backlog item, and then repeating until they are full. No discussion of story points. No discussion of velocity. It’s just about commitment and we decide how much we can commit to by breaking product backlog items into tasks and estimating each. This is called commitment-driven sprint planning.
When a team finishes planning a sprint in this way it is indeed likely that the number of story points they have unknowingly committed to should be close to their long-term average but it will vary some. It will also be true that a team will commit to approximately the same number of hours from one sprint to the next. I use the term capacity to refer to this number of hours because velocity is reserved for referring to measuring the amount of work planned or completed as given in the units used to estimate the product backlog (which I recommend be done using story points).
Tags: sprint planning, story points
Couldn’t agree with you more. Here’s a small problem I have with Story Points and Hours on my current project. Because the team is new to scrum, we started using “Ideal Days” (1 Ideal Day = 1 Story Point) to estimate story size. Because we have some epics in our backlog, we end up breaking these down into smaller stories during Sprint Planning. As a result, we need to estimate the size of these smaller stories AND we need to estimate the task hours. What happens is that the team uses these hour estimates to put the story in the right “Ideal Days” bucket (1,2,3,5,8,13). Essentially, for these new smaller stories the team is working backward to estimate the size. This isn’t ideal, but do you see a problem with this? I would rather have the team break down the epics and estimate story size before Sprint Planning, but it in day-to-day life it can be hard to find this time. Thoughts?
From a lean agile perspective there seems to be ramblings that perhaps backlogs are a waste. I think the concept of refining stories as they get closer to the a sprint helps eliminate some of this waste.
Currently we have been using story points for both the backlog and the sprint, but we have really been considering a more commitment driven sprint planning approach as decomposing stories into tasks as part of the plan appears to have many benefits. Would love to hear your thoughts on the many “lean” debates going on around agile.
I loved the basketball analogy and would probably add to it. Say I’m the Phoenix Suns and we average 102 points a game. If I know I am missing Steve Nash to injury in tonights game I would probably not expect to score 102 tonight. We find the biggest downside to using story points is that if the dynamics of the team are changed or other commitments for the team are introduced that its very hard to account for that in points. If I spend 3 days at a conference/training how many “points” is that against our velocity?
Thank you for this clarification, Mike. We currently are doing commitment-driven Sprint Planning (breaking stories into tasks with “real” hours) but also trying to provide that sanity check by being mindful of velocity because our teams were overcommitting greatly and not achieving doneness. For example, one team’s average velocity was 43 with last observed velocity of 65. During Sprint planning this same team ended up committing to 130 points, which is completely unrealistic.
Per my previous reply in your “To Re-estimate or not; that is the question” post, we are trying to enforce the team to not allow committing over 10% of their velocity (while still doing commitment-driven planning) to “wake them up” to see that they are over-committing. However, after reading your post, this seems like a bad idea.
If the sanity check of being mindful of average velocity isn’t working, do you have any ideas on how to get the teams to not over commit?
Brian–
I do think there is a danger in re-assigning story points during a sprint planning meeting. We’d really like to have all estimates of product backlog items be made with approximately the same level of knowledge. That way we have a more reasonable expectation that differences in the estimates will balance out. If the team re-estimates some product backlog items after having gone through sprint planning the effect is that your product backlog will contain some items that have a lot of thought in their estimates (from having done a task decomposition first) and some with much less thought in them. That will make them less comparable. Re-estimating during sprint planning isn’t evil and you’ll sometimes need to do it, but when possible try to do the story point re-estimating before doing the main sprint planning of task breakdown and estimating.
Hi Derek–I hadn’t seen those specific ramblings but I have seen similar comments made that a product backlog is waste. The arguments are largely wrong or are too extreme. Mary Poppendieck makes the point that investment in defining product backlog items is the same as building up inventory. That is true but an inventory of ideas is not as pernicious as an inventory of tangible things such as cars (the perennial lean example). If a team has no product backlog then they will no idea what is coming next. They could be building a spreadsheet one sprint then a dating website the next then a video game the next. A product backlog provides insight into what is coming next. Even a statement like “Let’s build a word processor” is a (very) high-level product backlog that may exist from one sprint to the next. A product backlog helps a team buy into the vision of the product, helps them see what is coming next so they can be aware of that, helps avoid risk, helps set plans for when a product should be released, and so.
Here’s the perfect counterargument: Lean people love Toyota. They hate inventory and point out how bad it would be for Toyota to have a big inventory of Camry cars parked somewhere. I absolutely agree. However, would it be bad for Toyota to have an inventory of ideas saying, “Two years from now would be a good time for a new minivan and maybe the year after that we should think about a new body style for the Prius.” Or should Toyota perhaps not start thinking about those things until the day before they are needed?
Finally, let me comment on the term “lean agile” since you used it. I know you’re not one of these individuals but there’s no such thing as “lean agile”. If there were it would imply there is a “fat agile”
or a “non-lean agile”. Lean and Agile are very, very similar and compatible. Whenever I see the phrase “lean agile” it seems to be used in a way for someone trying to create yet another brand in the agile space. I’m anxious for the day when all brands go away (including Scrum, the one I practice most often) and it’s all either just “agile” or (even better) just “software development”.
Hi Misty–
I think the sanity check of having the number of story points committed to (via commitment-driven sprint planning) be within 10% of the team’s average is a reasonable rule of thumb. I can think of a lot of times the team may want to violate it and if they can make a good argument I’d be fine with that as long as their arguments tended to hold water in hindsight.
The key with commitment-driven sprint planning is that the team will commit to a certain number of hours this sprint. Barring changes in team composition (transfers, vacations, etc.) they should commit somewhere around the same number of hours from sprint to sprint. If you find a team overcommitting regularly, here’s something I do:
Determine the number of hours by which they missed their commitment. Suppose a team plans to do 400 hours but only finishes 350. They missed by 50. Take that number and double it (to 100 in this case). Have them commit to around that many hours in the coming sprint (300 in this case, 400 – 2×50). The reasons for the doubling are to (a) make sure they don’t miss twice in a row and (b) because I assume that they cut a few corners in trying to meet the goal last sprint and I want to allow time to quietly fix/cleanup any potential areas where quality may have been cut.
Weekly Agile Reading. Pack 4…
Manually filtered top of the most interesting writing published since last Saturday. Of course, most interesting from my personal point of view.
Top writing of the week…
TASK POINTS is another alternative I have used on occasion. During sprint planning the tasks are estimated using the same techniques used for planning poker. The benefit of task points is that it again uses relative measures for tasks instead of absolutes. The Task Points end up representing a range of time (1-3 hours) instead of an absolute estimate in hours. For longer iterations (3 to 4 weeks) and a mixed bag of work, where done for stories are completely different I prefer task points to ideal engineering hours. For short iterations (1-2 weeks) hours seems to work well, the shorter iteration time frame means team members take on smaller stories with more detailed tasks.
I just wanted to say thank you, once again, for taking the pain out of planning. When we estimated proposed projects in days or hours, we were terrified to provide any number until we had basically built the thing on paper. As soon as a time was stated, we were committed. Then, story points allowed us to plan in units and simplified the task of prioritizing project work and choosing the right things to work on. Then we were stuck with the confusion of points and translating that to where we were on the project. When we fell behind, it was just points, not time. So we were unable to really get a solid grasp for how far behind we really were. The goal is to not fall behind. However, we all know that things don’t always work out as planned. The goal of converting story points to hours by decomposing stories into tasks and estimating tasks really helps add value to the activity of listing the tasks. I’m embarrassed to admit that this is something we almost always fail to do when project deadlines overrule our desire to have a solid, sustainable process. Sometimes your boss just says, “get it done, whatever it takes.” and you aren’t going to get anywhere showing a burn down chart.
Hi Rusty–
I’m glad you’ve found that the approach helps take the pain out of planning. Thanks for sharing that.
Hi Mike, when during the process does the team commit to implement features exactly? When you use hours for tasks rather than story points isnt that some kind of confession that you do not trust story points for planning of an iteration that one can really commit to? I always wondered about commitment of the team in sprint planning 1. In the scrum method by the book you first have sprint planning 1 based on story points (where the team commits to deliver) and after that the features are broken down to tasks. How can the team commit to something based on story points when they find out one day later in sprint planning 2 that after detailed planning in hours that there is too much work?
[...] Bem, se você está curioso pra saber o porquê ele recomenda story points para estimar o backlog e horas para estimar o sprint, é só ler aqui. [...]
Hi Knut–
I plan at two different levels because there are times we need a high-level plan. That is the product backlog and story points. These are estimated in such a way that tradeoff decisions can be made and at least slightly flexible commitments can be made. For example, a team may commit to delivering support for adding tables in a word processor but may not commit to a bullet list of 100 items of how tables will work (cell shading, 8 different border types, etc.). At the level of the product backlog the team is committing to deliver a set of features over time (multiple sprints). They’ll under-deliver sometimes and over-deliver others. That’s my point at the start about story points being a useful long-term measure. At the start of a sprint the team is making a different type of commitment–they convert items into hours because now that they are about to begin work on them it is worth decomposing each and understanding it in more detail. I can’t imagine spending that much time at the start of the project on ALL product backlog items. And I can’t imagine that if I did I’d feel comfortable with the numbers; I’d assume that I’d missed way too many things by looking too far into the future.
Mike,
I use to recommend exactly what you are recommending. However, earlier this year Brent Barton, Byran Stallings and I led a large team on the most critical project in a 42B company. A waterfall plan gave a date of 18 months out and the need was a 6 month delivery. Release planning indicated 1000 story points needed to be delivered. None of the people had ever done Scrum before.
Since the only thing relevant was number of story points done, we only burned down completed features in the Sprint burndown. They met the date.
Previously, I thought only experienced teams as a PatientKeeper were able to do this effectively. PatientKeeper commits to a certain number of stories every Sprint and goes live in large enterprises like Mass. General Hospital at the end of every Sprint. Recently, I asked the Chief Product Owner if he felt uncomfortable that the teams were no longer using hours for Sprint burndown. He said he was very uncomfortable. What I asked if he wanted to go back to hours he said no. I was surprised and asked him why. He said, “It will slow them down!.”
So there are two stories from a newbie set of teams and an experienced set of teams. It looks like it is all about inspect and adapt to see what maximizes velocity.
Hi
We use both story points and ideal hours.
Story points are used when sizing up the entire back-log during the initial project planning phase. (Before sprint planning 1)
We use the Fibonacci sequence for this.
So at the start of the project we know how many story points the entire project consists off.
We usually have a tentative deadline, set by management.
I usually tell management that after the first two sprints, we will be in a better position to commit to the tentative deadline, as I can use team velocity (story points per sprint) to support my argument.
The team then decides what they would like to commit to for a sprint. (Sprint Planning 1) This is difficult for the first sprint as there is not real baseline, you have to rely on gut feel.
Then the detailed sprint planning starts (Sprint Planning 2). Here we break down each feature in the Sprint Backlog into dev/qa/ba tasks. Each task is also allocated a number of ideal hours. I use a 1,3,6. This means that no task spans a day, if it does then it must be broken up.
I like the ideal hours approach, as it leaves time for meeting etc. Keeping the tasks small also improve momentum i.e there are always cards moving to done.
I might have got my terms mixed up wrt Sprint Planning 1,2 etc but SCRUM seems to be working on my projects.
Await feedback.
Hi Suven–
This is exactly what I advocate: story points on the product backlog (because they’re fast, easy, and adequate for high-level prioritization and planning) and hours on the sprint/iteration backlog.
Hi Mike,
Firstly, I’d like to state that I have read your book cover to cover and hands down, it’s the best book on agile/scrum out there.
I have a question for you in regards task ideal hours. Do you think it’s relevant to add the total task hours and compare that against total available hours? I assume that’s the point of commitment vs time driven approach.
Jack
Hi Jack–
Thanks for your kind words about my book.
Yes, I absolutely coach teams to add up total task hours and compare them to available hours. I usually start a commitment-driven sprint planning meeting by asking team members to “do your personal math,” by which I mean to figure out their availability for the sprint. That’s the number of hours of PLANNED work they can commit to. I don’t want to commit to 8 hours a day of planned work because there’s corporate overhead and because I will undoubtedly forget some tasks or some tasks might take longer than planned. I might believe I can devote 6 hours a day to my project but only feel comfortable committing to planning 5 of those hours. (The other hour will get used by unplanned work or by pulling something new in or by helping others.)
As we plan the sprint, breaking user stories into tasks, team members should be monitoring either the number of hours each is signing up for (if they sign up for specific tasks during the planning meeting) or the number of hours by functional area (30 hours of Java work so far, 18 of database, 32 of testing).
Thanks Mike, that helps a lot.
A have another question for you regarding bugs. What is your thinking behind how to treat hours associated with bugs. My understanding is that bug fixes should not be counted in as part of the regular work that you’re burning down. but i would assume that big bugs, that require architecture changes, would need to be scheduled in and counted. but regular day to day feature bugs arn’t counted?
Thanks
jack
Jack–
A sprint burndown chart (and the sprint backlog) that it visualizes should always represent our best estimate of the amount of work remaining. Suppose we discover a bug in one of the user stories being worked on during the current iteration and that we decide (as we likely should) that it needs to be fixed as part of the iteration. Further, suppose that fixing and verifying the fix are estimated at 5 hours. We’ve just moved five hours from the goal. An iteration backlog task (or two) should be added with estimate(s) of 5 hours and included.
As for big bugs, architectural changes, etc—yes, those normally go on the product backlog and get estimated and scheduled.
Hi Mike,
Back to my question about capacity .. do you believe one can calculate this from the tracking on the burn down to get your actual capacity …
e.g. if your velocity say is 32 hours per week, then over the course of a week your capacity = 32 hours
or as you say just do some personal math 40 hours per week – vacation time – time spent in meetings etc
Hi Jack–
Yes, I absolutely advise teams to assess their capacity from looking at the burndown chart. Essentially, the y-intercept (starting number of hours) on the burndown chart should be roughly constant from sprint to sprint. Make adjustments based on illness, holidays, dropped work, etc. Over the course of a 2-4 sprints, most teams figure out about how many hours to plan into a sprint and can make adjustments as needed for planned time off, etc.
–Mike
Thanks for the clarification Mike. I am completely agree.
Jack
Hi Mike,
Suppose I got a backlog item that is estimated in 55 (planning poker). During sprint planning 2, while breaking that into tasks and estimating each using hours I discover that it would required (for example) 100 hours of java development , 55 hours of sql and 80 hours of testing. What happens if I only have 50 hours available from a test resource ? Should I break the original product backlog item into 2 ? Should I keep the story as it is and not consider done when spring finishes ? Can I move unfinished stories from 1 sprint to another? Can I have a product backlog item just for testing (in this case) ?
Thanks
Hi Diogo–
First, I’d like to see if anyone else on our team can pick up the extra work (testing in this case). Perhaps someone who is nominally someone we identified as something other than a tester can help do some testing.
If that’s not possible then I would find a way to break out part of the story and do only the part we can commit to in the current iteration.
I find that teams do best if they take a no-partial-credit approach to their stories. We’re good at knowing when we haven’t started something, we’re reasonably good at knowing if we’re done, we’re horrible anywhere in between. So, avoid being in a partially done state to the extent possible.
[...] [7] Mike Cohn, 2007, “Why I Don’t Use Story Points for Sprint Planning”, http://blog.mountaingoatsoftware.com/?p=15 [...]
Hi Mike,
I have a product backlog which includes high level stories, which can be referred to more as epics than as used stories. All stories/epics are estimated. Often it’s clear that one user story will take more than one sprint. Breaking the large stories into smaller stories will require significant investigation which can’t be done at product planning.
Now comes the sprint planning, and the product backlog stories are broken down into more manageable user stories, and each story to tasks (average task size is 3-4 hours).
My question is if it would be right, after breaking the epics to smaller stories, to replace the epic in the product backlog with the new stories. Obviously, the sum story points of the new stories won’t be the same as our estimation for the epic.
On one hand, changing the backlog makes the forecast less reliable. On the other hand, if we stick to the large stories with the high story points, we can finish a whole sprint without getting to “Done” state and without updating the release burndown chart.
Your advise would be appreciated.
Thanks,
Gershon
Hi Gershon–
Yes, I would absolutely remote the epic from the product backlog and add the smaller, new stories to the product backlog instead. And, yes the sum of their estimates (in story points) won’t be the same as the number of story points on the original epic. A lot of people want to constrain the estimates of the new smaller items to add up to the size of the original epic but that’s artificial and fails to incorporate new knowledge into our plans.
I would advise, however, that you should put the story point estimates on the small stories before you create tasks and task estimates for those new stories. This helps ensure that everything on the product backlog was estimated with an equivalent level of knowledge. We can get into problems if some product backlog items are estimating with little knowledge and others are estimated after a great deal of task level discussion. I cover that subject more in this posting here:
http://blog.mountaingoatsoftware.com/?p=20
Mike,
This article is a really big help. At the moment I am the ScrumMaster for a team that has two burndown charts for each sprint. One for story points over the sprint and one for task hours. I agree with you that story points aren’t a useful short term metric during the sprint. I don’t feel that the separate task burndown in hours is adding much value. The developers like the feeling of completing tasks and updating the burndown, but we are getting into the situation where we have burnt nearly all of our task hours without burning any story points! Obviously this is wrong.
I would like to change so that we only have one burndown for stories, but estimated in hours as you propose. I have a few questions though:
* Should we sum the hours estimated for each task and call that the ‘hour estimate’ for the story?
* When do we award hours and update the graph? Shouldn’t this only happen after all tasks are complete and the customer acceptance tests for the story all pass? The story is *done*.
* If we only award hours when stories are *done*, then at any moment in time our burndown chart doesn’t reflect all the latest knowledge that we have. For instance how do we handle adding and claiming the points for a 5 hour ‘internal to the story’ bug fix task?
* Does all of this mean that our stories are too big? We are developing a complex Web interface and find it hard to get to very small stories without going into detail on the UI and even then we end up with stories that are not independent.
Thanks for your illuminating article.
–
James
[...] Traduzi o post de Mike Cohn em seu blog: “Why I Don’t Use Story Points for Sprint Planning“. [...]
James–
I suggest sticking with a traditional sprint burndown chart–hours remaining on the vertical axis and days across the horizontal. Update this chart once per day based on hours as shown at that time in the tool or task board the team uses.
Augment that with with another really simple graph that you can update once a day at the same day. This graph should also have days across the horizontal axis but on the vertical axis, graph the number of completed user stories or product backlog items. Unless a team is used to trying to finish one or two stories before moving on to the next few, the line will start out flat for many days. It will then magically surge upward as all user stories are “finished” on the last two days. Well, except testers find a ton of bugs in them, so they aren’t really done. Have the whole team agree at the standup whether a particular story is “done.” If it is, that story is counted in the day’s progress. Here’s an example:
If you want to measure how much work a team can accomplish in a time period you need 2 different units of measure: work and time.
Try defining a measure for velocity. For example: lets say 1 velocity point is 1 story point of work per person per day (1 vp = 1 sp / 1 person * 1 day). Once you know the velocity points for your team, calculating the amount of work that can be accomplished in an iteration should just be a matter of plugging in the numbers and doing the math.
Tom–
That will work over the long term but will not work in the short term (i.e., one sprint), which is exactly why *I* don’t recommend this approach to planning a sprint. Two examples of why it doesn’t work:
1) It is analogous to taking the scoring average of the players on a basketball team, adding those up and saying “This basketball team will score 92.5 points tonight.” No. That may be their average to-date and it may be their average over the next 10 games but it is very unlikely to be their exact score tonight.
2) When I worked at the car wash as a kid, we each had a quota of four cars per hour. No one expected me to get exactly four cars per hour. Maybe not even 32 cars in an 8 hour day. But the quota was a useful measure over longer periods.
So, velocity is a useful long-term measure but not a particularly useful measure in the short term as in planning a single sprint.
Thanks for this very useful article, Mike! We re-ignited our scrum process in January 2009, after a fairly dismal attempt at “going agile” in 2008. We’ve just finished our first major release cycle, using scrum throughout and tweaking as we went along, but sticking to velocity and story points for estimation and release plans.
Although a lot went well with this “re-adoption” of scrum, the biggest issue has been estimation, and that the entire team feels that story points are not sufficient for actual work planning on sprints. This post on the role of story points and task hours, and the two burndown charts you use, come at the perfect time for us as we’re relooking our estimation techniques before we start our next major release cycle.
Hi Maritza–
Thanks for sharing your story of re-adopting scrum.
[...] useful in Release Planning? This concept is fairly useless when it comes near term planning. Even Mike Cohn suggests to use Hours instead of Points when Sprint [...]
[...] agile leaders don’t agree about estimating only tasks or only stories or both. For example, Mike Cohn recommends story points for release and backlog planning but time on tasks for sprint plan…. Well, inspect and adapt is the agile way. We tried only estimating time on tasks for a while [...]
[...] to be delivered (given a fixed release date). Several people have written extensively on agile estimating and planning and the importance of hours and story points in the [...]