The most common question on any project is, “How long with this take?” This question isn’t too difficult to answer when the work is small – a few minutes to a few days. Problems start when someone wants an estimate for a chunk of work you can’t complete in just a few days. Requests for estimates like this come from a need to make higher-level planning decisions. But estimates aren’t the only way to make these decisions. Over the last fifteen years of working with agile teams, I’ve seen value in exploring estimation alternatives. Two, in particular, come to mind, the first of which I’ll describe here: Shifting conversations about estimating to budget discussions.
Confronting Problems with Project Governance
Around 2010, I led an agile adoption effort inside a large, multi-national manufacturing-based company. Our project planning approach was familiar to many large organizations: Stage-gate project approvals. To start the next release of our software package, we needed permission from the Project Planning Group (PPG). As is typical, one stage involved “finalizing” the requirements and project timeline.
When we’d done this before, we began with market and stakeholder analysis. We used that research to define what features should be included in the release. When I started at the company in 2006, these requirements documents were written in the classic (and often reviled) “the system shall/will/should” style. Each anticipated use case was enumerated in dry detail – but still left the developers with too many questions. Developers were given a list of requirements and asked how long it would take to implement each. A project manager loaded these estimates into a project plan – complete with a Gantt chart – showing how long the project should take. The PPG would then consider these project documents and the corresponding budget requests and either approve them or send them back for more work.
Of course, everyone knew that the requirements, the project plan, and the budget were fiction. So why did we do it? Ultimately, a project governance process like this is to ensure the company gets a good return on its investments of time and money. There were a limited number of people to do the work and only so much money to fund those efforts. This process wasn’t a terrible fit for projects with reasonably low degrees of uncertainty and where materials and capital expenditures dominated costs.
This company had a manufacturing legacy, and while they were starting to adopt Lean Manufacturing techniques, they still functioned in a primarily industrial age paradigm. We were a software project with high uncertainty and whose development costs were driven mainly by labor. We knew there were better estimation alternatives. By trying to operate in an agile way, we found ourselves as the round peg in this square hole.
Estimation Alternatives in the Planning Process
While we had management support for adopting more agile approaches, we had to adapt our preferred method to the company’s current state when it came to project governance. We couldn’t say, “We’re going to ignore the PPG and do our own thing.” We had to work with them. At the same time, we wouldn’t waste time and energy creating a project timeline based on a fixed set of requirements and estimates we knew were bogus. We needed to come up with some estimation alternatives. So we did two things: We looked at data and used that data to set budgets.
The development team had worked together on the previous release of the software, so we had historical data on their productivity. We used that to forecast – within a range – roughly how much we could get done in a given time. This wasn’t too different from what we had done with previous releases, although our data was much better this time around.
Developing Feature Budgets with T-Shirt Sizes
This time, we only did high-level estimates of the dozen or so features for the release. During a three-day workshop with about half of the team – including all of the functional roles we needed to release the product – we categorized these features into T-shirt sizes: Small, Medium, and Large. We didn’t do detailed requirements for each of them. The team had face-to-face conversations with the stakeholders requesting each feature. We did demos and held whiteboard sessions. We built prototypes in the existing code base. At the end of the second day, we could say, “Based on what you’re asking for, we think this is a Small/Medium/Large feature.” Based on our prior data and the desired release date, we knew roughly how many features of each size would fit.
When it became apparent that not everything that people were asking for would fit in the release, we started negotiating. Specifically, we started discussing what each feature would look like at a smaller size. That sounded like, “Based on what we discussed, this feature is a Large. We’ve only got room for three Large features in this release, and you’ve said this is the fourth most valuable one. If we didn’t do these three parts, that would make it Medium. Would it still be valuable enough without those parts to make it worth including in the release?”
These conversations were about being flexible on the scope of each feature. Features are rarely monolithic, but many planning and estimation processes treat them that way. Avoiding this trap was one of our most practical estimation alternatives. Throughout this process, we imagined several features in Small, Medium, and Large versions. Talking about these different versions gave us a sense of where our stakeholders thought the real value in each of them was. In none of these conversations did we discuss cutting corners on quality. At the end of the third day, we had a high-level idea of what we planned to include in the release and a reasonable degree of confidence we could deliver it.
Getting Project Approval
We worried whether a plan based on our estimation alternatives would pass PPG approval. We discovered we didn’t have to use the traditional requirements and project plan formats. Other groups in another part of the corporation were streamlining these, so we piggybacked on those efforts. We knew the PPG cared about the budget and expected return on investment. So we took the output of our workshop, combined it with the commercial justification (which they had approved at an earlier stage in the process), and made our ask.
Essentially, we said, “We intend to dedicate these three teams to this effort. Sixteen months from now, we will release a new version of the controls package. We intend to focus on these seven areas, spending roughly these proportions of our time on them. Within each area, we will collaborate with internal experts and customers willing to pilot new features to identify the most valuable features and work on them in that order. We plan to start with the items identified in this document. Based on our conversations and the productivity data from the prior release, we believe we can deliver the needed value in each area within those time budgets.”
That was what the PPG needed, and they approved us to proceed.
Working Within Our Feature Budgets
Our plan for the project was to work in a more agile way than we had before. Getting approval for that plan was an important milestone. Now we had to live up to the commitments we had made.
We were using Scrum on this project, with two-week Sprints. At the end of each Sprint, we did two important things. First, we updated our forecasts based on the work we had done. We tracked what we completed, what new things we discovered, and what still needed to be done for each feature. Second, we compared those forecasts to our budgets. Where the data indicated we wouldn’t need all the time budget, we didn’t worry. When it showed that we were over budget, we ensured we did the most valuable work first. That way, we could cut scope when the time ran out, knowing the items we omitted were ones the stakeholders agreed were less valuable.
We shared these updated forecasts in each Sprint Review. Our stakeholders were used to seeing a revised project plan, but having that alongside a demonstration of working software every two weeks changed their perspective. In the past, project plan reviews were just as fictional as the original plans. Sure, they would see an updated Gantt chart and a plan with a new “percent complete” number. But everyone involved had the experience of the first 90% of the project taking 90% of the time, while the remaining 10% took another 90%. Our estimation alternatives helped mitigate this risk.
Because we delivered and demonstrated working software every Sprint, our stakeholders were more confident that our forecasts reflected reality. In our bi-weekly Sprint reviews and monthly PPG reviews, we provided updates on where we were in our feature budgets. We said, “These things are complete,” and they believed it – because they’d seen working in production. Instead of questioning the plan, they talked to us about the product we were building. This represented a marked difference from how reviews had gone in the past – and a welcome improvement.
Looking Back at Our Estimation Alternatives
Sixteen months after we started, we released our product on schedule, on budget, and with higher quality than any prior version. It was a commercial success for the company. It was the lowest-stress release of this scale that any of us had ever worked on. We’d replaced the traditional suspicion and animosity between “the business” and “tech” with collaboration. We’d found a better way to deal with project governance.
Moving from feature-level estimates to feature budgets was the key to this approach. But we couldn’t just stop estimating. We had to adopt several critical practices to support that shift. In particular, we needed to:
- Create initial forecasts based on past data
- Replace rigid specifications with high-level direction
- Work in small increments
- Deliver working, potentially releasable software every sprint
- Engage our stakeholders frequently to gather feedback on what we delivered
- Continuously forecast as we worked
- Flex scope to stay within our budgets
For many organizations, adopting any of these practices represents a non-trivial change. We could only do it at this scale because of what we’d learned on two earlier agile projects. This release saw all the pieces starting to come together, and it remains some of the work I am most proud of.
This organization wasn’t ready to abandon its project-based approach and embrace a product-based funding model. When I left that company, the one I joined was living in that space. I’ll explain how they took the idea of feature budgets and estimation alternatives even further in part 2.
