Estimations in Agile development – Estimating the Backlog with Story Points

This is the second post in the Estimations in Agile development series.

Epics, User Stories and Tasks

Estimating User Stories with Story Points (you are here)

Sprint Planning Methods: Capacity vs. Velocity vs. Feature

Improving Estimations using Burndown, Burnup and Actual time metrics
In the previous post I’ve introduced the different product backlog items, their hierarchy and scope.
In this post we’ll learn how to estimate user stories using story points. I’ve introduced the videos website project that I’m building. This is its current epics backlog:

Story points
We need to estimate those epics, but how? The trivial option is time. We usually estimate effort in time “It takes two hours to get to Tel Aviv”, “The renovations will be over in a week”. However, it is extremely hard to estimate long term effort in time.
Let’s look at the first epic Allow users to find, play and comment on videos. This is obviously a lot of work. It is more than a week and probably less than a year. Every time driven estimation won’t be accurate. It is hard to estimate accurately something that is longer than a week. Months? Impossible. We need something else.
When estimating long term effort we should use a more relative unit like size or complexity.
These units allow us to easily compare features by their size or complexity. “This one is 2 times bigger/more complicated than this one”. It allows to easily separate the complex features from the easy features or from the small ones to the large features.
Since the units are relative to one another we can choose any numeric representation that we want. We only have to stay consistent while using it.
It can be 1,2,3 story points when 1 is super easy and 2 is harder, or 10, 20, 30… . It doesn’t really matter and that is the beauty in story points. Personally I prefer reflecting size in story points. “How long does it take to get from Tel Aviv to Herzelia? Same as getting from Tel Aviv to Holon which is 2 (some relative representation of this size)”.
Another option is ideal days. “How many days will it take if the days have absolutely no distractions?” The problem in this way is that yet again it is time based and we suck in estimating long term in any time based method. Hence it is not recommended.
Prioritize, estimate and prioritize again
The backlog will be constantly prioritized and changed due to business requirement, estimations and new discoveries along the way.
In order to properly prioritize we need to have the business prioritization along with the estimated R&D effort. Usually it will take 3 rounds:

1. The first one is a “business prioritization” round. The product manager will prioritize the epics based on their business values. What feature does the user must have first?
2. The second round is a “technical effort estimation” round. The R&D will go through the list of epics and spot the ones with the highest level of uncertainty and risks. We don’t want to leave the unknowns to the end – we want to tackle them from the beginning in order to increase our level of certainty in the required effort. Unknown effort usually is a big effort, hence its story points value will be big.The recommendations epic has many uncertainties like introducing intersects into the system and understanding what videos the user will actually want to watch. It seems like it is 3 times bigger effort than the other two epics. We’ll estimate it with a value of 30 while the other epics are 10. The cool part is that it doesn’t have to be “3 times bigger” it can be 5 or 10 times bigger. It is relative. It means that a new epic will have an estimation that is relative to the previous ones: is it “more like” the big one (30) or more like the first one (10).
3. The third and last one is the “business prioritization” round again. This time the product manager sees the required effort for all the epics and decides whether some of the highly estimated epics should be moved higher or lower in the backlog. Perhaps if a feature is so difficult to implement then it shouldn’t be implemented at all. Our product manager is fine with our estimations and he decides to leave the epic in its current priority. The first two are more valuable than the recommendations.

This is our current estimated backlog:

Estimating User Stories
The epics are prioritized and estimated. Now what? We can start all the epics simultaneously but then it will take us much longer to finish the first one as opposed to focusing only on the first epic. Keep in mind that every epic has a real value to the user hence we want to decrease the time to market of every epic. In order to achieve that we must strive to start only a single epic at a time. There is a great phrase that one of my managers used to tell “stop starting – start finishing”. We should strive to focus on the most important feature first. Finish it and only then move to the next one. The feedback that we’ll get from real users might change our initial priorities.
Now it’s time to split the first epic to user stories. We’ve done it already in the previous post:

The estimation process of user stories is identical to the epics. User stories also give actual value to the user, hence we need to deliver the feature with the most value first. Watching videos in a video library application is probably more important than commenting or searching (without videos to search or comment on).
Now it is time for technical estimations round using story points – same as before. In this case the first user story is bigger than the other two since this is the first feature. We need to build the application’s first screens, create the project, build continuous deployment (hell yeah! From the start) and allow to actually watch videos.

*If you try to add up the estimations you won’t reach 10. That’s alright since 2 SP and 1 SP are not equal to 3 SP. In the next posts we’ll talk about ways to sum estimated effort in a more precise way.
The filter user story has the smallest estimation since it has no persistence complexity and it feels like less effort than the other features.
If a user story receives a big estimation then it is a sign that we don’t understand it well enough or perhaps it is just too big as a single feature. In both cases the best practice is to split it to 2 or more user stories while every user story will give actual value to the user. That is exactly what I meant in my previous post when I mentioned that epics split to themes and only then to user stories. Since this is our first estimations round we still don’t know what a too big estimation is. In the next post we’ll learn how to define our limit and by doing so define when we should break the user story further more.
Time for the last business round of prioritization. This round is the most important one since it determines the next feature that the R&D will work on and that the user will see.
After we’ll complete it and deliver it to the user we’ll receive feedback that might change these priorities. This is good. Our job is to deliver what the user wants. Having a real product at his hands might change some of his first assumptions. This is why the prioritization will happen again and again. Along with the priorities the estimations will also change. Something that we thought was 2 S.P. appeared to be much easier or much harder and it is no longer should be like other 2 S.P. user stories. It may sound depressing to constantly re-prioritize and re-estimate the backlog, however, this is the only way it will truly reflect the product.


Starting the sprint
We know the user story that we should work meaning we are ready to start our sprint. The sprint starts with a “sprint planning meeting”. In this meeting the team splits the user story to technical tasks and estimates them.
Should we also use story points for estimating tasks?
How do we know that we filled our team’s capacity?
What is capacity?
How do we improve our estimations?
All that and more in the next post.
 
Estimations in Agile development – Epics, User Stories and Tasks
Estimations in Agile development – Estimating User Stories with Story Points (you are here)
Estimations in Agile development – Sprint Planning Methods: Capacity vs. Velocity vs. Feature  (go here)
Estimations in Agile development - Improving Estimations using Burndown, Burnup and Actual time metrics