One of the hardest adjustments to make when adopting Agile is to get used to the idea of using a unitless measure like “story points” to do estimation. I think that most engineers get used to the idea eventually, especially as they grasp how it functions in combination with measuring velocity and using that to estimate future capacity of the teams. It’s a simple feedback system, and as long as the estimator itself is stable, it really doesn’t matter in the long run if it is accurate in estimating effort.
Even after you get used to this idea, you will find an ongoing concern expressed by the feature teams that the estimation process is flawed. Now, I have to admit that early on my reaction was that this was just natural – we all know that software work always expands to fill the container in which it is placed, and it takes a while for each feature team to learn this and for the velocity estimates to correct to the point that the team does not enter each iteration over committed. I also noticed that there was a tendency for feature team leads to let the product owner buy more than their original estimate, usually because there is a pet story that they really want to squeeze in so the decide to go for it even though the numbers don’t substantiate it. However, even as I used time and coaching to try to bring both of these aspects of the process under control, the frustration still remained as a consistent theme in ongoing retrospectives.
My next thought was to address this by getting more people involved in the estimation – my assumption was that participation would help to neutralize the concern; if they saw the process in action and participated in the estimating, then they would come to appreciate why and how it works. So I opened up the invitation to the entire extended team, adjusted the time schedule for the meeting so that all participants around the world could join, and rejoiced over what a smart manager I was. We had one or two new participants for one meeting and then it quickly relaxed to the same participants as before and the same grumbles re-emerged.
At this point, I was running short of ideas and getting frustrated with the situation, so what did I do? What any manager would do – delegate the problem! I know that sounds like passing the buck, but I can also rationalize it by saying that I needed both new ideas and a shift in responsibility for resolving the problem to those that worked hands on with the teams – the feature team leads.
As the leads started to tackle this problem, one thing quickly became clear – the individuals doing the work wanted more influence over what they were committed to accomplish in the iteration, but I would not budge on the approach or need for the high-level estimation process. The natural inclination was to try to force these commitment processes together, but the reality is that they serve two very different purposes. Story estimation in the product backlog combined with the buying meeting are needed to allow for macro level management of the release cycle and for gating the flow of the quantity of work allowed into the development engine. To plan the work at more detail meant creating a significant distraction for the developers and testers in the team, a process which starts the slippery slide back into waterfall. We needed to keep our high level, less accurate estimation process in place, but we needed to add an inner ring of commitment that would occur within the confines of the feature team itself.
Dirty Sweet at Lollapalooza - Chicago, IL
One of our feature team leads (Jeff Whiteside) really took this to heart. Jeff wanted to figure out how to overcome this barrier by focusing on the iteration kickoff and planning process and figuring out how to best build shared responsibility within the team that ALL of the stories that were purchased could be finished and if not, then we would invent a new way to unallot them from the team. I’ve asked him to relate the specifics for how he has accomplished this in his own words and will post the details here in a separate article, but let me take a moment to relate the results I witnessed.
Jeff decided to formalize the kickoff as his means for transferring ownership of the deliverables and for planning the scope of the iteration. He realized that these were two sides of the same coin – if he didn’t force the team to take some time up front to consider all of the stories in the iteration then the natural behavior was everyone to just grab one and go. Now they break these stories down into tasks and estimate the tasks in hours. If the rolled up detail estimates across all of the stories exceed the available hours of his team, then we know we have a disconnect and revisit the story list.
These task level estimates become the element that is tracked for burndown during the iteration – story points tend to be too coarse for doing day to day project management, and this gives Jeff (who is remote from the rest of the team that he is leading) better visibility to what is happening day by day. What I have observed as the result is that the pressure felt by the team to deliver when they feel they were over-committed has been resolved (as have the complaints) and planning in BOTH layers of the organization (macro planning for releases done by the director and product owner and iteration planning done by the feature teams) are working smoothly.
