At Agile+DevOPs 2018 @ryan.ripley kicked off a UX fishbowl panel session about no estimates. To be honest I have been skeptical about no estimates since I first heard about it. I think I have been skeptical about it for a couple of reasons including:
- Committing to work and achieving it in the sprint has been one way for a team to achieved a level of trust with their business partners.
- Many of the people I have interacted with pushing no estimates have been software developers that have been burned by managers using estimates as commitments and getting burned by expectations that developers never thought they were setting.
- No one ever explained how business planning could happen with no estimates. While I am a technical person I have always believed that business value has to be the cornerstone of any project.
Part of the way through the session, I had to leave for a reason beyond my control. The session was going well with a lot of great information coming up in the course of the discussion. The next day I was able to ask two of the initial panel members how the rest of the session went. They generously gave me some of their time and recapped their points of view for me.
The first one, we can call her Johanna (@johannarothman) started with the suggestion that telling managers and business partners that you want to do no estimates can often lead to them shutting the idea down. A better approach is talking about incremental funding. That coupled with a rough order of magnitude estimates for project sizes and breaking work down to the point where you are delivering value on a continuous basis is a great way to build trust with the business. Let me break down what I took from each of those statements and hopefully I am not botching Johanna’s ideas too much.
Incremental funding – This is funding projects as they go. The thing that can really make this work well is for the projects to have a prioritized list of features. This allows the team to work on feature-based priorities, whatever that might be. One of the sales pitches for agile is to fund the teams by the sprint. This allows the business to decide when enough work has been done for the product to go into production. Johanna used the example of working with an organization that was disappointed with the productivity of their teams. Part of the issue the team had was that there were asked to make estimates that were really commitments. In their culture, the team felt the only way to protect themselves from repercussions of estimate commitments was to pad the schedule. Johanna asked the executive if he would have preferred 85% of the work delivered six months before the date he demanded. He, of course, would have loved that. The way he framed the work and commitments prevented the team from being able to think of a way to deliver the most value on the shortest amount of time. By not forcing estimates and a date, but enabling the team to work on features in priority order, you can create valuable software in less time.
Rough order of magnitude estimates for a project – As it was explained to me this is a time-boxed exercise where the goal is to have enough of an estimate to decide of the work as configured is worth doing from a business point of view. The goal isn’t to be exact but to give a directionally correct estimate that will get refined as the team works.
Breaking work down – The reason you break work down is to be able to create a prioritized list of user stories. This should be a true priority list meaning that there is one and only one priority 1 and your priority levels should be equal to the number of items in the list. Since Agile delivers small parcels of value earlier1 using a true priority list allows the business to get the highest value work first and to put that working software into production as soon as there is enough value in the software to warrant a release.
Continuous work delivery – Following on the idea of having a true priority list, the team should be delivering software on a regular or continuous basis. This will allow the business to realize value as it is being produced.
The other panel member, Matt (@mattbarcomb), added that it is still possible to capitalize the funding for projects with incremental funding by doing work to make sure that the team is delivering software that goes into production. This is actually a big concern for a good number of the organizations I work with and without that answer, incremental funding would quickly get kicked out of consideration.
With that information, I see the #NoEstimates movement in a different light. Rather than a reaction to abusive projects, I now see it as a way to achieve the agile goal of business agility. In the long run, delivering increments of value on a continuous basis is going to build more trust with the business than hitting any schedule.
1 – https://twitter.com/evolvable/status/1066291655282634752
