If you want to start a fight on my team, bring up estimates. Just the idea of estimates is a “hot button issue”, and I don’t think it’s just my team.
On any given team, the technical staff are likely sensitive about how their estimates will be used. They have reason to be sensitive; there is a system-wide cultural misuse and misunderstanding around the concept. Woody Zuill is trying to reframe the estimates discussion around the idea of starting and completing small pieces of work, and not estimating at all. You can follow that by looking at the #NoEstimates hashtag on twitter. Matt Heusser, the lead contributor to this blog, did some investigation and wrote an article recently for CIO.com about transitioning from traditional planning and estimating to, well … not.
Let’s consider another case: What if the act of estimating tasks actually has value?
If you are willing to grant that, then we can explore ways estimation might be a useful exercise for you.
(kanban board: how much work goes here sometimes depends on your estimates)
My ideas on estimates:
Estimates can be used for all kinds of things: accounting and billing, planning what can be completed in a sprint, and, yes, as a whip to punish people who can not comple work they have “committed” to complete. I’d be willing to bet you’ve experienced each of those at some point in your tech career. One thing I think we ignore though, is the way group estimates can take the ideas (and variances!) in our head and bring them out to the table where we can talk about them for real. That’s a meaningful benefit. Since estimates aren’t going away anytime soon for most people in software, that’s what I’d like to focus on: The benefits.
Pretend you’re in a meeting to plan a some work for the next two weeks. (If you are a scrum-er, this is “grooming the backlog for the next sprint.”) You all talk about a feature for a bit, what this thing should do, how users might benefit from it, and think you understand it pretty well. At least to the extent that you can start to make some guesses about how complex you think the work to build this feature is.
This conversation takes place:
PM: Alright, does everyone think they understand this enough to make an estimate?
PM: OK then, lets do this in t-shirt sizes. 1…2….3….go!
I think this difference is really important and is something the no estimates community doesn’t talk about enough. Sometimes estimation differences means people have different skills on the technology, the code base, or even a different understanding of the problem to be solves. Sometimes they are a lesson in disguise. As a general rule, if your technical staff have wildly varying opinions on how long something will take, then something might be going on there worth talking about. This might not tell you where to look or immediately solve a problem, but it sure seems like a good start.
This difference in estimates can be a clue that people have different understandings about what they need to work on. Maybe there is a complete misunderstanding about what is being built, maybe someone knows about available libraries or utilities that you don’t know about, or maybe some aspect of this widget has already been written by another group in your company. Without that estimate you may have never had that conversation. The group could have had the story grooming session then gone off happily and started working only to realize later that these misunderstandings existed. What a shame that would be!
What you can do tomorrow:
Don’t stop estimating, rather reframe how you think about this tool. Start thinking of estimates as a tool that can help groups of people reduce ambiguity and gain clarity on a topic. Don’t worry so much about being victimized by a process.
I mean, sure, we could point out the process is broken. But has that ever helped anyone?
Focus on the good, and there’s a chance things might get better.
The choice is yours.