Tag Archives: scrum

This is not a manifesto: Valuing Throughput over Utilisation

In a previous article, This is not a manifesto, I expressed the values I hold as a software development team member. Today, I’m going to talk about the first of these values.

Before I do, I’d like to say what I mean by “software development team”. I mean a cross-discipline team with the combined skills to deliver a software product – product owner, user experience, business analysts, programmers, testers, dev-ops, etc.

A common problem

Many teams I encounter will, at least in the beginning, have team-members who specialise in a single role. Each team-member will rarely, if ever, step outside their job description [1]. This can cause a problem.

Many teams find themselves in a situation where some team members have little to do on the current stories. At this point, the team has some choices, they can focus the under-utilised people on:

  1. Future user-stories, working on tasks most relevant to their job title
  2. Another team, working on tasks most relevant to their job title (e.g. ‘matrix management’)
  3. Current stories, taking on tasks that will take the story to completion sooner, even if it’s more relevant to someone else’s job title
  4. Things that will make the more utilised people get through their work faster, today and in the future.

More often than not, I find teams taking option 1. I think that people choose this option because it feels like it should increase the throughput of the team – i.e. the amount of new features they can add to the product. In fact, it has the opposite effect.

Little’s law

Let’s consider a team that is working in time-boxes or ‘sprints’ (à la Scrum) and measures it’s throughput with ‘velocity’ (story-points per-sprint). Points are accrued as each user-story is completed – i.e. coded, tested and product-owner validated.

In this particular team, it is able to complete an average of 10 points per sprint. Let’s say this is due to a bottleneck in the process. This bottleneck might limit the amount of testing that can be completed during the sprint. This is illustrated in fig.1 where each ball is a story point.


Shows a system through which a series of balls are being processed. Each ball represents one story point. It also shows that there is spare capacity in the team.

Shows a system through which a series of balls are being processed. Each ball represents one story point. It also shows that the spare capacity in the team has been used up, even though it does nothing to increase throughput.

Little’s law [2] tells us that the amount of time it takes to complete an item of work (cycle-time) is:

        Work in Progress (WIP)   

Which we can read as:

   story points in progress

In this simplified example, WIP is 10 points and throughput is 10 points per sprint. The average cycle time of a story is therefore 10/10 = 1 sprint. Notice, however, there’s all that spare capacity.

Let’s say this spare capacity is developers. So, the team starts taking on more user-stories from the backlog – increasing the number of story points in progress to 20 points (fig.2).

Because the bottleneck remains, velocity remains the same – 10 points per sprint. The amount of flexibility that the team has, however, is now reduced because the average time required to get a story to completion has increased from 1 sprint to 20/10 = 2 sprints [3].

Often this will take the form of testers working a sprint behind the developers. Worse still, over 10 sprints, the team still only completes 100 story points (as they would have before) but is left with a lot of unfinished work. This ‘inventory’ of unfinished work carries overheads which can, ultimately, reduce the velocity of the team.

The impact of filling capacity in this way has yet another effect.

Latency effect

As the developers get through more stories, a queue of stories that are “ready for testing” will build up. Testers working through these will, at least, have questions for the developer(s) or even find some defects. The developer, having moved on from that story, is now deep into the code and context of another story. When the tester has questions, or finds defects, relating to a story that the developer had worked on, say a week ago, then the developer has to reload their understanding of this old code and context in order to answer any questions or fix any defects. This context-switching carries significant overheads [4].

The end result is that the effort required to complete a story increases due to the repeated context switching, therefore reducing velocity.

So, not only does filling the capacity with more work fail to increase throughput, it adds costly context-switching overheads – ultimately slowing everything down.

This phenomenon is not unique to teams using fixed-length time-boxes, such as sprints. Strictly following Kanban avoids this problem, but what I’ve seen is some teams creating a ‘ready for testing’ queue – so that developers can start work on the next story. This has the same latency effect and turns a process designed for continuous flow into a batch and queue process. But, I digress.

What to do with the spare capacity?

The simple answer is to look at the whole approach and determine what is slowing things down. In the example above, I’d be wondering what’s slowing the testing down. Many of the things that hinder testing can be addressed by changing how we do things ‘upstream’.

Are lots of defects being found, causing the testers to spend more time investigating and reproducing them? Can we get the testers involved earlier? Can any predictable tests be defined up front so that developers can make sure the code passes them before it even gets to the testers (e.g. Behaviour Driven Development)?

Are the testers manually regression testing every sprint? Could the developers help by automating more of that? Are the testers having to perform repetitive tasks to get to the part of the user-journey they’re actually testing? Can that be automated by the developers?

Is there anything else that is impacting them? Test data set-up and maintenance, product owner availability to answer questions? Anything else?

Addressing any of these issues is likely to speed up the testing process and increase throughput of the entire team as a result. One solution is to put these types of tasks onto the product backlog. This is fine but if we assign point values to them it can give a skewed view of velocity. Or rather, velocity is no longer a measure of throughput. You won’t be able to see if these types of tasks are actually improving things unless you are also measuring what proportion of the points are delivering new product capabilities.

The only good reason I can think of for story-pointing these throughput-enhancing tasks is if your focus is utilisation – i.e. maximising the number of story-points in progress. Personally, I care more about measuring and improving throughput. By doing so, we get the right utilisation for free and a faster, more capable team.

Up next: Valuing Effectiveness over Efficiency.


[1] “Lessons Learned in Close Quarters Battle” Illustrates how stepping outside our job descriptions can move the team through each story more quickly by using special-forces room-clearing as an analogy.

[2] Little’s law (PDF) – the section “Evolution of Little’s Law in Operations Management” that references Hopp and Spearman’s observation about throughput (TH), work-in-progress (WIP) and cycle-time (CT) – i.e. TH=CT/WIP. And therefore we can say CT = WIP/TH.

[3] Little’s law also illustrates that if we reduce the work in progress to one quarter, then the cycle time for each story reduces to one quarter of a sprint. We’ll still get through 10 points per sprint, but stories will be completed more as a continuous stream throughout the sprint rather than all at the end.

[4] “The Multi-Tasking Myth” by Jeff Atwood, talks about multi-tasking across projects and pulls together several resources to illustrate the impact of multitasking at various levels. This applies when multi-tasking across stories.


I’d like to say a special thank you to my fellow RiverGliders – Andy Palmer and James Martin – for the feedback that helped me refine this article.

Software Teams can Jump

For many years I’ve been coaching software teams in various things such as Example Driven Methods (xDD), including BDD and TDD; pair-programming; programming; testing; retrospectives; Scrum, kanban and various other ways of getting the most out of a development team. One thing that I notice is that while the teams are being coached, they do amazing things. They are more happy, more productive, fast to improve as if there are no limits to what they can achieve.
Michael Jordan, Blue Dunk, Lisle, IL, 1987
Then, at some point they decide that it’s time to go it alone. I always say to my clients to keep at least one day in their budget for me to go away and come back some time later. Usually within a month or two to see how things are going. Inevitably when I return, the team is doing reasonably well, but not as well as if I’d stayed involved, even if I was just popping in once every couple of weeks.

Some say that this is what the Scrum master is there for, however, I’ve noticed that this is something that the Scrum master doesn’t get to do much of as they are are often dealing with external pressures “to get things done”…

On many teams, once I move on, there is a coaching void. Despite my pleas and efforts to encourage them to at least establish a coach from someone in-house, the team is often left to just get on with it.

This isn’t a new idea. For example, Extreme Programming highlights “the coach” as a key role in the team.

In sports, teams have coaches. Have you ever heard of a professional sports team without a coach? Can you imagine a professional sports team hiring a coach for a while and then saying – “we think we’re ready to compete on our own now so thanks for your help but you’re not needed anymore”. No, I don’t think so. This is unheard of in competitive sports, yet all too common in competitive business.

Even my 12 year old son’s basketball team, the Islington Panthers, has a coach. He trains them 2-3 times per week and he (or an acting coach from the seniors) attends all of their games. In some training sessions he gets a member of the under 21s team to coach the under 13s training session – so there is always a coach even if they’re just borrowed from another of the club’s teams. Without him, do you think any of the club’s teams would make the national play-offs as they regularly do? Very unlikely.

So, competitive sports teams always have a coach. Temporary coaching in a professional sports team is almost unheard of… Sure, they could get by but would they be taken seriously? Would they be competitive? Would they save money by not having a coach or would this be an obvious false economy? What are their chances of generating sponsorship revenue if they are not winning games? What are their chances of winning games without a coach?

The same applies in software teams. For example, I worked with a client recently and helped a team of 6 people double their output in one day. They’d have to hire another 7-10 people in order to achieve that but instead, one good coach was enough.

So, if you have a professional software team without a coach, consider, are you really helping your business save money by going it alone? Or, like the professional sports team, is having a professional development team without a coach another example of a false economy.


From Scrum to Kanban – good and bad reasons to switch…

This originally appeared on my old blog in February 2009.

There are, IMHO, some good reasons and some bad reasons to consider switching from Scrum to Kanban… or for considering Kanban over Scrum as a starting point for ‘going Agile’ (so to speak)…

‘Good’ reasons for considering Kanban are…

  • Wanting/needing more visibility of specific development process constraints (bottlenecks) than Scrum gives you (Scrum shouts “there’s a problem!”, Kanban points at where the problem is)
  • Kanban can avoid waste of stories not filling a Scrum sprint (although finishing ‘early’ can allow teams to make improvements they might not otherwise have afforded themselves)
  • Kanban can focus teams on vertical stories from the outset whereas new Scrum teams seem to start with horizontal slicing.

‘Bad’ reasons to choose Kanban over Scrum are…

  • Wanting to say you are “Agile” without really changing your development process
  • Because using Scrum is exposing rigidity and brittleness of software that is the output of your development process and wanting to hide that behind Kanban words like cadence
  • Hiding impact of speculative design behind Kanban work-items when it fails in Scrum because the work never seems to fit into a Sprint, spilling the story over multiple sprints

(by speculative designs I mean implementing architecture that is more than is necessary for current valued-work-item)

For a team that has legacy development practices, producing legacy code for which it simply isn’t realistic to do incremental and iterative development but wants gradual and continuous improvement… I think Kanban is perhaps a better place to start. Your first ‘work-item’ may take 3 months… but it’s an honest 3 months! The trick is to make continuous improvements to gradually increase the tempo of your delivery.

If a team needs to suffer the pain – that comes from seeing that no matter how hard you try you simply can’t fit the implementation of even the smallest feature into one month – before it realises it has a problem… Then maybe Scrum is the better place to start.

Whichever you choose, I hope you choose the right approach for you, for the right reasons ;-)