Coaches and Practitioners of Lean-Agile and the SAFe®
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 REvolution. I like to poke fun at our favorite thought leaders and how they love to redefine things in their own terms to somehow make their version more valid. So, let’s start by diving into the lively and oftimes crazy world of Agile word re-defining.
What the heck is Agile “Velocity?”
In the SAFe velocity and capacity are used interchangeably as part of the forecast and hypothesis’. I disagree with the overloading of terminology but it is how the good folks at Scaled Agile teach it. Also, in the SAFe, velocity is related to the program as part of a normalized estimating paradigm of 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. If teams independently estimate in completely foreign ways then the program (and ART) lacks the capability to scale up estimating/forecasting to the program, solution, and portfolio levels. There must be some commonality across teams such as using the same modified Fibonacci sequence, cadence, sizing/slicing patterns, et cetera.
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.
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:
- 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 capacity-based planning. The strategies for planning drive why the SAFe uses the terms interchangeably. I find this to be confusing, especially for students that are new to Agile and the SAFe. I petition the SAFe Fellows and product owners to consider changing or dramatically improving the language and training materials.
This is why the tool I created came into existence. The SAFe PI Planning event includes an agenda that drives teams to produce great plans they can commit to. The first team breakout session has teams set to calculate velocity for each iteration in the program increment. Then teams begin planning their work. For teams that have little to no experience with Agile, 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 calculations at start and to perform capacity planning I created a simple spreadsheet tool.
The VelociPacity 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.
#SAFe #capacityplanning #estimating #agile #scrum #lean #lean-agile #continuouslearning #relentlessimprovement
#calculating normalized velocity safe