Estimations​ ​in​ ​Agile development​ ​-​ ​Improving Estimations​ ​using​ ​Burndown, Burnup​ ​and​ ​Actual​ ​Time metrics

This is the fourth and the last post in the Estimations in Agile development series.

1. Epics, User Stories and Tasks
   
2. Estimating User Stories with Story Points
   
3. Sprint Planning Methods: Capacity vs. Velocity vs. Feature 
   
4. Improving Estimations using Burndown, Burnup and Actual Time metrics (you are here)

In the previous post we’ve discussed the different methods for the sprint planning and the benefits of using absolute units like hours for estimating small efforts in a known time frame - the sprint.
In this post we’ll see some metrics that will help us verify and improve our estimations over time and even allow us to predict whether we’ll achieve our long term goals.
 

Burndown

After we finish estimating all the tasks we can create a rough estimation regarding the amount of work that has to be done (according to the daily capacity) in order to finish all the tasks on time.


The green line displays that available capacity for a current day. In other words – we need to make sure that our remaining work for the sprint is below the green line. Otherwise we won’t complete all the tasks on time.
Each day developers should update the “remaining work” field for their tasks – how much time is left for finishing the task. That metric will allow us to know whether we’ll finish all the estimated tasks or not.
The burndown might go up when new tasks are added or new information is discovered during the sprint.
The remaining work should be updated daily and the team should look at the chart in the daily stand up meeting. In this event we can easily see that our estimation are not correlating with our actual performance. The impact is clear: if the team proceeds with the current phase they won’t finish all the planned tasks for the sprint on time. Hence the user won’t receive a working product.

In this very moment the team should decide on the action to make the chart to convergent.
They can decide on giving some extra work to close the gap or perhaps remove the least prioritized task from the sprint – this is of course done with the product manager who is the stakeholder of the sprint.
The burndown chart is a daily feedback tool. it is effective only when it is updated on a daily basis. it is also another reason why I think one should use hours and not story points for the sprint’s tasks. when working with story points you don’t update the remaining time - you don’t change 3 SP tasks to 1 SP task, you simply work on it until it’s done. This way the burndown will not reflect your actual progress daily and it will be hard to understand if you are on track.

Actual vs. Estimated - Improving the team’s estimations

Even in a two weeks sprint we cannot know everything. Something will always surprise us. A larger than estimated task, an external requirement, un-expected technical support and more. Sometimes there is absolutely nothing we can do about it, however sometimes we can learn from these unaccurate estimations and correct them in the future. Therefore I suggest another metric which purpose is to compare our initial estimations to our actual performance.


After finishing a task, the team member will fill another field “Actual Work” with the actual time that took him to complete the task. This way we’ll create another graph that will compare the planned estimation to the actual one,  Allowing us to see which tasks were underestimated, overestimated and which were exactly as we predicted. Our purpose is to minify the gap between the actual and the estimated. ”why did the task take longer/less than we estimated? Could we do something in order to predict it?”  This graph is a great topic to start the retro meeting with.
 

Predicting the future with Burnup chart

The burndown chart allows us to monitor only a single and the current sprint. It allows the team a clear view on their progress in the sprint. However, it doesn’t tell if the team if the whole project is on track or will they finish it on time? Every stakeholder and manager wants to know when will the project, milestone or a release be ready.  It is hard to predict a date 3-6 months into the future. Any estimations for this feels like a hunch. “Well, we have 3 months left and 2 more big features, so I guess will make it on time”. How can we monitor our progress on a ~weekly basis?

Actually we can predict all this using our previous progress. Let’s say we are 4 sprints in (2 months) in a 6 months project. Will we make it on time? To answer this we need only 2 things:

1. Estimated backlog (Epics/ user stories with their SP values)
   
2. The Team’s average velocity

Average Velocity is the amount of story points that we finish in each sprint divided by the number of sprints (those who read the previous post probably understand that this metric won’t be too accurate but it is enough for this purpose).

Team’s average velocity for the last 4 sprints = (10 +8 + 6 +11)/ 4 = ~9.
The beauty of the team’s average Velocity is that it gets more accurate with every sprint. Therefore if we know the end date (4 months from now) and the average velocity, then we can predict how many story points the team will finish by that time.
We’ll take the previous chart and we’ll turn it into a cumulative

Now, based on the average velocity we can calculate how much SP we’ll finish in the future sprints.

All the data on the right of the black line (the present sprint) is predicted based on actual data from the previous sprints. You can see that after 12 sprints the team will finish ~110 Story Points. If the total required amount is 100-110 then it seems that we have the right velocity and we’ll finish the project on time.  But we all know that the above chart is too good to be true. The below one is probably more realistic:

This chart is called burnup and it allows a clear, data driven, look at the future. Based on this data the team, and everyone else, knows that the project won’t be ready on time. The velocity should be higher, the ETA should move or the project scope should change. Either way -this is not a hunch.
 

Summary

In this post we’ve seen 3 ways to improve our estimations and predictability. The actual vs. estimated is the best tool to verify and improve your estimations over time and the burnup will let you know you need to speed up your development, even if you finish all sprints on time. The key is to constantly check yourself and improve.
In this series we covered lots of topics regarding Agile development and estimations. It is important to remember that there is no “right” way to do Agile. There are common fundamentals but different teams should use and adopt the principles and process that suits them best. And remember that nothing is constant -  something that used to be “right” for you then, may not be right anymore. So keep retroing yourself and your process, keep fine tune it all the time and I hope that you’ll find what is best for you.
Feel free to share and comment.
Estimations in Agile development – Epics, User Stories and Tasks
Estimations in Agile development – Estimating User Stories with Story Points
Estimations in Agile development – Sprint Planning Methods: Capacity vs. Velocity vs. Feature
Estimations in Agile development - Improving Estimations using Burndown, Burnup and Actual time metrics (you are  here)