The role of estimates in software development
The debate surrounding the now infamous #NoEstimates tag has seen commentary from all corners, so we thought we’d try and put it all together for you. After some thorough research, here’s what we’ve discovered.
Deadlines, estimates, schedules. They’re all required in order to make sure a project gets deployed and has a realistic, justified and deliverable outcome, right?
Well, maybe, maybe not. If you’re Woody Zuill, Neil Killick, Vasco Duarte or the countless software developers who’ve been supporting the #NoEstimates Movement, then the word estimate doesn’t factor into the development landscape if you continually deliver in small increments. That can be seen as a pretty loaded statement, so let’s explore a little further.
No estimates prologue
It all began with a blog post by Zuill, who documented an approach that he felt worked best to deliver a ‘done’ project, that uncovered the needed features of software, and discarded what was later deemed irrelevant or unimportant in terms of the final product.
At the conclusion of the project, Zuill made some observations about how the team worked, and noticed one thing in particular about the idea of estimates:
Boss wanted estimates, and also wanted the work done as quickly as possible. I made the case that we could try to get some critical feature into production ASAP, and then revisit the idea of estimates later. After the first deployment, no requests were made for estimates.
No requests for estimates. None. But how did this come about? Zuill goes on to say that estimates are part of the ‘comprehensive documentation’ that we value less than ‘working software’. With the team iterating and incrementally delivering, doing the work of “writing the code in small pieces and getting it into real use made it possible to steer the work”.
After speaking to a few developers myself, the idea of having a priority focus, or as Zuill puts it, a critical feature to work on, was definitely the way to go in terms of productivity and preferred output. But of course, priorities change – which Zuill highlighted as a potentially good thing. He goes on:
As we started delivering usable software, the users and Boss started asking for different things than had been described in the requirements document. The users and Boss started fine tuning what we had delievered – noting things that they wanted to be done differently. This is a valuable and wonderful thing. This is how requirements emerge.
This is all part of a continuing series of #NoEstimates posts that Zuill has compiled in order to send the point home: software can be valuable depending on what it does, not how well you estimate its development.
The movement grows
After Zuill’s initial blog post and follow-ups, other players began appearing on the #NoEstimates game board. Vasco Duarte, who’s written a book about the #NoEstimates Movement, has been ardently pushing for wider adoption of the practice as a way to turn projects around. He’s also put together a smorgasbord of posts authored on the subject.
Neil Killick has also been a vocal supporter of the movement, who claims that he’s seeing “more and more evidence in the workplace that many of the problems caused by software estimation are a simple case of teams shooting themselves in the foot”. The dysfunctions that exist within software estimates are easily avoided simply by asking the right questions at the start of projects and being single-minded about delivering great outcomes for the client.
Henri Karhatsu blogged about his experience in moving a team to a complete #NoEstimates methodology, transitioning from hourly estimates to story points, to eventually scrapping estimates altogether. Being a Scrum Master himself, he found that his team spent a lot of time arguing about story points, and when the conversion to #NoEstimates was made, they decided to focus on the next most important thing to work on in order to guide their project:
What really happened was that the required changes were in production pretty much when we expected them to be. However, we didn’t finish all of the dozen stories we had planned initially. Instead we realized that half of them could be done later and replaced those with other, more important tasks. The throughput was as expected but the content was something different, more valuable.
This focus on content change is exactly what Zuill describes as a positive outcome of the #NoEstimates framework.
The reaction to the movement elicited curiosity, intrigue and anger. Lots of anger. Steve Fenton chose to address the anger directed towards #NoEstimates in a way that deduced the following:
- There is a relationship between regularly delivering quality releases, building trust with the business/customer and a drop in demand for estimates
- In a low trust environment, people want assurance. To give them this assurance, start delivering early and often
- As trust increases, many of the negative reasons for estimates disappear and many of the positive reasons for estimates are solved in other ways
Fenton advises that to eventually work without estimates requires a building of trust that may not already exist, therefore you shouldn’t be aiming for #NoEstimates without it. He feels the anger that has been thrust upon the topic has come out of a misunderstanding of the framework, with people interpreting the phrase “some teams have found that they don’t need to use estimates” as “YOU must stop using estimates”.
As Fenton says, if you successfully get to a high trust state (which takes a whole lot of hard work, regular releases, quality releases and transparency) then revisiting the #NoEstimates tag might be worth your time. It’s important to get everyone on board in order for #NoEstimates to actually work, and by proving you don’t need them via prioritisation and having informative conversations about how to improve software development.
As Scott Rosenberg has summarised, what the commentators above are getting at is less about an uprising than a renegotiation of what organizations expect from software developers. What do you think? Let us know in the comments below!