Traditional 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).
[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
|cookielawinfo-checkbox-advertisement||1 year||Set by the GDPR Cookie Consent plugin, this cookie is used to record the user consent for the cookies in the "Advertisement" category .|
|cookielawinfo-checkbox-analytics||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".|
|cookielawinfo-checkbox-functional||11 months||The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".|
|cookielawinfo-checkbox-necessary||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".|
|cookielawinfo-checkbox-others||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.|
|cookielawinfo-checkbox-performance||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".|
|mailchimp_landing_site||1 month||The cookie is set by MailChimp to record which page the user first visited.|
|CONSENT||2 years||YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.|
|_ga||2 years||The _ga cookie, installed by Google Analytics, calculates visitor, session and campaign data and also keeps track of site usage for the site's analytics report. The cookie stores information anonymously and assigns a randomly generated number to recognize unique visitors.|
|_gat_gtag_UA_42152348_1||1 minute||Set by Google to distinguish users.|
|_gcl_au||3 months||Provided by Google Tag Manager to experiment advertisement efficiency of websites using their services.|
|_gid||1 day||Installed by Google Analytics, _gid cookie stores information on how visitors use a website, while also creating an analytics report of the website's performance. Some of the data that are collected include the number of visitors, their source, and the pages they visit anonymously.|
|NID||6 months||NID cookie, set by Google, is used for advertising purposes; to limit the number of times the user sees an ad, to mute unwanted ads, and to measure the effectiveness of ads.|
|test_cookie||15 minutes||The test_cookie is set by doubleclick.net and is used to determine if the user's browser supports cookies.|
|VISITOR_INFO1_LIVE||5 months 27 days||A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.|
|YSC||session||YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.|
|yt-remote-connected-devices||never||YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.|
|yt-remote-device-id||never||YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.|
|COMPASS||1 hour||No description|
|cookies.js||session||No description available.|
|S||1 hour||No description available.|