In an earlier post, I described how one of my teams went down the #NoEstimates route. We had pretty good success going down this path. As a manager and a coach, it validated for me that how long it took for a story to get done had little correlation with the size or complexity of the story. In an organization with 30 development teams, we were definitely not the first team to stop estimating stories. We had other firsts under our belt, but that was not one of them. Very soon though, there was not a single product development team that was using story point estimates. It was the end of story point estimation, but as much as I would like to tell you, this was not the end of estimation.
First, a quick description of our work breakdown structure. We take long-term strategic initiatives and break them down into features. These features are then broken down into stories. The teams have the freedom to decide if they want to break these stories further down into tasks or not. Most teams choose not to use tasks as they do not provide much value to them.
At the story level, as described in the previous #NoEstimates post, limiting our WIP and right-sizing the stories made us more predictable. We were more predictable than we had been after years of trying to figure out estimation. The transition was easy for developers, as they always found the estimating conversations time consuming and wasteful. It was also easy for the folks on the product side of the house. The predictability gained counteracted the desire to get story level estimates. The other reason that the business did not have an issue with us going to #NoEstimates was our delivery level. We, as an organization, delivered Features and not Stories. Eliminating story points stopped teams from spending time guessing the exact "size" or exact "complexity" of a story. It did not stop the business from asking the teams to spend time guessing the exact "size" or exact "complexity" of a feature.
Teams across the organization were no longer estimating stories but were providing estimates for features in the following format -
The product team at that point would take these estimates and the team's forecasted capacity for the release into consideration for release planning. The product team would play 'Tetris' in order to fit as many of the features into the release based on these story estimates. For example, if the team working on the features listed above has a projected capacity of 80, the release plan would say that they can do features A, B and C (12 + 55 + 7 = 77). These features would then be advertised as the ones we are committing to for the upcoming release.
On the face of it, this seems completely logical and sane way to go about releases planning. Unfortunately, this approach suffers from the same problems that story-level estimates have.
- It is impossible to know the exact count of stories in a feature beforehand, regardless of how much analysis we do on the feature.
- Features, more often than not "grow" and more stories are added while they are in flight. Planning to capacity puts features at risk, even if one of the features grows.
- In order to ensure completion on time, the largest of the features has to be started Day 1 of the release even if it is the lowest priority feature. This almost always puts higher priority features at risk.
- These estimates are based on initial guesses, which, when later invalidated, did not always invalidate the commitment.
- Large features are turned into multi-release efforts as opposed to being sized appropriately.
After struggling with these issues for a number of releases we started to attack these problems. We realized that we already had a blueprint for how #NoEstimates has worked for us at the story level. We decided to start applying the same to Features. To start, we first collected some data on our features. We discovered that 85% of our features consisted of 25 stories or less. This was our stake in the ground. We asked teams to start using this as a yardstick for whether a feature is too large or not. Teams had already been doing this for stories. Each team was very adept at "right-sizing" stories based on their data. The other necessary step in order to get #NoEstimates to work at the feature level was to limit WIP at the feature level. We asked teams to establish Feature level boards and limit WIP on each stage of Feature lifecycle (Selected, Analysis, Development, Test, Done to start with). Teams had again, already been doing this at the story level and this would be a natural transition for them. We, as a coaching group, set these guidelines and left the implementation in the hands of the teams.
The results were mixed. Some teams, due to various reasons, including external pressures, implemented a loose feature WIP and didn't quite go down the path of sizing features. Other teams, took the advice to heart and implemented strict WIPs on the number of features they would work on and not accept any features that were above 25 stories. When a feature seemed like it would be much larger, they broke it up into smaller features that could flow through their process smoothly. There were some things missing though. Even in the teams that took the approach head on, they did not do everything that they were doing to make themselves predictable with stories. They were not breaking up features into smallest deliverable features as they gained more information about them. They were violating their feature WIPs when emergency requests came in. In other words, our roll-out was only semi-working. Which means, we were becoming only semi-predictable.
Of late, we have changed our approach a bit. We have picked one team to work closely with and try out our approach. Apart from ongoing coaching, we are actively encouraging them to not provide feature estimates and to break up features as much and as often as possible, especially as they seem to approach the 25 story mark. We are trying to turn our #NoEstimates game up a notch. We are taking all the principles that we know work with stories and applying them to the Epics/Features. Limit WIP, Control Batch Size and Manage For Flow at the feature level, the same way as we do on the story level. Once we have these concepts proven out with this one team, we will roll them out to others in the department as well. Hopefully, all estimation conversations turn into simple conversations of "Does this work-item look like it is too large for this level, if yes, let us break it up, if no, let us start work on it."
We expect that this approach will make us more predictable with our features. The predictability gained should allow us to answer the question of - "When it will be done?" without having lengthy estimation conversations. The expectation is that this approach will also help us get to Just In Time commitment, where a feature is committed to only after it has been started Before the feature is started, the business can easily de-prioritize it and replace it with a different right-sized feature. This should allow us to be more agile and respond to market pressures and feedback more often. The hypothesis is that limiting WIP and controlling batch size allows for these things to happen naturally. Watch this space for results in the future.