Backlog estimation done right
This is about the the good and the bad of estimating backlog items. Why should you estimate, and why not? What benefits do you get if you do it, and what risks do you face?
Why should you estimate a backlog?
Estimating a backlog provides certain benefits and draw backs, which I am pointing out in this article. Some of the benefits you might experience when estimating a backlog:
Be able to prioritize a backlog: There are various ways on how to order a backlog. This can be related to risk, value or even personal preference. If you know the workload or complexity of a backlog item, it will provide insights for you to be able to choose a certain order.
Compare teams performance: If you follow the amount of work which is done in a sprint, you can choose that number to compare the workload for the next sprint planning. If there is a significant difference, you might need to question the workload.
Estimate delivery time: If you have done a few sprints, and you have an estimated backlog, you can interpolate how much time you might need to get a certain set of features done, or alternatively how much you get done at a certain point in time.
When should you estimate?
Simple as this: Don’t estimate a backlog, if it doesn’t provide any value to you.
If you estimate a backlog, but you are not changing any activities based on the results, estimating backlog items is a waste of time.
High Level Estimations vs. Backlog Estimations
In some cases, having a very rough estimate on larger tasks is helpful, so you know that a certain task takes month instead of days. This might result in removing it from the backlog, as the value it provides is rather low.
While having the backlog cleaned up by that rough filter, you might make sure that anything else in the backlog is important enough to be developed. If there is no additional benefit for estimating all tasks, you should spend the time on other things.
Only estimate where it provides value to you.
Estimate in abstract numbers instead of hours
People tend to use hours or days for estimations. This is obvious in the first place, because you want to know how long it takes to do a certain amount of work.
Estimating hours and days is bad
First of all: How often have you estimated how long it takes to finish a certain task, and how often did it turn out right? If your answer is -almost always-, then you are probably one out of very few people who can say so. Consider yourself very lucky.
Estimating tasks is really hard, especially if you are working on the edge of things. It tends to get more easy for repeating tasks.
So why are time based estimations real bad? Here are two examples, which I consider the most relevant:
8 Hours: Let’s consider a task, which would roughly equal to 8 hours. As we’re mostly working in 8-hours-a-day environments, we would also expect the task is done in one day. But that is not realistic. You have a daily standup, co workers have questions regarding a certain task they are working on, anything like that. You might end up with an effective amount of 6 hours work if you are lucky. So finally, each time you are working on an 8 hours task, which equals to a days task, you are not able to finish it. If this is the case, people are under constant pressure to finish a days task in a day, which would not be possible anyways. To avoid that situation, often people tend to work overtime to be able to deliver.
Estimates equal to time boxes: Consider a team of developers working out time estimates for certain tasks. There is always a difference in estimations, and the team will negotiate for one estimate - most likely to that of the more experienced people. Then there is one developer working on a specific task, who is now „bound“ to that estimate. Imagine you figure out time is half way through, but the work is not close to that. The developer is now in a hurry, which produces either two things among others: 1: You spend some of your concentration on „I am in a hurry, how can I manage to get it done in the given timeframe?“, while you have better spend your concentration on your work. 2: You try to finish a task in time, which will result in less quality, less documentation or anything like that. You want neither of that.
Use abstract numbers for your estimations
The solution is to use abstract numbers. In Scrum, these are usually called story points.
Now, that we got rid of hours and days, how do we estimate a certain task? We can do that by comparing tasks, and relate them to each other. Relating tasks can be done by either:
Workload: You estimate the workload of a certain task and relate that to another one.
Complexity: You relate your tasks in terms of complexity.
Example: Imagine we have to implement google analytics, we might give it a relative number of 2. The other task is adding social media meta data to a page, which is a bit more work, so we estimate it as 4 points, as it is roughly twice as large.
The main difference is, that we are not asking the team on how long it takes, but rather we are asking how big it is, or how complex.
Find a scale for the estimation process
Basically you can choose whatever you feel comfortable with. You can just use a simple 1-10 scale. In the agile world, these two variations are pretty common:
T-Shirt-Sizes: The number of T-Shirt-Sizes are pretty limited, which might be good for your case. So your estimates are like S, M, L, XL. I pretty much like this variation, as it keeps things really simple, and also not too specific. It leaves room for interpretation, and everyone knows how to handle it.
Fibonacci-Numbers: Fibonacci Numbers are also great for estimations, as the room between the numbers increases the larger you get: 1, 2, 3, 5, 8, 13, 21, 34. The idea is the following: The larger your estimation is, the more unprecise it is as well. While you can pretty good estimate a difference between 1, 2 and 3, it will be really hard to differentiate between 13, 14 and 15. This is my favorite estimation method.
In any case, you need a reference system. How would you know if a certain task is a 3, a 5 or a 21 (Same thing for the T-Shirt-Sizes)? For getting a common understanding, you have to choose a common task, ideally with a lower complexity / workload, and choose that as a reference. Then you figure out how other tasks relate to it.
So how do we get to good estimations? I suggest to estimate as a team as much as you can, as it has certain benefits:
Share knowledge: If you estimate as a team, you will figure out, that people have different estimates on a specific task. Now the team can discuss it, which will result in sharing knowledge about a certain domain. Junior people will be able to pick up knowledge, even people from other domains will get an understanding on workload or complexity of certain tasks. I am always recommending to estimate tasks with people from different domains.
Make things clear: If you discuss a certain task with the team, often it shows different understandings about the same task, which can then be solved. Also problem might come up wich other team members didn’t see. So the team will also benefit from the experience of individuals and learn from that.
Comparing planning poker with other estimation methods, The problem with estimations is, that less experienced or more introverted people might just follow the more experienced people in their opinion. So it does possibly not show different understandings right away. To solve that, there is planning poker, and it works like this:
Choose a story: From the backlog, choose a specific story you want to estimate. If people have questions, discuss it.
Choose a number: Everyone in the team chooses a card from his planning poker set (i.e. Fibonacci Numbers).
Compare the numbers: At the same time, show it to anyone else. This way, no one could be influenced by others, but have to do their own estimations. It also ensures that less engaged people in the team are also equally engaged.
Negotiate: Now if there is a difference in estimations, discuss why that is. As the team member with the highest and lowest rating, why they think so. This process might show different understandings of the same task, which you can then solve.
Risks on backlog estimation
Estimating a backlog is always a very subjective issue. The specific estimate on a certain backlog item is affected by all sorts of different factors.
Personal insights: Your view on estimating a certain task is influenced by knowledge and experience.
Optimize metrics: If there are metrics on how many story points you finish in a sprint, people might (not on purpose) change numbers to produce better metric results.
Split stories: People might split stories to achieve more story points at the end of the sprint.
Finish things early: To get a certain metric result, stories might be finished early so that it is taken into account when finishing the sprint. This could lead to bad quality, missing documentation or anything like that.
All of these are possible results of estimating and measuring backlogs and team performance. Some of these might be done unknowingly by the team. Everyone in the team should know about these potential conflicts, but especially the Scrum Master should keep an eye on these kind of things.
Estimations are not providing any value on it's own. They are part of something bigger. Among others, these will be some topics, I will write some blog posts for as well. Just follow this blog, if you want read a follow up.
NoEstimate: The NoEstimate movement is quite interesting, as it spends more time on the work itself, less time on estimations. Still this might not always work, but I'll go into that later.
Prioritisation: The obvious reason for estimations is to be able to prioritize your backlog items. There are many different methods for it, and I'll get into detail of some of them after sketching an overall picture.
Metrics: Estimations can be used to measure the performance of the team. I will get into Burn Down as well as Burn Up Charts, and why they could be of great help for you.
Estimations can be a valuable tool for all sorts of things. In any case, I personally like to base the decision on how much of the backlog items should be included in a sprint on the teams feeling instead of counting on story points. The team should feel well and capable of getting all stories done, which has a much higher value than risking a sprint where we are not able to reach our goals and demotivate the team. This works very well in my experience. To be able to do so, the team needs to work out a good impression on the stories as well as the product, which might take a few sprints.