# Do we need story points?

I want to share my solution for quick estimates, which is meant to be implemented in a Scrum team, but it might be used to improve a Kanban process too. I'll explain my idea in a minute, but let's take a step back and talk about Agile principles in general for a moment.

I think that we can summarise the fundamental principles of Agile in just one sentence: Agile means delivering working software incrementally with short iterations, while adding value for the customers, constantly adapting to changes, and encouraging communication. This sentence contains the key concepts of Agile which I assume you are familiar with: iteration, increment, working software, customer value, adaptation, and communication.

The idea of iterations in particular implies that we have to break down a large activity into small activities, prioritise the activities in such order that we increase the customer value delivered with the increment, and select a reasonable amount of activities which we can complete by the end of the iteration.

People practising Extreme Programming came up with the idea of Story to define the work which needs to be done. They also defined the concept of Story Points for estimating the effort required to complete a story. Moreover, story points can be used to limit the amount of work that we can select for a single iteration and ultimately they make long term planning possible.

This is how it works: Before starting a new iteration, we select few stories from a prioritised product backlog, we add enough details and we estimate each story using story points. At the end of the iteration, we compute the total number of points of completed stories. We use that number to limit the amount of stories that we select for the next iteration. It might happen that we select too many or too little stories for one iteration, in that case we adjust the limit when we select the stories for the next iteration. After few iterations we can evaluate the velocity of the team as average number of completed story points.

Some people recommend to use Fibonacci's numbers as story points values, such as in the sequence 1, 2, 3, 5, 8, 13. The idea behind Fibonacci numbers is very clever: Since the gap between numbers increases not linearly, Fibonacci's numbers account for uncertainty. The higher is the number, the bigger is the story, and the more uncertain is the estimate.

I really like story points and Fibonacci's numbers, but I have never seen them been used properly. Either I have been very unlucky, or estimating stories with story points is more difficult than expected. In my experience, very often the composition of the team is not stable for long enough to reach a steady state, or the team's members have very different skill sets and they are not able to estimate work on a different tech stack. I have seen people implicitly reverting to time estimates, when they say that 3 points means 2 days, but time is very subjective and it makes more difficult to reach an agreement in the team. Last but not least, more often that it should be, the backlog contained too many large stories which didn't have enough details or were missing acceptance criteria.

A partial solution for simplifying estimates would be to limit the sequence to 2, 3, 5, 8. Alternatively, we could replace numbers with T-shirt sizes, such as S, M, L, XL. Reducing choices mitigates some problems, but it doesn't help to make sure that stories have enough details and to increase the accuracy of the estimates.

## What solution do I propose?

My recommended solution is to break stories into small tasks and visualise stories and their tasks on a board during a planning meeting to emphasise the relative size. You can easily visualise stories and tasks on a whiteboard creating a rectangle or a circle for each story and adding a post-it note for each task of the story, like in this example:

The most important thing to understand is that we must agree on the relative size of the stories, and forget completely about time. Even people with different level of experience or different skill sets can easily agree on the relative size of the stories, especially when they visualise the stories.

The crucial step is breaking down large stories into tasks until the tasks are small enough. In this context, small enough means that each task should not take more than a certain amount of time. It might be different for every person, but in general it should be much shorter than the duration of one iteration. Just keep asking yourself if you can still break down a task, and stop only when everybody in the team agrees that the tasks are small enough. As additional benefit, creating tasks helps clarifying the stories.

This is how it works: Before starting a new iteration, we break down each story into small tasks until they are small enough. At the end of the iteration we compute the total number of tasks completed. We use that number to limit the amount of tasks that we select for the next iteration. It might happen that we select too many or too little tasks, in that case we adjust the limit when we select the tasks for the next iteration. After few iterations we can evaluate the velocity of the team as average number of completed tasks.

Please note that a story can have just one task or many tasks, and perhaps it can't be completed in one iteration. In case that a story is too uncertain and we find difficult to define tasks, we can create a spike to clarify the story before the next iteration. The spike is time boxed, therefore it is small by definition.

Also note that the conversation about a story happens when the story is decomposed into tasks. The team doesn't need a discussion about story points anymore, because they can be inferred automatically from the number of tasks. Just apply a simple conversion: for a story with one task assign 2 story points, for a story with less than 3 tasks but more than one assign 3 story points, for a story with more than 3 tasks but less than 5 assign 5 story points, for a story with more than 5 tasks assign 8 story points.

This solution has the benefit that small tasks can be worked in parallel and delivered quicker than large tasks, increasing the opportunity of feedback. Moreover, the accuracy of the estimates increases because small tasks provide finer details about the story.

I strongly believe that the solution I described reduces the time spent on planning meetings, but also increases the accuracy of the estimates, and therefore it makes the estimates more effective. When we have good estimates, then we can make better long terms plans based on the team's velocity. I can't prove it because I don't have statistics, but I recommend to give it a try, since it can't hurt you!