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. 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. 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]). In vanilla scrum velocity is only relevant to the scrum team. The program level normalization in the SAFe is actually quite rational and necessary. If teams independently estimate in completely foreign ways then the program (and ART) lacks the capability to scale up estimating to the program, value stream, and portfolio levels. There must be some commonality across teams such as using the same modified Fibonacci sequence, cadence, sizing patterns, et cetera.
So let’s define “velocity” in Agile terms before we get started so that we have a shared understanding.
The various glorious inconceivable Agile definitions:
The team’s velocity for an iteration is equal to the sum of the size of all the stories completed in an iteration – Dean Leffingwell, Scaled Agile, Inc., the SAFe.
Velocity is a capacity planning tool sometimes used in agile software development. Velocity tracking is the act of measuring said velocity. The velocity is calculated by counting the number of units of work completed in a certain interval, the length of which is determined at the start of the project. -wikipedia.com
Velocity is an extremely simple, powerful method for accurately measuring the rate at which scrum development teams consistently deliver business value. – VersionOne
1) Velocity measures how much functionality a team delivers in a sprint.
2) Velocity measures a team’s ability to turns ideas into new functionality in a sprint.
– Mike Cohn, Mountain Goat Software
Now, you won’t find a definition of velocity in the Scrum Guide at scrumguides.org. You will find dozens of definitions at the Scrum Alliance community forum. Ditto for scrum.org. People seem to get wrapped around the axle about what Agile velocity is supposed to be.
In Agile terms, "velocity" of the team is simply the average value of an agile teams delivery in the last few iterations in the form of normalized story points. The velocity of an iteration is the value of the agile teams delivery in that iteration in the form of normalized story points.
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