Coaches and Practitioners of Lean-Agile and the SAFe®

UPDATE: I have updated the tool for SAFe 5.0! See below.

In my experience the amount of time that we get to spend in Lean-Agile and SAFe® courses on the subject of Velocity and Capacity Planning is inadequate. So I spent some time building a tool for one of my client organizations. I have since spent some time greatly enhancing the tool and getting it ready for distribution. I am offering the tool for free. All that I ask is if you decide that the tool has value and you are going to use it, to like my blog and share feedback for improvement. Perhaps even share this article on your favorite social media. 

There are so many definitions in the wild for (Agile) “velocity” and “capacity” that I’m going to attempt to clear the way for folks that are new to the Agile R-evolution. So, let’s start by diving into the lively and of-times crazy world of Agile.

What the heck is “Velocity?”

In the SAFe velocity and capacity are used interchangeably as part of the forecast and hypothesis’ in PI Planning as part of the function of capacity management at scale. I disagree with the overloading of terminology but it is how the good folks at Scaled Agile teach it.

Also, in the SAFe as with other instances of Scrum or Iterative Development, velocity is related to the program [now Essential layer or network node construct] using an additive function. The velocity of an essential network node construct becomes part of a normalized estimating paradigm and consequently the team of teams (an Agile Release Train [ART]). When used in vanilla Scrum, velocity is only relevant to the team. It is important to note that velocity is not part of Scrum (scrumguides.org). Neither are user stories (XP).

In program level context (SAFe/ART), normalization of velocity and the use of story points as currency in the SAFe is actually quite rational and necessary for capacity planning and management at scale. If teams independently estimate in completely foreign ways then the program (and ART) lacks the capability to scale up estimating/forecasting to the program, large solution, and portfolio levels. There must be some commonality if not standardization across teams such as using the same modified Fibonacci sequence, cadence, sizing/slicing patterns, et cetera.

A SAFe Portfolio could also go the #noestimates route after establishing normalized flow by simply using throughput. This presents lots of challenges at scale however and only works in the most disciplined businesses and organizations. Or with small groups of teams or single teams. I actually haven’t seen any evidence of this working at scale in a large enterprise.

Read: An aside about Business Value

Defining Velocity – read the full article here.

For long-lived “teams”, “velocity” of the team is simply the average of the team’s delivery of working product/service (valuable) in the last few iterations in the form of normalized story points.

The velocity of an iteration (or sprint) is the aggregated amount of the team’s delivery of working product/service (valuable) in that iteration in the form of estimated story points. NOTE: teams do not go back and estimate actual story points. That is a complete waste of time and defeats the lean intent of story points.

Teams do not re-estimate the actual story points to move a story to a completed state.

The value of the estimate is driven by the content and character of the conversation surrounding the estimate. Retrospective events are used to improve the teams estimating techniques.

As an example, the velocity of a projectile issued from a cartridge in a firearm is unknown until actually fired and the speed measured. It is useful to know the “forecasted” or “projected” velocity of a particular cartridge in shooting sports prior to expending the cartridge. Especially at long range.  The forecast for a given cartridge recipe, or average velocity, is accomplished by collecting data from test firings of many cartridges in standardized tests. Manufacturers publish the average velocity so that users may forecast performance of the cartridge. If you purchase a box of cartridges and measure the actual velocity / performance of say,  20 cartridges, you will find that the velocity changes for each round (especially in lower quality ammunition). Even when fired from exactly the same firearm. Variables such as weather, geography, arc/gravity, powder chemistry and amount, and the physics of the cartridge, projectile, barrel and action affect the outcome. So there are really two versions of velocity in this example – forecasted or average and actual. Actual velocity of each data point individually is of no value. A sufficient sample size must be observed to determine a predictable velocity used for forecasting performance of the cartridge under normal use.

The same logic applies to teams using velocity.

Normalized story points come into being by a team using a consistent relative estimating technique and additive system. Many factors affect the teams ability to normalize estimating. Feature slicing patterns, discipline, repeatability, et cetera, may all affect normalization.

Story points, the currency of SAFe, have four parts:

1. volume
2. complexity
3. knowledge
4. uncertainty (dependency/risk)

Well, O.K. I understand Agile velocity now. What about “Capacity?”

I like the wikipedia definition of velocity in terms of explaining what Agile capacity is. It captures the essence of how we use the term in Agile. It is also important to note that velocity and capacity are two different things. Think of it this way.

Velocity is what we did the past.

Capacity is what we have potential to do in the future.

Some more definitions.

Capacity of an agile team is an important measure that should be used to inform the team how much workload it should undertake during its sprint planning meeting for an upcoming sprint. – VersionOne

In commitment-driven sprint planning, a team commits to one product backlog item at a time by roughly identifying and estimating the tasks that will be involved, and stopping when they feel the sprint is full.

Because “commitment” is often mistaken as “guarantee,” this approach is becoming more commonly referred to as capacity-based sprint planning. – Mike Cohn, Mountain Goat Software

In the SAFe we actually use velocity-driven (and/or throughput) and capacity-based planning to manage spend and enable capacity management. The technique used for planning drive why the SAFe uses the terms interchangeably.

This is why the tool I created came into existence. The SAFe PI Planning event includes an agenda that drives teams to produce plans they can commit to. The first team breakout session has teams set out to calculate informed, forecast capacity for each iteration in the program increment. Then teams begin planning their work. For teams that have little to no experience with Agile, Scrum, the Lean-Agile mindset or planning in team of teams formats the experience can be a bit overwhelming. Sitting down as a team with limited time to create a committed plan for the first time is hard. But hugely valuable.

In order to expedite the learning process and help teams to come to an understanding of how to do velocity and capacity calculations at start and to perform capacity planning I created a simple spreadsheet tool.

The Tool

If you are interested in getting a copy of the MS Excel Spreadsheet version of the tool please like this article and follow my blog including a note about the tool. And well, since no one took me up on the offer after a few days I added the link to download the file below.

Download or download from the google share.

#SAFe #capacityplanning #estimating #agile #scrum #lean #lean-agile #continuouslearning #relentlessimprovement

#calculating normalized velocity safe