Forecast the Feature Completion Date
Anyone who’s led an agile team has run into this challenge: project stakeholders want to know when things are going to be done. Internally, it can be tough to communicate some of the forecasting constraints in agile to business leaders. But when you’re a consultant, this challenge can make or break your contract. Here’s one example of how I used deterministic agile to give my client the answers they needed and provide scheduling certainty.
The Need for Certainty
For one of our projects, we had a project sponsor who needed to understand what features could be done by the end of the contract. This helped him determine if he needed to move internal resources to join the project or start communicating internally to reset expectations.
The project sponsor also wanted a roadmap of when certain features would be started and completed. That allowed him to schedule internal previews appropriately with the knowledge of what features would be complete or close to completion.
The first try at this road map was a rough estimate based on experience and intuition. While this was okay in the beginning of the project, more specificity was needed once we were further along.
According to the cone of uncertainty, estimations made on intuition alone can be inaccurate by a factor of four (The Cone of Uncertainty | Construx). The project sponsor needed a data-driven estimate to feel confident in what we were going to accomplish. Intuition alone would leave too much to chance.
Data-Driven Forecasting
The beauty of agile is that there’s a focus on capturing team metrics, so we had some data we could crunch to better estimate future features.
Since we were a third into the project, we had a feature complete we could use as a baseline. We initially t-shirt sized this feature as a small, and it took the team a sprint to complete. We calculated that we spent 40 points on the feature, so we had an initial baseline of small equals 40 points. If a small took the entire team one sprint, then we assumed extra small would take one developer an entire sprint to complete.
Now that we had a baseline feature with a t-shirt size and point value, we could go back to all our other t-shirt sizes and see how this affects the total scope of the project.
All these features together gave us our total scope of the project.
While this was a good start, we needed to go higher in the certainty-cost asymptote faster. We needed to be more certain; therefore we needed more information.
Deterministic Agile: Straddling the Waterfall-Agile Spectrum
The more information you have about your future features, the more accurate you can estimate feature scope. We took a page out of the Waterfall playbook and told our product owner we needed enough information to assign point values to each feature.
Deterministic <——————————————————————————————> Non-Deterministic
On the Waterfall-Agile spectrum, we needed to move closer to waterfall.
This required the Product Owner to be as specific as possible about upcoming features and get help from the design team.
A rough feature sketch is good enough to make sure it captures the details of the features. Pixel-perfection isn’t necessary. The goal is to get as much information as possible to make as accurate a point estimate as possible. This will take time, so it will cost some velocity points from the team as the team works to estimate future work instead of work on current features.
With upcoming features better fleshed out, we could assign point values and give a more accurate representation of total scope. During this process, the product owner also learned more about what could be pushed to the second release, which is represented by blank lines on the chart.
Now with more certainty we had an updated total scope.
The team also reached a predictable velocity of 47 points a sprint.
With the total scope and the team’s predictable velocity, we could estimate when we’d be done with all the features.
This is reflected in the project burn up chart. The total scope is in blue. The green, yellow, and red lines reflect different assumptions in the velocity. The green line assumes the team trends 20% faster, the red line assumes 20% slower, and the yellow line assumes the team trends at the same velocity.
This chart aided in our conversations with the project sponsor and let us speak to how adding, removing, or changing features changed the project scope and affected the completion date. We could also make changes to the team’s velocity based on known vacations and speak to how this affected the forecasted completion date.
With the total project scope and a predictable velocity, we could create a roadmap of the project. Everyone across the entire project knew what features the team was going to work on next, and we could accurately move features around upcoming sprints if necessary. Since we knew how many sprints each feature was going to take, we could create a roadmap that was driven by data and not by optimistic thinking.
This met the expectations of the project sponsor as he could confidently speak to his peers about the planned project completion date, features completed thus far, and upcoming features. This allowed him to generate excitement across his organization through internal previews.
If you’re interested in learning more about how you can apply this approach to your projects, read this step-by-step guide on putting deterministic agile into practice.
