The last few years I have been part of a team that is building diabetes management apps for both iOS and Android. Our client partner is a global leader in the diabetes care market. We want our partner to be successful…necessarily we have to understand the constraints that they are working with in order to deliver products that are regulated by the FDA.
In the past, working with this particular partner has taken the shape of large increments, long release cycles, and big upfront estimates.
In a joint effort, we decided to work differently this time: we wanted to work with smaller increments, leading to shorter release cycles. We knew that releasing more frequently meant we would need to change our approach to building and designing products with this partner. It’s a big shift to go from 18-36 month release cycles down to something closer to a 6-month release cycle for major releases.
Being excellent technically wasn’t going to be enough…we had to be better in other areas as well. Introducing… #NoEstimates…
@steve_fenton #NoEstimates is not about ditching estimates. It is about improving the way we work such that estimates become redundant.
— Neil Killick (@neil_killick) January 29, 2014
I love the pragmatic view that Neil Killick has about what #NoEstimates represents – improving the way we work…such that estimates become redundant. Today I’m only going to talk about making estimates redundant…I’ll save the “improving the way we work” for a future post 🙂 …the short version of this future post is that this was the most sophisticated, collaborative, and fun team I have been part of in my career.
Making estimates redundant
As Neil says, #NoEstimates is not about ditching the estimates…it’s about making them redundant.
Since we started this journey we have had 3 major releases with multiple minor releases for each major release. We track our work in a work item tracking system, TFS, which makes it really easy for us to collect data on our team.
All of our “things” in TFS had a value of “1”. (more on the term “things” in a moment) We counted the number of things our team got done each iteration. We then used this data to plan what the team could do for each iteration. This data was extremely useful for us monitoring our current plan and our progress for the current release we were working on.
Eventually, we finished our first major release. We were able to use all of our team’s historical data to help forecast the next release…and then the next release after that…then the next one after that…and so on. Using this historical data was the basis of how we continued to forecast releases and secure incremental funding from our client.
Our most recent major release is especially interesting. We were able to quickly count the number of “things”, use our previous throughput data, and estimate the entire major release in a few minutes at a whiteboard.
Only a few minutes.
With serious confidence.
Using actual team data!
Side note, “things” became our team’s technical term for work items that we performed work against, and specifically not bugs/defects. We had 3 types of work items — PBIs, “things”, and bugs. We didn’t let ourselves argue over whether something was, or was not, a story. We identified work that needed to be done and we tracked it.
So what?
Bringing #NoEstimates into an FDA world was only a means to an end…the “end” for us was…
- Raising the technical bar for our team to improve the way we worked
- Raising the relationship bar with our client to better understand each other’s worlds and constraints
- Minimizing the amount of waste we introduce trying to estimate releases
- Making life with diabetes suck a little less for our users
These improvements and changes spanned over the course of multiple years. This was not a change that we made overnight. Embracing #NoEstimates helped our team get to a place where estimates became redundant. At the end of the day, estimating features/widgets/things does not support our client in being successful at making life with diabetes suck a little less.
Embrace the constraints that you are living in, and move your team/client/partner to a place where estimates are redundant.
