Tomas Gutierrez, Partner at Scalable Path gave a detailed description of the Storypoint Estimation Scale they use at his company while answering a question on Quora. I think the way they use this has great value for any team that is thinking about improving their own estimation process. It is fast, simple and meaningful and you can take it as a base to create your own scale definition.
Like many teams, they are using story (or agile) points to assign a common definition to the effort required to complete tasks/stories. Their exponential complexity scale is based on the modified Fibonacci Sequence – 0, 1, 2, 3, 5, 8, 13, 21. This definition of complexity should be shared by a whole team, from developers, product owners, executives, to anyone else who’d like to understand the nuances and complexities of creating something with this team. The scale will allow you, your team and your organization to have visibility into timelines, complexity, budget, and staffing.
Here is how they interpret story points in our projects and de-couple effort from hours.
0 – Very quick to deliver and no complexity; on the order of minutes
– One should be able to deliver many 0’s in a day
– I know exactly what needs to be done, and it’s going to take me very little time
– Example: Change color in CSS, fix a simple query
1 – Quick to deliver and minimal complexity; on the order of an hour+
– One should be able to deliver a handful of 1’s in a day
– I know exactly what needs to be done, and it’s going to take me little time
– Example: add a field to a form
2 – Quick to deliver and some complexity; on the order of multiple hours/half-day+
– One should be able to deliver one 2 comfortably in a day
– I mostly know what needs to be done, where improvements/changes need to be implemented, and it’s going to take me some time
– Example: Add a parameter to form, validation, storage
3 – Moderate time to deliver, moderate complexity, and possibly some uncertainty/unknowns
– On the order of about a day or more to deliver
– I have a good idea what needs to be done, and it’s going to take me a bit of time
– Example: Migrate somewhat complex static CSS into a CSS pre-processor
5 – Longer time to deliver, high complexity, and likely unknowns
– On the order of about a week or more to deliver
– I know what needs to be done at a high level, but there is a good amount of work due to complexity/amount of development, and there are big unknowns we’ll discover as we get into the work.
– Example: Integrate with third-party API for pushing/pulling data, and link to user profiles in the platform
8 – Longer time to deliver, high complexity, and likely unknowns
– On the order of a couple weeks+
– I understand the concept and the goals, but it will take a while to deliver due to the amount of work, complexity, and unknowns
– If we have an 8, we should break them into smaller tasks/issues with smaller point values and minimize the complexity
– This might require a Spike to architect/remove uncertainty or be created as an epic with more granular stories within it
– Example: Overhaul the layout/HTML/CSS/JS of a web application
13 – Long time to delivery, high complexity, many critical unknowns
– On the order of many weeks/month
– Similar to an 8; this should definitely be an epic and requires discussions around how to accomplish
– Example: Migrate application from the outdated data store to new DB technology and ORM
21 – You’re doing this wrong…
As you can see, this is not clear-cut and leaves much room for interpretation. Estimating software development is difficult, and there are many factors to consider, including complexity to develop given existing architecture, team availability, business priorities, unforeseen third party complexity, use of CI (Continuous Integration), automated testing, etc. What teams should strive to do is build a culture where there is a good grasp on the solution, and all agree on definitions for the level of effort required to deliver each piece of functionality, task, bug fix, etc.
