The myth that there is no estimation in an Agile development environment has been thoroughly debunked through various estimation strategies explained in articles like this and this.
There are great resources available to learn about Agile estimation and a tremendous amount of discipline that you can put in for your story-pointing process, but how does one successfully make the switch over to an Agile estimation model when you’ve been so used to a Waterfall process for so long?
We recently worked with a Fortune 500 financial services company that has an extensive history with various estimation tools and processes, but none that are aligned with the Agile and Test Driven Development (TDD) approach to which the IT group is moving. The business expected a certain level of cost certainty early on in the process (nothing new there), but the big thing is that they also needed some level of scope certainty as well which didn’t play as nicely in the new manner that IT was delivering projects.
We started by identifying the “quick wins” from a basic Agile estimation blocking-and-tackling standpoint that we could help them could achieve right away, such as:
- Ensuring items – both big and small – don’t get added to the backlog without an estimation
- Making sure all estimates have some notion of shared services time – things like QA, UAT support, release management, and production rollout activities need to be accounted for
- Connecting the sprint planning and backlog grooming process to the project and annual budget planning so that the boots on the ground estimations can feed into the financial plans for the company
- Communicating the prioritized high-level goals and objectives for the organization and/or solution so that the project team understands the most critical aspects and can incorporate that into project and sprint level decisions that are made
- Build an estimation tool to facilitate the story-pointing process where certain inputs could be loaded in and the resulting estimation incorporates data from historical actuals and previous lessons learned
If you’re not doing those things right now, start there. Remember that Crawl-Walk-Run is a good process for just about everything.
The next challenge was to help them start to change their estimation culture over the long term and implement something straightforward (super important in any situation), widely applicable (can’t just work for some teams but not others), maintainable after we leave (you have to let your baby go eventually), a natural extension of Agile methodology (no need to reinvent the wheel), and most importantly something that fully meets the business’ needs (since they fund the budgets for all this stuff – kinda important I suppose).
The really interesting thing is that following this approach should lead to the same outcome with the desired outcome of Waterfall or any other software development and estimation methodology. This is what we’re striving for by keeping these key characteristics in mind:
Accuracy
This is the ultimate goal of any estimation, right? My old standby of taking a developer’s estimate, doubling it, and adding half may turn out to be more accurate than that original developer’s estimate, but still isn’t really a tried and true approach. The key is to start by having the team fully groom backlogs at the feature level (including robust descriptions and point values) and then making sure that the backlog estimate becomes a primary input to budget planning and project initiation. This satisfies the team’s need to provide input into the estimation as well as the business’ need to have an estimation that can be used for the planning process. Once this process is in place, it’s also important to make sure there is someone (such as the PMO) accountable for tracking and revising estimation metrics based on measured actuals at least semi-annually. If you’re not continuously learning from your mistakes, then you’re never going to get better (and more accurate) about future estimations.
Efficiency
You don’t want to add a lot (or any, in reality) overhead to the estimation process through the mandate of additional tools, systems, or processes that will take the team away from actually delivering the work. This can be done by seamlessly incorporating the standard outputs from the delivery process (i.e. backlog and sprint planning) into the higher-level organizational goals such as project chartering, budget planning, and resource assignments. This is a shared benefit closely tied to the accuracy advantages described above with major efficiency gains resulting from the ability to leverage existing artifacts as key inputs to other areas of need as well as by realizing those gains through a recurring process to review the most recent outcomes.
Simplicity
The third big benefit that we’re trying to achieve is that feeling of simplicity that you get when things are working well together. It makes such a difference when one tool flows into another, multiple groups are collaborating leveraging the same resources to meet each group’s individual needs, and there is a refreshing lack of overhead involved because separate tasks aren’t done in a standalone manner or in silos. Many of the ways you can simplify your process is by incorporating the same activities that will help achieve efficiency and accuracy, such as rolling out a standard estimation tool that still allows for some team-specific tuning and making it impossible to forget to add in those shared services tasks by making it all-inclusive through the use of formulas and calculations.
Remember that this will be a new way of life for both business and IT, so it’s critical that both sides take the long view and strive to make it a collaborative, sustainable model. This will require leadership and direction by the sponsors, but also buy in from everyone involved in the process. It’s easier said than done, but once everyone is on the same page you can start seeing gains to your new approach and the transition should smooth out over time.
– Matt Barman, Principal & Founding Member
