Creating Reality-Based Forecasts in Agile Projects

Agile approaches for estimating and forecasting are better than traditional approaches because they deliver better and more predictable results. Agile project forecasts are also easy to understand and easy to update because they are based on the team’s actual velocity. This is what I call a reality-based agile forecast.

Traditional Project Estimating Approaches

Traditional approaches for estimating projects are ineffective and as a result, no one believes or trusts them. Worse, traditional projects are frequently on schedule right up until they are scheduled to launch and go live, and then you find out that they are going to be late. And then it is frequently too late to do anything about it. Which is one of the reasons that traditional projects are 3X more likely to fail.

I was a project manager working in waterfall and traditional approaches for over 20 years. I always knew the estimates we were using were best guesses and I felt uncomfortable that others treated them as commitments.

Stakeholders always wanted us to commit to those best guesses and then they would “hold us accountable”. Which usually resulted in an adversarial approach to estimating and a vicious cycle where technology would create heavily padded estimates that felt “safe”. It’s a crazy way to start a project.

Agile project management approaches for estimating and forecasting are superior and deliver better results. This is what I like to call, reality-based forecasting. Let’s dive a little deeper into reality-based forecasting and why I think that Agile Project forecasts are better!

Traditional Estimation and Forecasting

In a traditional plan-driven project, the planning is done at the beginning when we have the least information about the project. Most of the plans we create at the beginning of a project are incorrect.

And we get locked into those plans. As I mentioned in The Mindset Change for Agile Project Management, studies have shown that nearly 2/3 of what we build in a typical project is not actually needed or used.

The other major problems with estimation in a plan-driven project is that we are estimating phases that comprise different activities, like Analysis, Design, Development, and Test. Our estimates for one phase bears little relationship to the estimate for the others, and performance ahead or behind schedule on one phase doesn’t necessarily mean others will have the same variance to plan in the next phase.

The people doing the work of the Analysis phase won’t usually be the ones designing or testing. And since there is usually pressure to maintain a schedule, one phase is rarely completed before the next begins.

The traditional estimation approach uses an ideal timeline where one task starts immediately after its predecessor ends. It fails to accurately take into account lags and handoffs between various specialists working within one phase.

And then there is the real world where people are spreading their time among multiple projects and work sits around waiting for people to become available.

Another problem with estimating phases is that human beings are far too optimistic when it comes to estimating how long things will take. The bigger something is, the more likely we are to be under-estimating it.

Estimates and Forecasts in Agile Projects

Estimating Features and Stories

Estimation and forecasting in Agile Project Management is different. Estimating is done at the level of feature or customer need. The estimate includes all the work to complete that feature – analysis, design, development, and testing.

Most teams use story point estimates for the features. Story points are a form of relative estimation, a simple, fast, and precise enough way to estimate them. A team can estimate one item every 5 minutes or so using planning poker, or 100 items in an hour using affinity estimation. The sum of all the backlog items for the release becomes the size of the development effort.

These estimates are simpler because the features are small pieces of functionality and humans can estimate small things more accurately and consistently than large things. It’s also simpler because agile teams estimate together. When everyone on the Agile team participates, it is a form of crowdsourcing.

In addition to being fast, a key benefit of relative team estimation is the discussion that ensues. The discussion reveals assumptions and helps share the knowledge within the team. Most people feel that the discussion is more valuable than the actual estimate that is produced!

Finally, agile teams get a lot of experience estimating things, so they get pretty good at it. A typical Scrum Team will deliver 7-10 features or user stories every 2 weeks. This provides lots of opportunities to estimate and then to complete the work that they just estimated. These short feedback loops quickly improve the team’s estimation prowess.

Forecasting Agile Project Completion

Forecasting the completion of an Agile project becomes really simple. So simple that anyone on the Scrum Team including the Developers, the Scrum Master and the Product Owner, should be able to create or update the forecast very quickly. Most Scrum Teams update their forecast at least at the end of every sprint.

There are two main inputs to the forecast. The first input is the sum of the story point estimates for all the features in the backlog, or all the features in the next release. The second input is the forecasted velocity of the team.

The forecasted velocity is very straightforward for teams that are up and running. You can use an average of the last 3 sprints, or even take the latest sprint velocity as a forecast for the future. s an acceptable method. Using the previous sprint is also acceptable.

With these two numbers in mind, the forecast is created by showing a sprint by sprint burn up of completed work. Each sprint the Scrum Team plots the actual cumulative work completed, and then they use the velocity to create a forecast line for the completion of the rest of the features in the release.

You can see how this works in the two examples that follow – one created in Excel and another one hand drawn on a flip chart and hung in the team room.

Keys to Success with Agile Forecasts

In order for reality-based forecasting to be effective, there are a couple of requirements. First, we need the team’s past velocity to be a good predictor of the future. This is one of several reasons why it is a must to have team members dedicated full-time to just the one team.

With partial contribution or rotating team members, commitment is weakened and performance becomes less stable and predictable.

Similarly, changes to team members should be minimal from sprint to sprint. We want long-term stable teams that have a predictable delivery rate. Teams should be left together for long periods – years if possible. I know that there is turnover and other reasons for change, however, if the team is constantly churning you won’t have stable and predictable velocity.

So, don’t form and reform teams on a regular basis. Whenever you add or delete team members, you can expect the velocity to go down as teams repeat the forming, storming and norming stages of Tuckman’s team development model.

Finally, estimates are most accurate if the team doing the work completes the estimates. Some organizations will have an architect or lead developer estimate everything. I guess they believe that person is the smartest, and by implications, others are not.

Don’t do it. Estimation is a discovery and learning process for the team. The best estimates are going to come from the full team who is responsible for delivering the work.

Henrik Kniberg does an excellent job of describing estimation and forecasting in his 16 minute video, The Agile Product Owner in a Nutshell. That is a video that I recommend to people new to Agile all the time because while he covers the Product Owner role, he also describes how Agile teams work.

How about you? Is your team using reality-based forecasting? I would love to know in the comments section.

This article originally appeared on Viality Chicago’s Blog and has been republished with permission.

Business & Finance Articles on Business 2 Community

(47)