Not always used and understood by the whole team, story points are a great way to quickly determine the complexity of a task along its entire life: definition, development, testing and deployment. When working on an agile approach, tasks are created in the “to do” list without always knowing all the details about it. A typical example would be something like: “I want to change the header logo” or “The page needs to incorporate three more fields”.
For those tasks to become actual requirements, there is a journey that includes better definitions, acceptance criteria, discovery, a testing strategy and a real estimate. What our PM would ask for is a “guesstimate”, some sort of effort measure for the task. Although we know very little about the task and the implication and ramifications, we should be able to assign to it a certain level of complexity. And here is where Story Points start to make sense.
It is as simple as having a scale in mind, and adding a number on that scale to the stories. The higher the number, the more complex the ticket will be. This doesn’t only apply to development but to the whole process: if a task is about to change a line somewhere in the code, but the test cases to be run are multiple, then the complexity of the task is high. Same criteria applies if the definition is complex but the solution is not.
How does the scale work? As complexity increases exponentially in some cases, the Story Points scale is represented by the Fibonacci sequence, in which a new number in the scale is just the addition of the previous two. This is to draw everybody’s attention to a task that has a high number of story points assigned to it.
| Story Points | Complexity | Rough estimate |
|---|---|---|
| 1 | Very simple task | Half an hour or less |
| 2 | Simple task | A morning |
| 3 | Standard task | Half to full day |
| 5 | Average to complex task | 1 or 2 days |
| 8 | Complex task | 3 days to a week |
| 13 | Very complex task | Up to the whole 2 weeks sprint |
If a task is heavy (maybe 13 SPs or higher), the recommendation would be to split it in various smaller tasks that all combined may or may not add up the same number of Story Points. Finally, based on the weight each task has, the Project Manager will determine which ones shall be part of the next sprint, to then go ahead and undergo the entire cycle of life of the selected tasks.
Just a final comment: the Story Points aim is not to be translated into development hours. The point is to determine the complexity a task has all across the board (to be defined, developed, tested, approved and deployed). This being said, in some projects and after a few sprints it will be likely that a team may measure the speed of a sprint in SPs.
