The #NoEstimates crowd wants the agile community to stop estimating stories on scrum projects. Their reasoning: story points and velocity calculations are gamed and abused.
[featured-image single_newwindow=”false” alt=”Christina Welsh | Metric | Flickr” title=”Christina Welsh | Metric | Flickr”]Christina Welsh | Metric | Flickr[/featured-image]
And they are right. Management teams, scrum masters, and product owners abuse these numbers…often. But getting rid of agile estimation and a scrum team’s velocity calculations is not the solution.
In fact, you lose quite a few benefits that estimation brings to the scrum team:
- The conversations that arise from planning poker tends to smoke out hidden issues and drives whole team learning about the story being estimated.
- A groomed and estimated product backlog gives a transparent view in to the work that the team is getting “done”.
- The Product Owner has the ability to forecast product releases based on the velocity of the team – driven by the estimates.
- The development team can use velocity and other agile metrics to drive continuous improvement and to help gauge what their sustainable pace is over time.
The benefits of the agile estimation process leads me to think the #NoEstimates group is chasing the wrong problem. Let’s looks at the reasons to ditch estimating story points and calculating velocity given by some of the more visible proponents of #NoEstimates practices:
- Estimation is difficult:
- Ron Jefferies: “Estimates are difficult. When requirements are vague — and it seems that they always are — then the best conceivable estimates would also be very vague. Accurate estimation becomes essentially impossible.”
- Joshua Kerievsky: “Newbies are confused and uncomfortable estimating with story points and frequently compensate by consistently translating story points back to actual time estimates.”
- Estimates and velocity are misused:
- Ron Jefferies: “Estimates are often used as a bludgeon to try to get programmers to work faster. This leads to unhappy programmers and to poor software. No one wins.”
- Neil Killick: “What I object to is being asked to carry out (or ask my team to carry out) estimation rituals whose results will then be used for making important business decisions.”
- Joshua Kerievsky: “I shook my head, amazed at how a mature agile team, a team that had been assessed, trained and coached by myself and two excellent Industrial Logic coaches, could so suddenly inflate their story point estimates to appear like they were going faster.”
- Fixed Scope of work = Commitments:
- Ron Jefferies: “In addition, a focus on estimation often leads to a fascination with completing some fixed scope of work.”
- Neil Killick: “Fixed” scope project delivery expectations are often (always?) based on an up-front estimate of scope (guess) and how long that scope will take to be delivered (another guess), leading to the obvious dysfunctions like death-marches, low quality, etc.”
- Estimates are waste:
- Woody Zuill: “Dang right I’d eliminate them! Anything that is a cost that brings no value is WASTE and I would rather spend my money some better way. I won’t keep any process, practice, procedure, policy, or plan with no pay-off.”
- Neil Killick: “To increase velocity the team simply needs to over-estimate stories to give the illusion of delivering more. They may not consciously do this but it may happen sub-consciously. The project manager pats them on the back, but all that has happened is the same amount of “done” working software has been delivered.”
The charge filed against estimations and velocity are not new. I’ve covered the abuses of velocity and the gaming of estimations in past posts. Where I disagree with the #NoEstimations group is that the abuses are the fault of the metrics themselves. Estimates and velocity are just numbers.
The problem is the conflict between traditional management and agile teams.
In his recent blog post – Agile Coaches – We’re coaching the wrong people!?!? – Bob Galen cuts to the heart of the matter:
Instead of taking the easy road (and money) by mostly training & coaching teams, I’d like us to focus on partnering with and training the management tiers within organizations. In fact, I’m starting to think we’ve been avoiding these folks.
Picture a newly minted scrum master, the ink on their certification not even dry yet, marching in to a meeting with traditional managers and trying to explain how velocity is a team metric, not a management tool.
The scrum master doesn’t stand a chance.
Clearly, management are the very people that need to have a solid understanding of agile principles, practices and values if any meaningful organizational change is going to take place. And we have not helped them get there.
Mr. Galen touches on this as well.
As I reflect on my most successful coaching gigs, these ratios come through—in coaching, conversations, training, and simply influencing change. The middle management tier in organizations, comprised of team leads, managers, and directors, needs the most help in making the transition. And they’re in the position to do the most with the coaching, helping to sustain and grow it.
#CoachingUp is the better way to solve the abuses that the #NoEstimates fans use to justify their movement. Simply deciding to not provide estimates adds to the already widening gap between traditional management and agile software development teams.
As agile practitioners, we should work with our management teams at all levels to get them the knowledge and information that they need to trust us to deliver our work. Otherwise, it does not matter how you decide to slice your stories. Points or not points, they will still seek traditional ways to manage our agile teams.
[reminder]It’s your turn! Do you think it’s time to stop using story points? Have you seen situations where #CoachingUp helped?[/reminder]