Story Points – What Does It Mean To You?
Concept of story points was always slightly confusing for me so I wasn’t that surprised after reading Mike Cohn’s blog post and comments that definition of story points can vary widely between different people, here a few examples:
- SP should be based on the complexity
- SP is a measure of complexity, effort, and doubt
- SP is a way to measure the size of the requirement, not the time it takes to implement the requirement
- SP are not about the complexity of developing a feature; they are about the effort required to develop a feature
- SP are “size points” and map to time retroactively
- SP do not *equal* hours because points are an estimate
- SP are an estimate of effort (“how much time will this story take?”)
It’s strange that concept which is part of agile planning and estimating for so long can be so confusing and can be understood in so many (sometimes even contradictory) ways.
Maybe definition of story points should be agreed within each team separately? In a similar way as it should be done with definition of ‘Done’ for user stories? Then for one team story point means X and for other team Y?
Personally I don’t think it’s a way to go. Ultimately after planning session we, as a engineering team, are suppose to answer one fundamental question: how much time we need to deliver the project. Therefore it doesn’t matter if you estimate in story points, ideal days, ideal hours or something else. Final outcome has to be in man-days.
If all that business care are man-days and how many is needed to get things done than maybe there is absolutely no point in using story points? Story points are confusing. Maybe we should estimate in man-days and get rid of this additional level of abstraction? I will try to answer that in my next post …
If you liked this post, you might like these, too:
I’ve got my own way around the dilemma. In my team we use “ideal hours” and estimate on the basis of an average velocity of the team.
If a team could solve five similar tasks in 40 ideal hours total, we should assume the sixth will take 8 hours. We arbitrarily assume 6 hours per day and they can be considered as story points to some extent. The ideal hours, however, reflect the team’s velocity and hence are easier to map to man-days than story points. In other words – the velocity is factored in estimates rather than in the mapping itself which makes it easier to understand.
Said that, we also need some contingency. People are not resources and same task will take different amounts of time to implement; tasks are not equal and often not clear enough to commit to an estimate. To cover that we use a “confidence factor” where tasks of low confidence should be treated as “can take twice the time” and tasks with medium confidence as “1.5 times the original estimate”.
The result seems like a fuzzy logic solution where the sprint has a ranged estimate and project managers can work towards narrowing it by reducing complexity / passing more details to the team.
What do you think about that? Would it makes sense for projects like the ones you worked on?
Jan Kuźniak
24 Jul 10 at 10:59 pm
I think you may have two major problems with your approach:
1. How do you estimate user stories in product backlog before the first sprint? Without any statistical data telling you how fast your team is?
2. For me big advantage of story points over any time-based unit is that whole team have to focus on relative size of the user stories rather than on ‘how many hours I need to get it done?’ For junior member number of hours will be completely different then for someone more senior. So they have no way to agree on particular number of hours. Yet then can agree that one user story is twice as big as other one. That’s why story points are handy.
But, when you have historical data and you know how fast your team is then additional level of abstraction (story points) is not really needed. Also I like the idea of ‘confidence factor’ and I use it from time to time. But personally I prefer estimates in ranges … pessimistic and optimistic scenario. I like to use confidence factor to validate that ranges are wide/narrow enough.
Marek Blotny
26 Jul 10 at 10:53 am
re 1) – before the first sprint the story points estimate wouldn’t tell you much in a man-days terms anyway. I estimate on the basis of my previous team’s speed with lower confidence and then adjust in next sprints. While it might not be perfect, it is a better start than a meaningless (at this stage) story point.
re 2) – now, here’s the difference. In our projects junior developers are not able to make an educated guess about the task’s size. We normally don’t estimate with whole team, but we have a role of “estimator” who then presents and briefly discusses his results with the team. Usually it’s a technical project manager, or technical lead who does that, but it varies.
While it might not be very agilely, the “estimator” has some historical data which make his estimates better (on average) even though they are time-based.
About ranges – you’re right that ranges are more flexible than a confidence factor approach, but the latter has one important advantage. It’s simpler and hence easier to understand and communicate. Low confidence = alert – either I didn’t have enough details while estimating, or the story you gave me is challenging.
Confidence factor therefore clusters stories into a few (usually three) groups: “good to go”, “could use some help”, “need attention”. Said that, I’ll definitely give simple ranges a try – but only with an educated customer / project manager.
Jan Kuźniak
26 Jul 10 at 10:36 pm
I think it’s a sensible approach, very good use of historical data.
I disagree here, actually I think you can get outcome very similar to your approach. In a different post (Story points – when can that be useful?) I have suggested a mapping between story points and mandays. This approach will you give you quite wide range but it can be narrowed by taking advantage of historical data. (again!)
For sure this is not very agilely
But it doesn’t matter so much if it works for you …
Question here: what if “estimator” will be hit by a bus? Will your team be able to keep working? My worry here is that by having one so crucial person your team’s Bus Factory equals one!
Here I have to agree, wide range by itself is not so obvious for business people (even though it means exactly the same thing). On the other hand ‘Confidence Level Factor’ is almost self-explanatory.
Marek Blotny
27 Jul 10 at 9:02 am