---

By Adrian McGrath, Digital Strategist and Digital Business Lead

7th December 2020

---

The BIG Question

Agile projects, by their very nature, are fluid and adaptable. Unlike Waterfall projects, in Agile the project scope is variable, with requirements captured incrementally throughout the project, documented as User Stories, broken down within Features and grouped into Epics, all placed into the Product Backlog.

It is for this reason that Project Managers on Agile projects often dread the question “Are we on track?” It can be a difficult question to answer as the scope is variable and ever-evolving. It is usually answered with a string of caveats that can have the unfortunate effect of creating doubt and anxiety in the mind of the business.

Within this post, I share my thoughts on a model that I’ve seen successfully address this question by making better use of the data available in an Agile Scrum project and promoting greater collaboration and joint responsibility between the business and the project team. For context, I have never played the role of Product Owner or Scrum Master. However, I have been Delivery Lead on many Agile Scrum projects and that is the perspective I am coming from within this post. Some people reading this post will have successfully used other techniques and tools, and I would love to hear from you. My model is just one approach and I am sure there are many more.

Why is that question important?

When providing funding for a project, the business sponsor (often the Board) is predominantly focused on why they are investing and what outcome they want to achieve within a certain timescale. They tend to be less concerned about how the work will be undertaken, offering autonomy to those with the right expertise in the project to select the best means to implement it.

A key “how” decision then made at the outset of a project is what implementation approach to use, with Agile increasingly becoming the de facto choice over the more traditional Waterfall. Agile projects will sometimes achieve the end-goal outcome faster and at less cost than Waterfall, however, there should not be an expectation that it does. The real benefit of Agile is on achieving a better quality outcome and one that is more likely to deliver the business value expected. In this regards, let’s assume that the budget and timeframe is the same, irrespective of whether Waterfall or Agile is selected.

The problem I see with Agile, if left unchecked, is that the forward view into the project is too short and it can sometimes run away with itself, such that the expectation to complete the outcome within budget is forgotten until too late.

Conversations such as the following are common:

“Are we on track?”

“Well we are four sprints into the project and we’ve completed all of the User Stories assigned to the first four sprints, so yes, I would say we are on track.”

“But what about the rest of the scope, will it be delivered within the remaining sprints that we have budget for?”

“Too early to say, we haven’t got to them yet. This is Agile.”

“So you don’t really know if we are on track?

“Well … no.”

The Business Sponsor has provided funding to achieve a desired outcome within a specified timeframe. Agile projects tend to be costed out, with a run rate per sprint, adding up to the total budget and timeframe. However, just because we’ve selected the Agile “how” route, doesn’t mean we can pay lip service to staying on top of achieving the expected end-goal outcome within budget. Otherwise we run the risk of getting to the end of project and having a product/solution that is, say, 90% complete. That means it most likely can’t be deployed into production (perhaps due to missing functionality) and can’t deliver value to the business. And we’re out of budget. This is a really bad situation to be in. It would be much better to reduce non-core features earlier in the project so as to have a solution that is 100% ready for deployment into production, introducing dropped features in a future phase. Agile allows for this flexibility, but we sometimes take our eye off the budget and neglect to measure if Agile projects are on track against budget and take early, corrective action if not.

Key areas where Agile can take eye off budget

Forward view is too short

As in conversation example above, there are often Features, and sometimes entire Epics in the Product Backlog where the documented requirements merely consist of a headline statement. Essentially, there are lots of “empty” slots in the Product Backlog, as illustrated in the figure below.

Many people may say, well this is Agile. However, the problem here is that we can’t answer the “Are we on track?” question unless we have some level of understanding, and broad estimate, of all of the Epics in the Product Backlog, acknowledging that this view will most likely vary as the project progresses.

Not taking corrective action when overrun occurs

This point is perhaps best illustrated by example. Let’s assume an Agile project has 5 Epics. At the outset of the project when funding was approved, the project may have been expected to play out over 9 months, with an indicative timeline for the Epics laid out (as part of the due diligence behind the investment).

However, 4 months in, it becomes clear that Epic 2 is going to take an additional 4 weeks and, with greater definition of requirements now known, Epic 3 will also likely take an additional 4 weeks. Let’s assume that the reason for the additional time is because the business decided to add more functionality in the product/solution, which only became apparent when they saw the product/solution evolve and decided that it needed additional functionality that they hadn’t thought of before. This is all perfectly reasonable and a core benefit of executing the project using Agile.

Nevertheless, it does mean that the combined impact of the additional functionality requirements means that the project is now predicted to take an additional 3 months (assuming we have a forward view of the Product Backlog).

In situations such as this, it is critical that a flag is raised to the business, highlighting that the extra functionality request will push the project beyond the budget, giving the business essentially three choices:

1. Scale back or drop some requirements to fit within budget – if not the new functionality, then something else has to give;
2. Increase the budget and probably the timeframe for the project;
3. Leave it for now as it might balance itself out later in the project.

This flag could probably have been raised by month three. What is key here is that we are able to track that the Agile project is predicted to extend beyond the budget, flag this to the business and allow the business to make an early and informed decision on scope. However, this isn’t practical to do unless there is a forward view, with estimates, in the Product Backlog. There needs to be a model in place to track the project.

The Model

To set the model up:

1. Everything in the Product Backlog needs to have a Story Point estimate (no “Empty Slots”) and tagged with one of the following status categories; “Completed”, “Ready”, “Base”, High-Level” and “Educated Guess” (explained in figure below). Ideally the estimates need to be against User Stories. However, in the earlier stages of the project, this won’t be possible as the requirements won’t be captured in detail yet. As such, if the User Stories are not yet defined for an Epic, then provide an estimate for the Feature. In turn if it is still too early to estimate at Feature level for the Epic, then provide an initial estimate for the Epic itself.
2. A Confidence Weighting needs to be assigned to each status to reflect how accurate you think the estimates are. This will most likely be adjusted as the project progresses and the estimates are validated.

With this in place, the following figure below illustrates how the “Are we on track?” view may change over the course of an Agile project.

In the example above, 4 sprints in, there is only a 55% Confidence that the project is on track as there are too many Epics/Features/User Stories that are estimated at “High-Level” and “Educated Guess”. This is to be expected in the early stages of an Agile project. However, at least there is a view as to how long the project could take, a view that is acknowledged will change as the project progresses and more requirements are captured, adding greater precision into the Product Backlog. Therefore, the degree of confidence about whether the project can be complete within the designated timeframe will naturally increase with every sprint.

With Agile, we don’t have the design completed up-front. Rather there will be lots of unknowns and the only thing we are certain about is that things will change and evolve. As such, providing estimates based on confidence weightings allows us to give a view, at a point in time, as to whether the project is on track, caveated by a single Confidence Factor.

Note that for this model to work in practice, it is assumed:

• In general, User Stories assigned to sprints get completed within the sprint (i.e. there isn’t a trend of incomplete stories moving into subsequent sprints);
• The Scrum team is operating at a maximum, reasonable sustainable level.

So, are we on track?

At the outset of the project, we need to make an assumption as to what the Scrum team Velocity is likely to be, taking likely annual leave into account. This can then be validated about 3-5 sprints into the project when the Velocity usually reaches a steady state as the team gets into a rhythm. This will give us a view as to the likely Scrum team capacity over the project duration.

Answering the question “Are we on track?” is then simply a case of:

If the estimated Scrum Team allocation of Story Points over the duration of the project does not exceed the Scrum Team Capacity, then YES, we are on track with a Confidence Factor of X%.

This concept is illustrated in the Dashboard below.

Using the same data to answer the “Are we on track?” question, we can also get insight into the likely cost per Epic and how much of the budget has been spent in comparison the scope completion progress of the project.

Final thoughts

Models like this go a long way in building TRUST with the business, allowing much greater positive and collaborative focus on driving the product/solution forwards. Ideally the base model should be assembled in Sprint Zero and evolved thereafter.

Defined business requirements (written up as User Stories) are the fuel that drives the Agile projects. I believe that this model strongly encourages much greater business stakeholder participation in the requirements capture and definition, critical to the success of the project, as they will have a heavily invested desire to increase the Confidence Factor.

To date, I’ve implemented the model in Excel and used it in combination with Agile Management Tools such as Azure DevOps and Jira. However, ideally and with customisation, the model should be embedded within such tools rather than sitting outside them.

• Agile
• Model
• Scrum