Comments on: Why I Don’t Use Story Points for Sprint Planning

By: Mike Cohn

Mike Cohn — Tue, 10 Jan 2012 02:59:30 +0000

Hi Andy–
What I recommend these days is that teams start with story points by defining them that way if they need to. A lot of people need that definition to get started with points. Once I can get a team started I try to no longer talk about days. I want people to think in days–that’s fine–but I’d prefer that discussion amongst team members be more abstract–”this one is the same size as that one and it’s twice as big as the other”.

And, yes, I continue to recommend that teams estimate the product backlog in points and the iteration backlog (tasks) in hours. Using separate units for those remains a good idea.

By: Andy Long

Andy Long — Mon, 09 Jan 2012 16:19:09 +0000

Hi Mike,

I’m just going over your book, “User Stories Applied” again and on page 87 you mention that your preference is (or at least was) to treat a story point as an ideal day of work. Is that still the case?

Also, in this article you say you use story points to plan the product backlog and hours to plan the sprint backlog – so would it be right to assume you are using days to estimate the product backlog because it is at a high level and hours for story tasks at the more detailed sprint planning level?

By: Mike Cohn

Mike Cohn — Mon, 22 Aug 2011 03:06:11 +0000

Hi Nicholas–
I’m glad you’ve found the discussion here helpful. So have I. And, yes, it’s the best part of the blog.

As for when to estimate the product backlog: Please see the post titled “When Should We Estimate the Product Backlog.” It should answer your questions.

By: Nicholas Tuck

Nicholas Tuck — Sat, 20 Aug 2011 03:06:19 +0000

Hi Mike,

Thanks for having all of this discussion with everyone, the discussion is nearly more valuable than the article for me at this point.

We have had a lot of questions about story points and how to use them and I am heavily leaning toward your approach here. My latest struggle is when and how to have the planning poker for story points. New stories will come on during a sprint by the PO and Scrum Master, and will require story points assigned by the team. When does the team get together to discuss? Obviously not defined in the Scrum process but do you have any recommondation or past experience?

Is it better to setup weekly meetings for any/all new stories, maybe time boxed? Some have suggested after the Sprint during the inevitable down time surrounding the Sprint Review and Retrospective meetings. This suggestion doesn’t make a lot of sense as the PO needs to know the story points for relative priority and planning, he/she should have more than one day to consider the latest points.

Again thanks for your input!

By: Mike Cohn

Mike Cohn — Sun, 24 Jul 2011 02:04:57 +0000

Hi Mike–
I wouldn’t generalize to say that “having developers estimate these [story points] is problematic, since they struggle with the concept” as many developers find the approach much more palatable than a large WBS and estimates in hours.

Story points are quite different from a WBS because story points are associated with user stories (or more generically a “product backlog item”) which will typically be worked on by 3-5 people, unlike a task is a WBS which is worked on by one. Additionally, smaller is definitely not the key difference. One of the biggest differences is that story points are relative. I suggest looking at the “It’s Effort, Not Complexity” blog post (and its many, many comments), and, of course, the Agile Estimating and Planning book.

By: Mike Stallfus

Mike Stallfus — Fri, 22 Jul 2011 17:46:27 +0000

Mike,
Of all the agile practices, i have struggled with story points the most. Having developers estimate these is problematic, since they struggle with the concept. And based on this blog I am now reading that the Story Point is used as a high level/big picture estimating technique with hours used for the sprint planning. So how is this different then the classic Work breakdown structure analysis with the nebulous “work package” (8-80hrs)? Granted, story points should be smaller then 80hrs but the strategy is the same. And once the work (story points) package is defined the task of the project team is to decompose it into actual tasks and hours. If a PM is any good at all he is doing wave (sprint) planning, which means we revisit the estimate and scope after each wave. So how are these story points different the work packages with hours defined between 8-80? Smaller is the key here?

By: Biju

Biju — Tue, 12 Jul 2011 17:11:21 +0000

Another question that I have (again with a team that’s pretty new to Scrum)….when in a sprint does the team get a look at the stories for that sprint? On day 1 during planning? or even earlier (grooming)? If it’s on day1, then how do we expect the team to come up with tasks and estimates right away? Wouldn’t people want to understand the story in detail to give accurate estimates? Maybe the question then really is, what’s the percentage of accuracy we should expect in task estimates and does Scrum advice we buffer it a bit?

By: Biju

Biju — Tue, 12 Jul 2011 17:08:18 +0000

Hi Mike,

Thanks, I agree with it in theory. However, wouldn’t this skew up release plans? The story points are assigned, usually, at the release planning stage. So, based on previous trend, we would have estimated a certain velocity for a team and hence while planning for the new release, arrived at certain timelines. So, in theory would you suggest that for every new team/or new release, we do the story point exercise only after 2-3 sprints to understand the trend? Or we do the story points early but start doing the timelines planning (high level, of course) only after few sprints of the release are done and average velocity is gauged?

By: Mike Cohn

Mike Cohn — Tue, 12 Jul 2011 14:42:54 +0000

Hi Biju–
Story points are awarded all or nothing. In the 3rd sprint (in your example) the team gets all the points for the story. They get none in the first two. This will have a couple of side effects, both good:
–the team will start using smaller stories
–velocity will be under, rather than over, estimated, which will avoid falsely optimistic plans.

By: Biju

Biju — Tue, 12 Jul 2011 08:06:09 +0000

Hi Mike,

Thanks for that, makes sense. It would be very useful to let the folks get a hang of things before diving into the story points.

Another question…We assign story points to a backlog item/story. However, what if that story runs across sprints (let’s say the effort needed in terms of hours adds up to 3 sprints)?In such cases, how do we measure the velocity for the sprint? Cause velocity is based on story points for the entire story and we completed only a part of the story in sprint 1.