Projected Velocity

A More Accurate Estimation of Velocity in Burn-Up Charts

The Burn-Up Chart is ubiquitous in Agile development. For those who may be unfamiliar, it is used to communicate development progress by visualizing the variance between the work you have already completed and the work you should have completed at any point in the program. However, the classical construction of the Burn-Up chart assumes that development starts at full speed and all at once¹. I haven’t seen it play out that way in reality due to any number of reasons (e.g. the team’s actual velocity doesn’t match the required velocity or time needed for developers to ramp-up on new technology or transition off other commitments isn’t considered.) We need a new path.

There are multi-billion dollar companies who are struggling with program reporting because, at its surface, program reporting isn’t super interesting. Simply, it’s an expected by-product of having a TPM, and it’s something to look at as the TPM talks about all of the stuff that the chart doesn’t contain: a realistic velocity, future plans, or expected effort. Why do we or our stakeholders need to jump through all of these hoops? It creates an atmosphere primed for inter-departmental friction. Projected Velocity² solves this.

Let’s look at some charts!

Classic Burn-Up Chart 1.0

The classic burn-up chart is very basic and makes the assumptions that all development starts at the same time and velocity is expected to be at 100% throughout the program. To represent this, we use three series of data:

Estimated Effort — A number representing the size of the development work for the solution³. As an aside, often leadership will request the use of Known Effort. We explore that concept in detail in a later section.

Progress — i.e. Completed Work. The sum of story points for work that has been completed (i.e. tested and accepted).

Velocity Guidance — The average number of story points required each sprint to complete the program on time.⁴

We’ll need to look at some real charts, so let’s set the stage for the conversations with some assumptions.

Assumptions

• The delivery date cannot be shifted.
• Scope cannot be reduced.
• Infrastructure design is efficient.
• We can’t take on tech debt.
• We are only considering one Agile team; although more can be added.
• The Agile team has 8 developers.
• All developers are at the same level and are expected to deliver 5 story points a sprint.
• The team’s expected velocity is 40 story points.
• The development window is 24 sprints.
• Engineering Leads have estimated the program to be 990 points.
• The team has completed 424 points.
• The program requires a 42 point velocity. (990 / 24 sprint = 42)

Figure 1. A traditional burn-up chart (called ‘classic 1.0’ in this article). Note Velocity Guidance has not yet reached the Estimated Effort.

Looking at the example in figure 1, we can discern a few things from the chart:

1. We are a bit more than half way through the program.
2. We should have completed 562 points, but we completed 424.
3. The program was slower to start than anticipated.
4. Since the team’s velocity is only 40 points and the program requires 42, the team is unlikely to complete the program with the existing resources.

Leadership is getting worried, and the meetings have been difficult. This is because what the chart isn’t demonstrating is your hard work facilitating a solution to get the program on track (after exhausting other strategies to maintain budget pacing, contractors will need to be added to the program). Unfortunately, the classic Burn Chart presents what’s already been completed. It doesn’t give insight into what will be completed. For that, we need to enhance the classic chart with forecasting.

Classic Burn-Up Chart 1.1: Basic Forecasting

Although the information we’re going to walk through will improve the chart’s message, this is an incomplete solution that should be considered a fair middle-ground if processes or partners don’t allow for the investigation necessary to build out the additional insight. I encourage everyone to push for more data through tools and workflows as a way to improve partnerships and gain deeper insight into the program.

Classic Burn-Up Charts 1.1 pull in two additional series to answer the question “when are we going to hit our velocity guidance?”

1. Planned Work — The story points scheduled in the next two sprints.

2. Forecasted Progress — the sum of planned work and the previous report’s progress.

We’ll also expand our assumptions to include the following:

• The team is getting support, starting sprint 25.16.
• We expect the team to double the velocity by sprint 25.20.

Figure 2 demonstrates Planned Effort (grey columns) being added to work already completed (progress).

Figure 2 shows Planned Work being appended to Progress, which quickly communicates the Forecast. In this scenario, the (now) two teams plan to complete 312 points over the next five sprints, which will put them slightly over what the model suggests.

Leaders will be thrilled to see this level of data, but there is more that we can do to communicate the health of the program and mitigate difficult meetings. That takes us to the Projected Velocity.

Projected Velocity

As mentioned, the Velocity Guidance in classic burn charts assumes all sprints are equal. There are no learning curves, competing priorities, or PTO. Because of this, the development often lags at the beginning of the program only to reach the necessary velocity multiple sprints into the development. Projected Velocity addresses this phenomenon by supporting variable capacity⁵.

We need to expand our assumptions one more time:

• Engineering Leads or Scrum Masters provided team allocation percentages that consider competing commitments, PTO, and knowledge shares.

The new calculation gives us a much more honest interpretation of the data. Let’s run through the sequence of events that leads me to that conclusion:

1. Engineering Leads estimated the features⁶ or capabilities⁷.

2. Engineering Leads also gave you their projection on the team’s capacity as they transition off other work.

3. You think through common PTO timeframes and include them in your calculation:

Figure 3 shows an example of how to determine team velocity throughout the year.

4. You get the team’s velocity from the Scrum Master: 40

Get Michael Rodighiero’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

5. Lastly, you multiply the sprint’s capacity with the team’s velocity and return the chart in figure 4.

Figure 4 shows the impact to the velocity. In Figure 1, the teams was behind only a sprint’s worth of development. This chart shows that it’ll be closer to 7 sprints.

It now becomes clearer that there is a misalignment between the scope of the product, the available developers, and the amount of time the team has to build it, but you have a significant runway to mitigate this risk.

Thankfully, since we conducted this analysis, we successfully lobbied to increase headcount via a vendor. Sourcing, hiring, and onboarding will take a few months, so we’ll need to double the size of the team to boost the Projected Velocity in the second half of the program (figure 5).

Figure 5. Teams were added to weight the output to align with your plan.

The chart is looking much better (figure 6). You’ve successfully communicated to all parties that development will be slow in the beginning, but you’ve mitigated the risk by engaging with a vendor who will have their team onboarded by sprint 25.16 to reach 100% productivity by 25.20.

Figure 6 overlays the team capacity on the team’s Projected Velocity to demonstrate that the increase in head count is directly tied to the expected velocity up-turn.

Using the Estimated Effort to calculate the Projected Velocity requires more upfront work, but it provides a cleaner and more accurate burn-up chart that will support you throughout the program. That’s not to say the Known Effort isn’t important to track.

Figure 7 is an example of what it might look like if the Known Effort is accumulating as the program is in flight. That metric only becomes important for the chart and program if it exceeds the Estimated Effort. If the extra effort exceeds the team’s output, you’ve uncovered a risk that needs to be addressed immediately.

Figure 7. A burn-up chart using the advanced metrics.

When using Projected Velocity, Progress will be more inline with your guidance, and conversations with your stakeholders will be focused on maintaining the plan, not fixing an underperforming program.

Known Effort, Expanded

I’m sure a few of you have been grumbling about how we should be using the Known Effort to track progress. That would be the best metric to use when determining the velocity guideline in the Classic Burn-Charts (note, the Projected Velocity Burn-Up Chart relies on knowledge of the team and their commitments); however, you’ve reached the struggle of combatting conflicting interpretation of Agile principles. That’s an entirely separate topic, but suffice it to say, depending on the size, there’s a really good chance you’re not going to know 85% of the effort within the first few sprints.

In an Agile environment, it can take a while for all of the stories to go through refinement⁷, and your understanding of the Known Effort is incremental. Since classic burn-up charts use this metric to calculate the velocity guideline, the velocity guideline will fluctuate as you learn more about the effort, making it impossible to know if you have the right number of developers until much later in the program when it’s harder to mitigate the risk.

Figure 8a shows how the burn-up chart would appear during the first sprint’s review where Known Effort is only 50 points. Figures 8b — 8d, Known Effort is increased incrementally, which changes the required velocity, having detrimental affects later in the program.

Figure 8 shows how the required velocity changes from sprint to sprint as more information is discovered. The program started off with needing 2 points a sprint, and in the course of 4 sprints jumped to needing 28 points a sprint. If the team was completing all work as it was identified, they would have completed 50 points by sprint 25.28⁸; however, we’d also be 62 points behind schedule⁹. This is problematic for several reasons, chief among them is you are going to have a hard time correcting the velocity, and that’s going to lead to difficult conversations and a lot of scrambling to mitigate the risk.

Objections & Obstacles

From conversations with TPMs, a handful of objections to the above (or any) approach came up:

Commonly used enterprise ticket management software (e.g. Jira) calculate program velocity using the standard methodology and do not support customization with basic licenses.

Making the changes to the software your company supports can be near impossible. It’s not worth the fight. I put a template that you can use here. Yes, it’s manual, but I hope that the data you need for the input is easy to attain. Updating shouldn’t take more than a couple of minutes once configured. Helpful hint: download the file.

Organizations are not using enterprise software effectively, and there is no desire to explore and commit to process changes required to implement such a solution.

Start small. Since change can be daunting to organizations, expect to calculate this manually with a team or two as a proof of concept. As leaders start to see the difference and the benefit, you’ll have an easier time getting commitment to roll it out more broadly.

If you’d like a head start, take a look at the template found here. Helpful hint: download the file.

Tool expertise is difficult to find.

I both agree and disagree with this statement. Finding someone with material knowledge of Jira or other CMS tools (i.e. more than ‘familiarity’) is a challenge, but the availability of knowledge is directly related to the second objection: organizations don’t like change, and it can be difficult to get teams to commit to new or changed processes or tool usage, so the tool remains poorly utilized, and knowledge isn’t advanced.

There needs to be two commitments:

1. From the leaders, we need you to re-evaluate the use of the standard burn-up chart and commit to supporting meaningful and reasonable change to process and tools that yield greater insight.
2. From the TPMs, we need you to commit to promoting our profession by advancing new or augmented workflows, reports, and tools that bring actionable insight to the leaders.

Partners don’t provide team capacity estimates.

Well that’s annoying, but it’s not the end of the world.

1. If you have historical team data, you can divide team velocity attained during the week of anticipated PTO by the team’s average velocity leading up to the observance to get the capacity percentage. Make sure you’re thinking about major calendars: corporate observance of national holidays and individual religious observances.
2. If you don’t have historical team data, talk to your peers and / or use your best judgement, but don’t go overboard. Having a sprint or two that has a slightly lower capacity percentage than what actually happens only helps you by making more progress than you anticipated; however, taking too much away could result in team expansion, which impacts budget.

Also, after you come up with your numbers, talk to your leadership to discuss ways to get the information in the future. They should have thoughts on what you can do to get the information or support you in your estimations.

Conclusion

Good data is important for a business to be successful. That’s a dumb statement, isn’t it? It seems obvious, and in many ways it is. You need to understand your costs and revenue so you can calculate your ROI¹⁰. Once you understand which product is more profitable (i.e. a bigger bang for your buck) you will know where to reinvest your profits and continue to grow your revenue.

If a CEO relies on Business Operations & Strategy’s ROI calculation and use of statistics to make informed decisions, why would we expect less when we’re discussing the type of data that we provide the stakeholders and leaders of the implementation and product teams? Holding on to a process that does not yield meaningful data (e.g. basing your velocity on what you need, not what you have — Classic Burn-Up charts vs. Projected Velocity) is rejecting a core objective of the TPM or PgM role: Continuous Improvement. Management, whether it’s over personnel, process, or product, requires the desire, will, and energy to fight for continuous improvement, and since it’s our role as the TPM to improve upon existing tools and processes as a way of improving partnerships, employee experience, and overall cost through efficiency, it’s up to the PMO to lead our partners through innovation when it comes to operational efficiency.

Classic burn-up charts work well for engineers who are hyper-focused on the performance of individual sprints. If research needs to happen before development, the engineers will create the spike or investigation ticket and assign it to a sprint based on the team’s actual velocity, not what the program needs. The result is the sprint metric looks great for the Agile team, but since development was delayed a sprint, the program is now (slightly) off schedule.

Because the burn-up is so often requested for program reviews, it’s time to redesign the information we use to communicate a more accurate plan and set the right expectations for our stakeholders. It’s time to start using Projected Velocity

Conversation Starters:

• What additional metrics have you been asked to provide, and how do you present it?
• What are the issues that you see with this approach? How would you overcome them?

Notes

1. View and understand the Burnup chart or report, Atlassian, 10/11/2024 ↑

2. The use of team configuration, commitments, and other variables to provide more reliable Velocity Guidance for the program. ↑

3. Engineering teams often provide estimates as T-shirt sizes, e.g. ‘Large’ or ‘X-Small’. Unless you have a standard rubric and are aligned on a developer’s velocity goal, these types of estimates are useless. If you don’t already use something, below is what a T-shirt size rubric might look like for a story or capability. For our purposes, a developer is expected to be able to produce 5 story points a sprint. ↑

4. Velocity = Current Estimated Effort / Total Number of Sprints in the Program ↑

5. Variable Capacity is the alteration of expected output due to conditions like ramping up on new technology, ramping down other commitments, PTO around holidays. ↑

6. Solution functionality that delivers business value, fulfills a stakeholder need, and is sized to be delivered within a planning cycle. “Feature”, Scaled Agile, Inc. 10/11/2024 ↑

7. A product, system, or service that provides value to internal or external customers. “Solution”, Scaled Agile, Inc. 10/11/2024 ↑

8. Known Effort = (4+6+12+28) = 50 ↑

9. (completed sprints x required velocity) - Actual Effort = (4 x 28) — 50 = 62 ↑

10. Return on Investment. The ratio between invested capital and the returned revenue. ↑