Fingerspell Flashcards – Done :-)
10-02-2008What is the difference between Scrum and RUP?
15-02-2008Traditional estimates attempt to answer the question, “how long will it take to develop X?” I could ask you a similar question, “How long does it take to get the nearest train station?
The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn’t depend on the person solving it, just as the distance to the train station does not depend on whether the traveler walks, runs, rides or drives to the station.
A story point is to program code what a kilogram is to sand or a kilometer is to distance: An arbitrary unit of measure which describes how heavy, far, big or complex something is.
So if we want to answer how long will it take to develop a particular software, we add up the story points, divide by the velocity, and that gives us the time. Think of moving sand: 100 kg / 10 kg per hour = 10 hours. 100 SP / 10 SP per Sprint = 10 Sprints. But how big is a story point? And how do I know what the velocity is?
If we’re measuring sand, it’s easy to define a reference kilogram. With program code, it’s more difficult. Once I played with the idea of converting lines of code into grams, 1000 lines of code = 16 A4 pages = 100g of good paper, but that’s just silly, isn’t it?
So how do we come up with our reference story point? And how do we know what velocity is?
Under Scrum, estimates are done by the team (if possible, the whole team) who will actually perform the work. So the team defines what a story point is. The classical approach is to look at list of backlog entries, take what appears to be the easiest, and declare that is a 2. Everything else is estimated relative to that task.
The thing to realize about about estimates is that they are very imprecise. +/- 50%. One technique for dealing with a cost ceiling is to define an estimate such that the actual effort needed will be <= the estimate in 90% of the cases, regardless of whether they are measured in days, hours or point.
So Story Points are usually estimated on the Cohn Scale (named for Mike Cohn, who popularized the concept): 0, 1, 2, 3, 5, 8, 13, 20, 40, 100. Why is there no 4? Well a 3 is a 3 +/- 50%, so a three actually extends from 2 to 5, a 5 from 3 to 8, etc. The difference between 3 and 4 is nowhere near as significant and between 1 and 2, so we don’t give estimates that give us a false sense of precision.
Summed together, many imprecise estimates give a total that is a remarkably accurate estimate of the work to be performed (the errors tend to cancel each other out, rather than accumulate). For this to work, the backlog entries must be independent of each other. If you estimate tasks that are dependent on each other, then errors accumulate and cascade. (See the update of 27/05/11 below).
Where does velocity come from? Before the first sprint, we guess. In the first sprint, the team accepts work based on gut feeling and discussion. After each Sprint, we measure the velocity. After two or three Sprints, the average measured velocity can be used to predict the velocity in the future, and thereby the completion date. It is also possible to derive values, like $/SP, which can be used to estimate project costs.
Story points are used to estimate items on the product backlog, i.e. items which represent value to the customer. They are not used to estimate effort to produce artificats needed by the team. In Scrum, we track progress based on results delivered, not on effort applied. So use story points to estimate stories in the Product Backlog, not tasks in the Sprint Backlog.
Used this way, the Scrum Release Burn Down Chart provides an accurate picture of the progress of the project, so management can rapidly recognize and react to the project’s progress (or lack thereof).
Story Points are not totally uncontroversial, and I’ll talk about some of the issues and alternatives to Story Points in a later post.
[Update 31/10/2010: Thanks to Christopher Messina for pointing out some ambiguities in the concluding paragraph, which I have now corrected.]
Update 27/05/2011: I have realized that two kinds of independence are critical for accurate estimates. Check out this new blog entry – The Key to Good Estimates
Update 03/12/2017: I have been using a more concrete basis for estimating stories than story points: – A concrete alternative to estimating story points in Scrum
16 Comments
Hi Peter,
I like your summary of the concepts. I read this thanks to your posting on the ScrumDevelopment Yahoo Group yesterday.
I noticed one nit for editing. You say that, in the beginning, we guess at velocity. Perhaps you meant to say that in early iterations, the team guesses at what it can deliver and therefore commit to. Velocity is only determined after some history has been established.
Regards,
Jay Conne
Hi Jay,
That is correct, and I’ve edited the article to reflect your comments.
Thanks!!
Cheers
Peter
A colleague at SAP BusinessObjects referenced your article to our team. It really helps explain the value of using what to some may seem "an arbitrary measure". Thanks for the simple yet helpful metaphor of the distance between two points versus the time it takes to travel it.
Thanks man, it was really helpful.
Do you suggest any articles that will explain in depth how to calculate the 'man power' and translate it into 'user story points'?
Hi Raffaeu,
(Sorry for the delay in responding)
It's very easy to convert Story Points (SP) in to a manpower estimate once you have some experience.
Let's say your team has 6 people and your sprints last 2 weeks (10 days), so a sprint has 60 person-days (PD).
Your velocity is the number of SP/Sprint (based on the SP-estimates of the backlog entries your team actually finishes).
Let's say the average is 20 SP/Sprint. You might be tempted to think that means that an SP cost about 3 PD's, but a sprint is a team effort, so it is better to think in terms of team performance per sprint.
So if you have a new project which your team estimates at 120 SP, dividing by the velocity of 20, you get an estimate of 6 sprints = 12 weeks, or 360 PDs.
Obviously there are additional uncertainties to consider. You might check out my talk on fixed price projects from the Italian Agile Day for more info. If you want to get into the nitty gritty, check out the Management Books, especially those from Mike Cohn, from my Library Recommendations.
Cheers & Happy New Year!
Peter
Just found your post (you come up near the top on Google when searching on Scrum Story Points!).
A very nice summary! Thanks. Will be sharing with my team.
I am confused about the statement "Story points should represent value delivered to the customer, not simply worked performed". How can one estimate represent two unrelated things?
For instance what would one do in cases where a user story is fairly trivial in regards to effort required, but is one of the most valuable features to the customer?
I thought I understood your explanation on how to use SP until that statement, but I must be missing something.
Team has carried out the first grooming in SPs, and after sprint planning, it turned out that backlog/sprint items are not that big in complexity as they seemed.
Is it a good practice to review/asign different SP values to items during e.g. retrospective meeting of the previous sprint?
Hi MT,
Absolutely. The idea is to get started, pick a reference, call it a two, the estimate relative to your "two" story.
Once you've estimated a round of stories, it's a good idea to do a sanity check and make sure that the sizings look good compared to each other.
As your team(s) gain experience, you might even develop and cultivate reference stories of different sizes and application areas. Estimates can maintain their validity across team and technology boundaries.
Just one qualification, don't worry too much about water under the bridge. Usually it's more beneficial to improve your performance than to improve your estimates 😉
Hi Christopher
Again I write "Sorry I took so long to respond…" Sigh.
And thanks for pointing this out! On reading this again, I would say my concluding paragraph was a bit ambiguous.
Story points should be associated with features on the product backlog, i.e. things that are of value to the customer or user. They should not be associated with artifacts, i.e. things that the developers need to produce something of value at a later date.
In particular, stories points are not used to estimate tasks in the sprint backlog.
I'll update the text to make this clearer.
Does this answer your question?
Peter,
I'm still in the information gathering stages, and my team still have not had the opportunity to use Scrum in its entirety on a project, so I apologize for my lack of understanding of what may be considered elementary concepts of Scrum.
I don't know that my confusion was over whether the story points should be associated with items on the product backlog versus sprint backlog. The confusion was more over whether the story points should represent amount of effort required to implement the item, or value perceived by the customer.
Originally I thought the second to last paragraph was saying that the story points should somehow represent the customer's perceived value, yet the third and fourth paragraph seemed to indicate that story points should represent effort. However, after your clarification, and re-reading the article, I think I understand. The story points represent the effort required, but they should only be applied to items where the customer perceives a value (i.e. the items on the product backlog not the sprint backlog).
Thanks for helping me understand this.
Hi Christopher,
I assign points to all work committed in a Sprint. The purpose is to scale commitments to team capacity. Full visibility of the commitment serves the team. Remember how vague points are as an estimate. These are just useful tactics to help us deal appropriately with considerable uncertainty by taping into our tacit knowledge. It's as much about psychology and epistemology as it is about the external facts. I hope I'm making sense and helping. If you want more clarification, just ask.
One other thought, for time boxed stories, i.e. research or spikes, I use an appropriate fraction of the team's capacity in points to keep uncommitted capacity visible in the Sprint planning process.
Jay
http://Www.jconne.com
Jay@jconne.com
has anyone of you read about FPA (Function Point Analysis)? Its sad that the new age software engineering practices are reinventing the wheels. Though I am not a fan of FPA and have seen it unfit for most of the projects using new technologies, the idea behind FPA is something which is most logical when it comes to 'sizing' of a feature or a product – an absolute measure which can be factored into other metrics like no. of hours using company specific historic data like dev. productivity when using JAVA or .Net for a single Function Point.
I think by story point, we really are doing the same thing… trying to capture an absolute measure for a feature so that we know how big/small it is. Directly relating it to no. of hours may not be that simple equation since it depends on many factors like which technology, how productive the team is etc.
Hi Amit,
Of course we have read the literature and yes, FP's and SP's are quite similar. They are both trying to assess of the size or complexity of the problem, rather than analyze work to be performed.
The difference is simple: Story Points are cheaper. Planning poker (or the newer 'Affinity Estimating') have proven to be effective ways to quickly get good idea of how expensive the desired features are.
And… directly relating the points to a number of hours is not the point. The variation in individual estimates is quite high. But the sum of the estimates gives quite a good picture of the total cost of a large set of features (which can be mapped into team-weeks, person-days, dollars and cents or whatever your preferred unit of measure is).
Cheers,
Peter
Yes, and… the article is basically nonsense, a regurgitation of the same old Scrum religious hogwash, that is swallowed again and again without any kind of understanding or taste.
Let me remind the reality-challenged that physical measures are not monopolised by substances. Volume is not beholden to the domain of sand and distance is not
a prisoner of roads. Let me further recall these people to terra firma with the observation that none of these measurements are arbitrary – they represent the framework in which humanity operates.
When people ask for estimates they want to know how much of something they can expect, in terms of volume, of distance, of loudness, of pleasure, of cost in dollars, of time.
These measurements are commonly understood by all. They have roots in empirical evidence. They are the culmination of enlightened thinking, of scientific study, of philosophical and economic literature. They are easily communicated, they are accessible by all. They are not arbitrary, and they cannot be dismissed.
To introduce a non-physical, non-temporal, non-economic, non-accessible, non-universal measure with no significance outside the scope of a narrow community, no convertibility to other metrics, and no usefulness outside the mutual relativity of a small "scrum" of people's view of a small set of requirements, and then expect the whole world to adopt this groundless metric, is an arrogant and futile endeavour.
You know, some people do have problems with the vagueness of story points. Others believe estimating is a waste of time and should be dispensed with.
I have seen countless projects in which estimating with planning poker and story points has worked quite well. It's more about the discussion among the team and stakeholders and building the common understanding, than about the number itself. Although being able to say with confidence "this story is small enough to implement in one sprint" is a very useful result of the discussion.
However if you don't like or don't believe in story points, by all means, do not use them! It's much more important that you believe in what you are doing than that you use somebody else's 'best practice!'