Absolute VS Relative Estimation
When you ask a software developer to give an estimate on how much effort it would take to implement a particular requirement, I’m sure that their initial reaction is to give you an absolute answer in hours or days. This is called an absolute estimate and has been the traditional way of providing estimates in the software development industry over the past several decades.
While it’s true that absolute estimation gives you a predictable time on how long it would take to release a product, how many times have you found that your estimates were completely inaccurate? This is because humans are known to be pretty bad at making this kind of estimation. As Yogi Berra once said Prediction is hard, especially if it’s about the future.
Contrariwise, people are really good at making relative estimates. Try to compare the requirement needed relatively to something you've already done before. So if you think that a specific job is going to take twice as long as the other, then chances are that would turn out to be pretty much more accurate.
So how can we make use of “relative estimating” to improve the estimates that we make during the project? In Agile estimation we use a thing called story points. Now a story point is just an abstract unit of time. For a particular team a story point might be half an hour, an hour, a day or even a week. The idea of a story point is to take us away from thinking absolute time estimates and to start doing estimations relatively.
So how do we estimate based on story points? In FiLDEV, Planning Poker is a common practice. Imagine you have a set of story cards technically known as the Product Backlog. Choose a card which you consider to be the easiest. Then find another card but this time pick the one you think is the hardest to complete.
Now apply a story point to each of them. For the story that we consider the easiest, we’ll give it a low value of like 2 points.
Then think relatively and compare the hardest story to that easiest one. Assuming that it would take 5 times more effort to complete, we want to give it a story point value of 10. But since we want to adapt the Fibonacci number sequence 1, 2, 3, 5, 8, 13 ... and 10 is not a number in that series we want to give it 8 points instead.
So now that we got these two ends of the scale defined (easiest VS hardest) we can now then take all the other story cards and position them proportionately on that scale so that all our estimates are made relative to each other.
You may be wondering which of the user stories in the product backlog should we tackle down first? Is it ideal to focus primarily on the easiest ones then walk our way up to the most difficult user story so we can get more things done? If not, how should we prioritize? This is when value points come into play.
Since story points allows us to estimate the complexity of a particular story, value points on the other hand allows us to measure which gives more business value to the user. Because remember in Agile we want to deliver value as early as possible.
While story-points are estimated by the people who will do the work (development team), value-points on the other hand are estimated by the customer. This should give us an idea on which item from the product backlog should we be including in the next iteration or product release.
Just in case you're wondering, at this point we still have no idea on how long a story would take to finish based on story points. So for us to determine this we need to understand what Velocity means in the world of Agile. After all business people wants to know how many days or months it would take to release a product.
Velocity is simply a measure of all the story points you manage to complete during a single iteration; and points from partially-completed or incomplete stories should not be counted
Let's make an example. Assuming you've done your first iteration:
- It had a duration of 2 weeks
- The total story points we made in this iteration is 50
Therefore we can now conclude that:
- A single story point is equivalent to 2 weeks Divided By 50 story points.
- Or we can say that for every iteration (2 weeks), the team's workload capacity can be as much as 50 story points.
- Or we can simply say that the team's actual velocity is 50.
Knowing the actual velocity is an important key factor to success and for us to have a relative estimate on how many stories a Team can do on the next iteration. Keep in mind that velocity may oscillate overtime from one iteration to another. Our goal is to improve the trend upward by roughly around 10% each iteration.
Software development is always loaded with high levels of complexity and unknowns. It's very challenging to identify with great level of accuracy how long a specific feature will take to complete.
By estimating relatively and making use of the following metrics I've mentioned above, you can significantly improve your estimates.
- Story points - Gives you an idea about the complexity of each tasks.
- Velocity - Is your indicator on how fast you can deliver them based on your team's historical performance.
- Value points - Gives you an idea on which should be done first.