LESSONS LEARNT ON PROPER ESTIMATIONS

One of the main challenges in any development team is giving correct estimations. In agile teams estimations are mostly done through story points, while in other teams hourly estimates are still relevant.

Estimating through story points has been one of the greatest innovations of agile. For teams being new to agile estimating with points can be a hazard. However a big number of experienced agile teams claim story point estimations to be rather effective.

We all know how we give hourly estimates to a specific task or story, that is simple. You read the task, you think of all the things needed to be done for completing the task and announce the amount of hours needed for that. The relative estimation is different.

The simple truth is that we never ever can give accurate estimates. All our estimates are guesses. The loveliness of high level planning is that both you and customer can have a plan which will be tracked.  

Steve McConnell, in his Software Estimation Demystifying the Black Art says: “The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them.”

There is a universal truth none of us can deny: Accurate estimates are not realistic, we need to understand that. Agile estimations allow us prevent promising what actually can’t be done. So  estimating relatively can be a great solution.

What do I mean by saying relative estimation? Imagine, it takes you a minute to drink a cup of water. And now you need to estimate how long it would take you to drink 5 cups of water. You will surely estimate it 5 times more, right? So the main thing is to find a baseline to be able to compare. In this case one glass is the baseline.

There will always be cases when your team will need to reestimate the stories. Especially in newly organized teams the baseline is often changed. This is quite OK, as only with changing and reestimating the team will be able to find an effective baseline.

If you are familiar with relative estimations, you will surely know what a Planning Poker is. It is a game the agile team is playing via a deck of cards for estimating the user stories during the Sprint Planning Meeting. The deck of cards have the Fibonacci numbers (0.5, 1, 2, 3, 5, etc..) as well as ?, and ∞. So each team member estimates the story individually by pointing out the cards, then discussion is being held based on differences.The discussion lasts until all the members agree on a specific estimation. If all the members have the same estimations for the story (not an easy task), the estimate is being fixed.

There are companies where user stories are being estimated through T shirt sizes, like Small, Medium, Large, Extra Large, Extra Extra Large. However, this seems to be even more high level than estimating with the points.

You can see that for being able to estimate relatively we need to have stories that are relatively sized to each other. So, before requesting realistic estimations from the team, the Product Owner should provide stories that are Estimable.

Trying to conclude the concept of relative estimation: we need to understand how long the trail is, not how long it would take us to cover it.

Most customers are very afraid of relative estimations, and they want to keep everything simple and trackable and to pay for fixed amount of hours. This can be a serious problem for outsource teams. Most customers think that people are more accountable for the hours rather than for the effort. That is the main reason most outsource teams do agile, but estimate with hours.

While estimating with hours (absolute estimation) you estimate how long it would take a specific engineer to develop something. So if the task’s assignee is changed, the estimate might also be changed, thus affecting the whole iteration and consequently, project plan. Maybe the task includes JavaScript or Angular JS, for instance, on which some engineers are strong and some are weak. While for relative estimations the team can collaborate and stay within the estimation.

You need to see the difference: whether you want your team to be accountable for the stories, or for each engineer to be accountable for the hours spent. When you have the answer to this, you will also have the estimating type chosen.

Another huge mistake is when teams try to match a point to a number of hours. It always strikes my ear, when I hear such expression:”1 story point equals 4 hours of development in our team”. Never ever do that! In that case you will lose the whole idea of relative estimation. In that case you just estimate absolutely but instead of hours use points. Relative estimations allow you to track progress from one sprint to another. For example, you covered 30 points within 120 hours in the first sprint and 35 points within 120 hours in the second one. You see that within the same velocity you were able to cover more work. If you match story points to hours, you will never be able to track your team’s progress.  

Even though everyone is well aware of how unreal the estimates can be, we are still requested to announce a delivery date. So how can we announce a delivery date, with all this relative estimates and guesses?  We need to take the total effort for the whole project, divide it by the team velocity (the sum of the hours to be spent on development for the whole team) and count how many sprints we think are needed to complete the work. So this is the sole project plan we need. Agile Samurai suggests the following formula :

Number of sprints = Total effort/ Team velocity

However, only after some two-three sprints you will be able to better understand how close you are to the initial plan. 

As you see, there is no specific guide that will help you on your estimations. All you can do is to find your baseline, track the progress throughout the first iterations and instead of making blind guesses, have statistical data to lean on.

Good luck with planning!