To begin with I want to state that this post portrays my opinion on Agile estimates.
Agile estimates have been around the Agile movement for as long as I can remember. I was not privy to the start of Agile so “as long as I can remember” probably does not cover the amount of time estimates have been around. Either way, chances are if you are part of an organization practicing Scrum, Kanban, or any other “Agile Methodology” you have probably heard of estimating your work.
Agile Estimation
In a nutshell, assigns a value to an increment of work. This could come in the form of Fibonacci numbers, standard 1, 2, 3…, or even t-shirt sizes. Whatever value you assign to an increment can then be compared to others to give an idea of complexity, risk, or other measurements.
Techniques for determining Agile estimates are many. There is Planning Poker, a technique that has every team member choose a value for a work increment and reveal them at the same time with the most common value becoming the estimate. Another is affinity grouping, where the team groups similarly sized increments together. There are many other examples out there of estimation techniques.
Where it goes wrong
Often Agile estimation goes wrong and the teams involved do not even realize there is a problem. One way things can go wrong is when teams are compared to each other based on their estimates and the work done. The big red flag here is that no two teams estimate in the same way. They would need to have the same thought process when taking into account different aspects of their work. Since this is not the case, comparing two teams based on velocity and estimates is a big ‘no-no’.
This brings up the next way Agile estimation can go wrong. When looking at estimates and the work done too many teams see the points being delivered as the metric of value. The team looks at the number of points they are getting done, which is “not big enough”. This can cause the team to pad their estimates to inflate the number of points done.
A third instance where Agile estimates can be leveraged wrong is when a team leader uses the estimates to measure individual performance. Believe me, this does happen. Velocity is a dangerous metric and is often misused.
Zombie Voting
Something I like to refer to as “zombie voting” is where team members arbitrarily pick a value for an estimate without putting any thought into what they have chosen. They figure “Everyone else is going to pick ‘x’, so I will do the same”. This checking out from the activity takes away value not only for the individual but for the team as well.
Top Down Estimating
Finally, when a leader, senior member of the team, or Product Owner passes down the estimates. By doing this the person providing the estimates eliminates the team from the conversation. The leader may answer questions on why certain estimates were given but the team has no ownership of the estimates.
Where it goes… right?
Teams look to better themselves and only themselves. In this situation, teams work towards improving their estimates as time goes by. They do not look at other teams and how they are doing. Similar to fishing with friends, it is wise to mind your own bobber.
Everyone has a voice during an estimation session. This allows all concerns to be addressed. This requires a psychologically safe environment for the team to estimate in.
Discussions around complexity, risk, etc happen without hesitation. When estimation is done right, whenever there is disagreement around the point value of an increment of work there should be discussion. In my opinion, one of the only valuable aspects of estimation is the conversations it can generate.
Are you getting value?
When discussing estimation with others you may find that there are plenty of people who disagree. They all have valid reasons.
In the end, you need to ask yourself are you getting value out of Agile estimation? Or are things going wrong without you knowing? Whatever your answer to that question is will show you if estimating is right for you.
Additional Reading Related to Agile and Estimation:
Why You Don’t Force an Agile Journey
