In a recent post on burndown charts and student syndrome, Bob Tarne wrote about an Agile team that was unnecessarily padding daily estimates, leading management to be nervous as the burndown didn’t move until it nosedived at the end of the sprint. Though I chuckled when I read this, it is a very common occurrence. For years, teams have been padding estimates as they’ve been held to given dates regardless of circumstance. There are a few things we can do to turn around this situation.
Shift Your Paradigm
Back in the day when projects were mapped out months in advance in Microsoft Project, all resources were perfectly 100% allocated, and the future was set in stone, management was told that they could rely on a very certain delivery date. And they hoped in their heart of hearts that this project would be different – it would be on time and on budget. And even better, they have this little gantt chart to see that everything is on track. It was a micromanagers dream. Someone updated the chart every day, management saw progress, and if they didn’t someone got yelled at.
And then the plan fell apart. Someone got sick; a vendor was late; a client didn’t have everything lined up; the team didn’t have all the resources they needed. Someone had to explain what happened. But we know what happened. The future is not set in stone. Stuff happens.
And so we implement Agile with it’s iterative development. We work in smaller chunks that the usual milestones, and deliver value every 1-4 weeks. It’s great.
But has the mindset of our teams and our managers changed? Does management still look at the chart as the true measure of progress? Do they need to? Yes, but only to a limited extent.
Burndown charts do show us progress, but what we’re really concerned with is the end result of an iteration (or Sprint if you Scrum like us). And if you are using story points for estimations, then you have velocity, which tells us the amount of “stuff” done during a given sprint. That’s what I really care about. How much can my team produce within a given time? All of my backlog items have these numbers too? Great, I can simply pick the same amount of stuff to work on next time, and perhaps adjust it once I talk with the team.
Big difference. But it takes work to help management understand this new way. But they like results, so let’s keep their focus there.
Back Up Your Team
Teams will pad estimates in a number of situations, mainly:
- They really have no idea how long it will take to complete a given task; or
- Their butts are held to the fire for any number that they give, so they give a big one
Evidence and research has shown that relative estimates are typically way more accurate than time-based estimates, and there are so many factors for the latter that the complexity shoots up and accuracy drops. So people are wrong. Does that mean they lied? Nope. Does that mean you might need to explain some things? Sure. In the end might it be a wash? You betcha.
And if I am truly leading my team and backing them up, keeping management from needling them when the don’t see burndowns going at the angle they think they should expect, then there is no reason for my team to pad their estimates.
What Would You Do?
You have teams padding estimates and you have management nervous from looking at charts. What would you do in this situation?
Other Posts That Might Interest You
