Recently, on a private forum, a member posted a query about their team’s recent drop in Velocity. Concerned about how their boss would respond, this individual wanted to know how to troubleshoot velocity issues.

After spending over an hour crafting a response, I decided I would also add it to my public blogs in case there are others who have similar questions about velocity.

Velocity doesn’t tell you much

Velocity cannot tell you much about what transpired over the course of an iteration, except that the team produced more or less units of work based on whatever measurement you are using. A higher velocity may not indicate better performance and a lower velocity may not indicate a drop in performance. And variance in velocity rarely indicates a variance in how hard the team is trying.

What you can look at

If you have historical data available, I'd run a cumulative flow diagram to see if you can easily identify bottlenecks in the flow of work.

Beyond that, there are a few things you can easily look at that typically impact velocity; Work In Progress, Batch Size, and Dependencies. You may be able to suss out these factors in an open discussion and evaluation of the work in the prior iterations.

Work In Progress

In general, the more items a team works on, the longer it takes to complete each item. As a general statement, if there are more items in "Doing" than there are members of the team, there is a problem. The more a team tries to achieve all at once, the less they complete in a given time box.

Let's take a look at a very simple example:

An individual is assigned 5 tasks (A,B,C,D,E), each of which takes 2 days to complete. Each iteration is 5 days long. They can do the work in sequence, focusing on one item at a time, or in parallel, giving each item 2 hours per 8 hour day.

Sequence:

Day 1 - A
Day 2 - A
Day 3 - B
Day 4 - B
Day 5 - C
Iteration 1 - A = 100%, B = 100%, C = 50%, D = 0%, E = 0%
Day 6 - C
Day 7 - D
Day 8 - D
Day 9 - E
Day 10 - E
Iteration 2 - A = 100%, B = 100%, C = 100%, D = 100%, E = 100%

Parallel:

Day 1 - A, B, C, D
Day 2 - E, A, B, C
Day 3 - D, E, A, B
Day 4 - C, D, E, A
Day 5 - B, C, D, E
Iteration 1 - A = 50%, B = 50%, C = 50%, D = 50%, E = 50%
Day 6 - A, B, C, D
Day 7 - E, A, B, C
Day 8 - D, E, A, B
Day 9 - C, D, E, A
Day 10 - B, C, D, E
Iteration 2 - A = 100%, B = 100%, C = 100%, D = 100%, E = 100%

With either approach, we get all the work done in two iterations. But working on the items in sequence, we complete two of them in the first iteration, whereas working in parallel delivers no tangible value in the first iteration.

Now, let's take another look at the choice to work on parallel.

Parallel (take 2)

There have been plenty of studies on the impact of multi-tasking and context switching in our work. As a general statement, each new item we attempt to focus on comes at a 20% cost. For every item, we add an additional 20% to the duration of all items due to the cost of context switching.

To avoid getting into the compounding that actually happens, let's run our scenario again, assuming an overly simplified 25% duration increase when we attempt 5 items in parallel.

Day 1 - A, B, C, D
Day 2 - E, A, B, C
Day 3 - D, E, A, B
Day 4 - C, D, E, A
Day 5 - B, C, D, E
Iteration 1 - A = 37.5%, B = 37.5%, C = 37.5%, D = 37.5%, E = 37.5%
Day 6 - A, B, C, D
Day 7 - E, A, B, C
Day 8 - D, E, A, B
Day 9 - C, D, E, A
Day 10 - B, C, D, E
Iteration 2 - A = 75%, B = 75%, C = 75%, D = 75%, E = 75% Day 11 - A, B, C, D
Day 12 - E, A, B, C
Day 13 - D, E, A, B
Day 14 - C, D, E, F
Day 15 - G, H, I, J
Iteration 3 - A = 100%, B = 100%, C = 100%, D = 100%, E = 100%, F..J = 9.375%

Limiting Work in Progress allows the entire system to deliver value sooner and be more responsive while creating a more stable and predictable throughput (or velocity).

Batch Size

Batch size refers to the amount of work that moves from one stage to the next. In software development, there are a number of possible batch sizes. There is the size of a particular work item or story. There is the size of the feature the stories comprise. And there is the batch size of the release itself.

The larger a batch, the longer it takes to get done. The longer a batch takes to get done, the less responsive the system can be. The less responsive the system can be, the more up-front planning is required.

And to our original concern of variable velocity, the larger the batch size, the greater the risk. Big tasks have more unknowns baked into them. The larger the average task, the greater the variance in completion time. By chunking our work down into smaller pieces and releasing more often, we actually reduce risk to the project and create a more predictable pace of delivery.

Dependencies

If some of our tasks are dependent on others outside of the team, we have less control over when the work will be completed. If other teams are not also limiting WIP or keeping batches small, then for every task that could be completed in a week, we can anticipate 3 to 4 weeks before it gets done.

Many organizations centralize or stratify certain functions. Everyone should perform user acceptance testing, so they centralize the function to ensure they are following "best practices" and to maximize the utilization of testing resources. Writing web pages is different than writing web services, so they stratify these functions, putting specialists together into groups reporting to other specialists - again to ensure consistency and "best practices" while also maximizing the utilization of these specialists.

While the intention is to improve the system of delivery, when organizations create these strata and silos, they impede progress and incur significant overhead. There are entire teams of people who now need to manage dependencies on projects. Each group is typically working on multiple initiatives for multiple internal customers at the same time (increased WIP). To manage all of this, they need more up-front design and then, given the difficulty keeping everyone in sync, they integrate less often (increased batch size).

Look for frequent dependencies between groups and find ways to reduce them. Shuffle the team structure, share talent across teams, increase the number of touch-points, reduce the number of simultaneous large initiatives in a department....