Estimating user stories is one of the most hot topics in the Scrum world. Questions like "How we do it?", "What is a story point?", "Does it mean time?" and finally what we gain by having story point estimations using size is something that I will try to analyze in this post.
Before we talk about story points, lets have a look to the distinction between size and time. In terms of physics this is pretty straight forward but in software development both are used to predict releases. So people tend to give priority to the question "How long will it take to do the that?". To answer that I will use a similar story founded in Mike Cohn's Agile Estimating and Planning book.
Let's say that I m near to a very small swimming pool and you ask me how long do I need to pull out the water and put it an empty pool 30 meters away. I look to my equipment and I see that I have one bucket and a rope and I say to you that it will take me 16 hours. What I did is to skip size estimation and go directly to time. If choose first to estimate the size, then I would try to calculate the capacity of the swimming pool. Lets say that I estimated that the pool contains 10.000 liters of water.
This alone does not answer the question "How long will it take to do the that?". I take a look on my bucket and it says that it can be filled up with 10 liters. Dividing 10000 liters by 10 liters gives me 1000 trips between the two pool filling and emptying the bucket. I estimate that every trip along with the filling and emptying the bucket is 5 seconds to fill, 5 seconds to empty and 50 seconds walking. 1 minute total. Multiplying it with 1000 trips gives me roughly 16 hours.
This approach is used in Software development too. You have the features and you try to estimate the time by sizing the features and then put estimated hours of work on them.
Defining the Story Points reference number
So what is different with story points?
Story points are a relative measure of the size of a user story. So they are relative to something. But what? In order to answer that we have to bring in the initial reference that every scrum team should have in order to assign story points in future user stories.
A user story should be small enough to fit in a sprint and not only fit, but to have space to fit more user stories if we are talking for teams with >=3 persons. Lets say that we have an imaginary user story story.
"As a HR guru I want to see the list of Employees and be able to delete them by clicking a Trash Icon placed next to the employees name."
This user story could be used to create a reference story point (number) by the team. So the team should sit together and start discussing what this story means in technical terms. Senior Developers should help Junior Developers to visualize the parts of the code that should be created/re-used/changed in order to implement this feature.
After everybody understands what this imaginary user story means in technical terms the team should put the reference number. The number must be closer to the bottom of the numbers scale. E.g if we are using planning poker then 5 or 8 its a good reference point.
The reason to use the close to the bottom number is that the user story should describe something which is not just a small change to the code/test/etc and from the other hand not an elephant that we need to build. It is something that with a fair amount of work will produce something between small to medium and will have the following characteristics:
a) It will not need the whole team working on it on the whole sprint
b) It will produce something that it worth a review and feedback
c) Will contain multiple application layers (e.g web, services, db) changes
Again we are talking about the reference user story, not user stories in general. You may wonder why is c in the characteristics. The reference user story should expose all the application layers so everybody have the chance to understand the coding/testing and all related actions in each one of them. This will help experienced developers of one layer to get a feeling about the other layers. In future estimations everybody will remember better the reference user story since through to this analysis they will cover almost any combination of future user stories.
Working with Story Points
So we defined a reference user story and we put a number on it. Lets say 5. In the next Sprint Planning we have to do it with real user stories. The process here has two steps. The first is to analyze the user story and negotiate with the PO about his needs. The second step is to analyze the user story in technical terms and remember the reference user story. Then compare the code/tests it needs to implement (along with other actions) with the corresponding actions of the reference user story. If they are similar then the same story point could be placed on this user story (which means 5).
If it's not similar, then try to figure out how larger or smaller is this story again using the abstract size we gave to the reference user story. To do that we will have to use the size language. For example if the amount of code/tests etc we estimate that it is double from the reference user story then we will give the double size story points which is 10.
So now we are able to do estimation with size. Wait a minute... where is time? We didn't say anything about time. Correct. But time is already defined. We have 2 weeks sprint. The only thing we have to do is to see how much of size we could deliver inside these 2 weeks.
How the Product Owner will know then when the X feature will be delivered? This is achieved by knowing the velocity of the team. Which means how many Story Points the team can deliver in one iteration. Of course in a new team the number will not be so accurate in the beginning, but after some sprints the Product Owner will know how much the team can deliver. Then he can call the team to have a "fat" estimation of all the user stories related to feature/s or to release/s.
So if the total user story points is 1000 and the teams velocity is 30 for 2 weeks sprint then the feature/s will be done after 66 weeks. That's the best planning that can be done for the moment and that's a fact. The rest Project Management pre-filed excel sheets are just WISH lists.
Common pitfalls when estimating
It very easy to start thinking of time when you are doing estimations. To prevent this, a reminder should be placed saying that you are estimating size related to the initial reference user story. If you forget that then estimation points will be shifted. In every user story try to remember to compare first with the reference user story and secondly with other user stories that you estimated correctly in the past. This will keep you in the correct size estimation track.
A potential danger when you forget to estimate using comparison, is to reduce the size in a similar story that you did in the past just because you feel comfortable of having all the knowledge and experience to implement. The size is SIZE, not time. If the same amount of things will happen to implement in this story, even if you hands will code faster, the same story points should be placed. This will reduce the teams effort to estimate since it will be easier to place in the same "bucket" (story points) similar stories than having people try to understand and convince the other developers how much comfortable they feel to implement the similar story.
Integrity in sizing will help also the Product Owner to understand his user stories better by comparing the requirements and the points. This informal feedback could lead the Product Owner to write better user stories it terms of size without extreme need of refining.
How velocity increases
I mentioned before that it is possible that a user story which has the same size with a previous one, to be implemented faster. That is normal, and it is a disconnection of time with size! This will happen because the developers are getting more experienced sprint by sprint and comfortable with the code. So the velocity will increase by taking more stories in each sprint because the team will need less time for the same size stories since will be more trained and know the system better.
Can the velocity decrease without changing the persons or anything else? Yes it can. Sometimes you may have to estimate a story that it seems similar to another one but the logic or the business requirements that it needs to be implemented are complex. In that case the amount of actions remain the same, but the code logic is more difficult for the developers to capture. So this could lead to a velocity decrease in that Sprint. But again calculating the velocity mean using multiple sprint outputs will give a correct velocity which will be safe enough for the Product Owner.
Of course the velocity will not increase forever. And in matter of fact if major changes in velocity are happening between multiple sprints then something is wrong. Velocity should stabilize after some months. Continues increment means that either the team is burning and the deflation its a matter of time, or that the team keeps the sizes but reduced the actions such as tests and quality assurance. This is not acceptable because DONE means DONE and includes quality. :-)