View this email in your browser

Forecasting and Data Newsletter by Troy Magennis
Estimating the Impact of Adding People and Teams on Throughput/Velocity

Thanks for subscribing, and if you haven't yet (this newsletter was forwarded to you, or you clicked a link somewhere) consider subscribing: Subscribe here

If you like this content, please forward it to a colleague. 

If you didn't like this content, please email me why: Troy Magennis.

In this newsletter:

  1. Coming workshops and events you might be interested in.
  2. Article: The Impact of Adding People and Teams
  3. New Tool: Introducing "Blocked" Blocker and Dependency Tool
  4. About Focused Objective and Troy Magennis
Got Metric or Forecasting Questions? Contact Me

Coming Workshops and Events

Policy "Register once, attend many times"
All online training runs once per month, you can attend any session multiple times.

Policy "Attend online, and get a free 1-hour 1:1 with me after the training
It's hard online to get your specific questions answered. So, I don't try. After attending the training, you schedule a call with me.

Policy: All sessions are recorded and you get those recordings
Language sometimes is a barrier. Every session is recorded and you and replay it in your own time to make sure you understand every concept.

MONTHLY (online) Training
Practical Forecasting Essentials (online)
Practical product features and portfolio probabilistic forecasting.

Using the Monte Carlo Throughput Forecasting Spreadsheets
This two-hour online power-session discusses how to use the throughput and velocity forecasting spreadsheets.

Team Metrics: Using the Team Dashboard Spreadsheet
This two-hour power-session discusses getting started and using the Team Dashboard spreadsheet.

Prioritization and Cost of Delay Calculation
Prioritization and Cost of Delay Calculation Power Session

Article: How much improvement do I get by adding more teams or people?

You probably suspect that adding a second team doesn't always mean doubling the amount of work delivered. You probably also suspected that doubling the size of a team doesn't double the throughput. You're right.

TLDR; Use this calculator to quickly estimate the speedup by adding parallel people or teams. Unless they can work independently, don't bother - it's just expensive for no benefit.
See my ONLINE calculator

OK, so you asked for the detail, and I love you for that.

The amount of improvement assuming all skills and performance of the additional resources are equal (they won't be) is limited by how much synchronization and integration work is needed between the teams. Gene Myron Amdahl, set about giving us the formula to estimate the total computation speed improvement by adding more processors to mainframes, and his formula is known as Amdahl's Law.
Amdahl's Law helps us understand that it is the proportion of a "task" that can be parallelized that limits total computation speed improvement. For example, if we are sorting numbers, we can sort segments of data using multiple processors, but these intermediate results have to be synchronized into one result list. That synchronization/integration step can only be done on one processor which will limit the total improvement time.

Although I hate referring to people or teams as "processors" the principle of this law holds true for software work as well. When we set multiple teams (or people) to work on a larger task by dividing the effort, they have to integrate their work. If that integration work is large, the improvement of multiple teams will diminish.

We need to consider this diminished improvement when explaining why doubling the number of teams comes nowhere near close to doubling the amount of work we can deliver. Until we minimize, automate, or eliminate the integration steps required to co-ordinate that work, the improvement you will see might shock you.

Why is this the best case?

The original Amdahl's Law estimated improvement where the computation problem is fixed size. Highly unlikely in our case that every team does parallel work of identical size. Also assumed is that every team and person has the same individual performance. Also, highly unlikely in our case that every team has an identical skill in solving similar problems. The key point is: When you are forecasting, don't assume a HIGHER improvement of throughput than Amdahl's Law shows, and don't be shocked if it is in fact less.

What parallel proportion is common in Agile?

It comes down to how work gets integrated into the master code branch, tested as a whole, and deployed. The more automation you have to integrate earlier, the better the parallel proportion. I've not seen it above 80% unless it is a team with no dependencies on integration between them and production. If in doubt, use 75% if you have a single code-branch and fully automated integration and deployment. Go 50% if you have manual steps to integrate and deploy. Just guidelines.

How can we improve the speedup?

Simply put: Increase the parallelizable proportion to 100% by eliminating all sources of integration or dependency. It can be costly to get those last few percentages of parallelizable work, so don't go crazy!

Some ideas:

Single branch development - make people integrate early and often to avoid hard and problematic large integrations

Continuous Integration - integrate and regression test automatically on code check-in. Find those integration issues immediately.

Minimize cross-team dependencies - cross-train and distribute specialist skills that might be needed across multiple teams, not centrally in a single team

The Math: Amdahl's Law

\mathbb S_\text{latency}(s) = \frac 1 {(1 - p) + \frac p s}Slatency​(s)=(1−p)+sp​1​


  • ''S''latency is the theoretical speedup of the execution of the whole task;
  • ''s'' is the speedup of the part of the task that benefits from improved system resources;
  • ''p'' is the proportion of execution time that the part benefiting from improved resources originally occupied.

source: Amdahl's LAw - Wikipedia

New tool: "Blocked" Blocker and Dependency Management
I'm really excited to introduce my latest baby, "Blocked" a web application for capturing, managing, and eliminating blockers and team dependencies. It's in EARLY BETA now, and I'd love to have you on board to test it out.
A brief intro to BlockedApp. It is DRAFT - so give me feedback.

About Focused Objective and Troy Magennis
I offer training and consulting on Forecasting and Metrics related to Agile planning. Come along to a training workshop or schedule a call to discuss how a little bit of mathematical and data magic might improve your product delivery flow.
See all of my workshops and free tools on the Focused Objective website.

Got Metric or Forecasting Questions? Contact Me
Copyright © 2020 Focused Objective LLC, All rights reserved.

Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.

Email Marketing Powered by Mailchimp