#NoEstimates. Is it the latest agile software development trend or meaningless hype? Your guess is as good as mine. It’s an interesting question that deserves closer examination.
The general premise is that software estimates are unreliable. They are usually overly optimistic and are often grossly inaccurate. So is it better to avoid all the work that goes into estimating?
To answer any complex question, we need to establish context. Let’s start with a small team of 5-7 developers and testers. They are working on a relatively small, targeted, software application. The marketing department has defined the minimal viable product (MVP). The primary goal is to deliver the MVP as soon as possible. In other words, get minimal functionality out there fast and add to it in future releases.
Does this effort need estimates? Not really. Marketing needs a rough idea of when alpha-level code will be available. Allowing a few weeks for alpha testing and a few more for beta testing provides a timeline. That may well be good enough. Why spend a lot of time estimating individual stories, adding up estimates, and tracking all of it? What value would that add?
Well, there are two answers to that last question. There is little or no added value in the estimates for the current project. However, there may be value in helping the team make future estimates (assuming they ever will).
Now we’ll take a look at a different context.
We have a small team of 7-9 developers and testers. They are working on an enterprise-scale, software application. Again, marketing has defined the MVP but this time the MVP is big and complex. In other words, the first release has to be functionally complete in order to be competitive. Everyone understands that this effort will take several months to get to beta-level code.
Does this effort require estimates? If time and money are no object, why estimate? Just go for it. I don’t know about you, but I’ve never worked with an enterprise company that would start such a project without at least having epic-level estimates. Management needs some idea of what they’re getting into, how long it will take, and how much it will cost.
Also, in a lengthy project, early estimates help to fine tune later estimates. The team should get better and better at estimating as time passes. It’s not unusual, to get 50% of the way through a project only to realize that 80% remains. This happens when the early estimates were overly optimistic.
Should You Estimate?
That depends. Does your management team trust the software development team? If not, rolling with no estimates will never work. As soon as problems surface (and they inevitably will), the team’s lack of estimates will be blamed. A tough situation will cascade into turmoil.
If trust exists, you’ll need to break up the work into small chunks — the smaller the better. (I’m a fan of one-week sprints and four-week releases. Admittedly, those time-periods are tough for many to accept but that’s a discussion for another time.) If the team can demonstrate the ability to deliver as promised early on, management is much more likely to accept that they will keep delivering as promised. Estimates will add little, if any, value.
Estimates are a lot of work. You have to derive them, track them and report them. #NoEstimates? It’s a goal worth shooting for but will be hard to achieve. Work on building trust first. Your odds of winning acceptance of new ideas will improve dramatically.
photo credit: quinn.anya via photopin cc