Applied capacity planning

Tomas Rybing

This paper will give you answers to the following questions:

- What is #NoEstimates?
- What is capacity?
- How to measure?
- How to use stored data?

Applied capacity planning © Tomas Rybing 2015 1 of 11

"#NoEstimates is a hashtag for the topic of exploring alternatives to estimates for making
decisions in software development. That is, ways to make decisions with 'No Estimates’".
- Woody Zuill (Leading #NoEstimates advocate)

Introduction
The term #NoEstimates is something that I see and hear more and more
about in the Agile world. I was curious if it’s one of those buzzwords that will
fade away, or if it was a real movement behind. Luckily I had the opportunity to
become a beta reader of #NoEstimates, the book written by Vasco Duarte that
has been published recently.

Estimates have always been around in my career within consulting and

software development. I have made estimates myself, and I have also asked
other people to do it, then I have included them in all sorts of plans. In the
beginning of my career I was absolutely crappy at making estimates. I once
estimated a project that in the end took ten times longer than first expected.
Later on I gathered some knowledge and became better at it, but I have never
liked to do estimates, and I think I share that with most of the people within the
software development industry.There is a feeling of unease, that you can’t predict the future and
that you will be held accountable when more time is spent than was originally estimated.

#NoEstimates opened up my eyes in the search for something new, something better. In this paper
I will share my experiences on that journey with you. A little bit more about my background may be
in order. The company I’m working for makes products and services for management of mobile
data services for Wi-Fi and LTE. Currently we have an R&D department co-located in one office,
with two development teams using Kanban (Scrum was previously used). If your context is very
different, the experiences described here may not be applicable to your situation.

#NoEstimates - What is it all about?

In software development we know that there are problems with estimates and that we shouldn’t
plan and make our whole business rely on them. I would say that this fact is common knowledge,
but no one seems to be doing so much about it. Not before the #NoEstimates movement started by
Woody Zuill, Neil Killick, Vasco Duarte and others. After all, estimates are just guesses, sometimes
they are educated (some type of work is behind the numbers) but nevertheless they are still
guesses.

The #NoEstimates book tells you how to measure progress in a project, to be able to make
forecasts (are we still on track to deliver before the deadline?) and take on an active management
of the scope. You may think that the scope is also fixed. After all, it has probably been agreed to in
a requirement specification. You can still work with the features and slice them to only deliver the
functionality that are of true value to the customer.

How you incorporate #NoEstimates is individual (and context dependent), in a ”Methods & Tools”-
article [1] Henri Karhatsu said ”the heart of #NoEstimates is continuous improvement”. My main
takeaways after getting more knowledge are the following:
• Forecasting and planning based on actual data
• Active scope management.
In this paper I will focus on forecasting and planning, and not so much on active scope
management.

Applied capacity planning © Tomas Rybing 2015 2 of 11

 ”Statistical forecasting beats estimation every time. With a flow-based visualization we can
measure cycle time, throughput, and lead time to provide much more reliable responses.” [2]
- Jim Benson (Author of ”Personal Kanban” and other related books)

Gather forecasting data

My journey took off after I read a very interesting blog post called ”How far have we come?” [3] by
Marcus Hammarberg, and my manager had approached me with the following task: ”Can you
make a status report where we are in the project?” Using this as a starting point together with the
new knowledge I had gathered, I took a new approach to this task than what I would have
previously taken.

Measuring

I had asked the teams to measure how many stickies they complete each week. We got this idea
from the book ”Kanban in Action” [4]. The reason we started to measure stickies delivered was to
see if our kaizen efforts (continuous improvements) were positive or negative.

Every Friday the team leader counts all the stickies in the ”Done” column on the Kanban board,
write the figure on the board, and then remove them. This is repeated every Friday. Each sticky
correspond in our kanban to a bug-fix or a sub-task of a story/feature. Hence, the measuring is
done on the lowest level of work that we track, and not on the story, or feature-level as is
suggested in the #NoEstimates book.

By plotting the numbers stored for each week the picture above was created. In the spreadsheet
program it was also possible to calculate an average, in this case 18 tasks/week.

You can argue that some of those tasks were only a few hours of work, while others may have
been much longer (days or even weeks). That is true of course, but by measuring over a longer

Applied capacity planning © Tomas Rybing 2015 3 of 11

period of time, these things ”even out”, i.e., some tasks will take a long time to complete, but others
will be completed very quickly.

One other argument is that work in progress is not considered or valued by doing this type of
measurement. Ongoing tasks are not considered. For example a task that was originally estimated
to five days, and now only have one day left on it, i.e., should be 80% done. My answer to that is,
how do you know that it’s 20% left? That is just an estimate. You don’t know that it’s done, before
it’s done! ☺

The last argument I will add for now is that you can’t make predictions on the future based on data
with this much variation. Correct, you need to use precaution when making calculations, I will come
to that later.

Remember that the effort for performing this type of measurement is less than five minutes per
week! If you want to set up something more advanced (and thereby time consuming), by all
means, please go ahead and do it!

”I agree that understanding capacity is key to being an #agile organization, and it's nothing to do
with estimating.”
- Neil Killick (Pioneer of #NoEstimates, tweet comment on ”Speedometer” [5])

Use actuals data to forecast

Back in school I learnt about the magic triangle of Speed’s law, as I assume it’s called in English. In
Swedish it’s called ”SVT-triangeln”.

d = distance
v = velocity (speed)
t = time

Basically it says that if you have two variables, you can d

calculate the third. Like:

d = v * t
v = d / t
t = d / v
v * t

An example: I want to travel by car to another city that is 100 km away, and I’m holding an
average speed of 50 km/hour. How long will the trip take?

t = 100 / 50 = 2 hours

This is simple mathematics that all of us understand, what does this have to do with project
management?

The Iron Triangle

Applied capacity planning © Tomas Rybing 2015 4 of 11

According to The Project Management Institute, a project basically depends on three variables.

They are: Scope

• Time - When the project should be delivered (functionality)
• Cost - How many people are working with 

the project
• Scope - The content (features and functions etc.) 

of the project

Quality

Cost Time
(people) © Project Management Institute, (deadline)
www.pmi.org
These three variables can be depicted in something that is called The Iron triangle. A common IT
project of today may look like this: ”In nine months we would like to have project X delivered to the
cost of one million USD”. As a supplier of that project you have to make two hard commitments, in
time (delivery date) and cost. The only thing left that can vary is the third variable, namely scope
(that you can control and manage). By doing so your project is ”value driven” instead of being
”scope driven” (where you can control time, i.e., delay the project or add more people to it, which
seldom works, and thereby adding cost).

Basically it works like this. You can have two variables fixed, but the third needs to be flexible. If
you do a fixed price & fixed scope project, the time plan must be variable. If all three are fixed and
your project runs into trouble, the quality is hurt (and you will be out of business in the long run).

As written earlier I have done estimates, for example saying that something is 20 days of work.
Thus I have been guessing on the scope. Then I have made something even more questionable, I
have committed to delivery times using those estimates. ”Are you out of your mind?” you might
say. ”How can you promise to deliver something in four weeks knowing that it will take 20 days to
do?” Hold your horses a bit, I have been using ”the factor”. What is ”the factor”? The factor is
”some magic thing” that comes from the stomach area of software developers ☺. A more correct
name is gut feeling.

To be serious, ”the factor” is something

you use to multiply your estimate with
Estimated Actual
to get the delivery time. You can make
an estimate of the way from A to B B B
(shown on the left picture). But
our experience says that the actual
road will be more like the picture on the
right. We know that we will face obstacles
in our way, but we don’t know how many
or how severe they will be. Imagine there will
A A
is a mountain in our way (to visualize
an obstacle in our software
development).

Applied capacity planning © Tomas Rybing 2015 5 of 11

Then we have two alternatives:
• ”Go over the mountain” - That will significantly reduce our velocity (and it will take longer to
reach our goal)
• ”Go round the mountain” - That will increase our distance to travel (and it will take longer to
reach our goal)

So we need ”the factor” to calculate the actual distance we think we need to go. You can call it a
”risk margin”, ”our collective knowledge of estimation boiled down to a number”, or the many
peoples favorite, π. Examples of values: 30%, 2x or 3.14159…

Combine the triangles to enable forecasting

But what if we could know ”the factor”? Then we could combine the two triangles together to
enable forecasting. Scope
s = scope (functionality)
c = capacity (”speed”)
t = time

Then we can use the same thing, if you have two variables
given you can calculate the third. Like:
s
s = c * t
c = s / t
t = s / c

c * t
Capacity
Cost Time
(people) (deadline)

The key thing to all this is, of course, for you to know your capacity. Without it you can’t use
the formulas above. You can of course ”cheat” and replace capacity with ”the factor”, but that is
really only the second best option. You have to measure the capacity, like the speedometer of
your car!

If you are not measuring capacity of your teams and you perform estimates on scope to give
delivery times, you have to use ”the factor”. Wouldn’t it be better to use capacity, something that
you can actually know (by measuring), and even better, do something about (increase it by
continuous improvements to your process).

Better decisions possible thanks to forecasting

Back to the project I talked about earlier. Someone did a time plan stating that the project needed 6
weeks for bug fixing (I have to admit, it was me, back in my ”old life” ☺).

Looking inside our bug tracking system, I found that 213 bugs were assigned to the project.

Now it was time fire up my favorite calculator:

Applied capacity planning © Tomas Rybing 2015 6 of 11

1. Actual time to solve all bugs

t = s / c = 213 / 18 = 12 weeks (double the planned time)
2. Number of possible bugs to solve within the given time plan

s = c * t = 18 * 6 = 108 (roughly half the scope)

Scope

213 = planned / guesstimated

= realistic (half the scope or
double the time)

50%

Time
6 weeks 12 weeks
Without judging the data to be the absolute truth (i.e., using it with precaution), we consulted The
Iron Triangle to come up with the following conclusions:
• Cost - Investigate the possibility to borrow some members from another team to help out with
this project
• Time - Investigate the possibility to delay the project delivery with the steering group
• Scope - Initiate activities to manage the scope. Must this bug be solved in this project, or can it
wait? Is it old and can be removed? Is this bug already fixed, but our tracking system has not
been updated? Etc.

Your conclusions may be different when you try this out. In the next section I will describe how we
use this in planning and prioritization.

”Estimates or #NoEstimates… It’s all a matter of context.” [6]

- Mike Cottmeyer (Agile thinker and writer)

Better planning
How do we use all this in our planning? For us it starts with the backlog. Often product backlogs
are kept in spreadsheets or internal systems. They are ”hidden” for the masses, to be shown and
worked on by only a few people. Our backlog is visualized on a white board inside our ”Nerve
center”-room, where we have all the Kanban boards and the teams perform their daily standup
meetings.

Applied capacity planning © Tomas Rybing 2015 7 of 11

Priority pyramid

To visualize our backlog we use a priority pyramid [7]. What is the extra value that the pyramid
bring besides visualization? It gives hard boundaries that highlight the priority. Given the size of our
pyramid and the stickies that we are using, there is a physical limit how many that can fit inside!

The priority pyramid is divided into the following sections:

• Priority one (P1) - At the top of the pyramid, with the 
 DONE
highest priority. This is for ongoing tasks. P1 (1)
• Priority two (P2) - In the middle of the pyramid. This 

is for tasks that will be started as soon as people 

become available.
P2 (2)
• Priority three (P3) - At the bottom of the pyramid.

This is for tasks that will be worked upon later.
• Backlog - Below the pyramid the rest of the backlog 

is present. At this stage the tasks can be written 
 P3 (4)
directly on the whiteboard, or be lines on a printed list.

Also seen in the picture above are the WIP-limits (Work-in-Process limits). Basically it is a limitation
for how many tasks that can be present in each section of the pyramid at any given time. Looking
at the example above, it’s the figures within parentheses (i.e., 1, 2 & 4). Use an increasing
sequence n x 2 for each underlying section in the pyramid. Starting with 5 at the top will give WIP-
limits of 5, 10, 20, etc. I think you get the hang of it.

Tasks flow from the bottom of the priority pyramid upwards, as the arrow to the left in the picture
indicates. When a task is completed it is moved to a ”Done”-area outside of the pyramid.

How we operate the priority pyramid

Going back to the picture with the priority pyramid, let’s assume that the yellow sticky in P1 is
completed and moved to done. Now we need to make a business decision. Shall the green or
yellow sticky in P2 be started (and moved to P1)? Since we haven't made any premature decisions
about priority, but instead waited until the very moment it’s needed, we usually have all the
information at hand to make the best decision possible. Let’s say that the green sticky represents
the most important task right now and this is moved to P1. This is the only business commitment
we make.

Now we make two more decisions, which do not represent a commitment, and therefore can be
changed later. We move a P3 task to P2, let’s say the red sticky. And we write a new sticky for an
upcoming task from the backlog list. Next time a task in P1 is completed we repeat this procedure.
This might feel cumbersome, and it’s true that you don’t want to have too small tasks (in terms of
work effort needed). Features / User stories represents a reasonable size of work effort. To make
the prioritization simpler it’s also good if the items are of approximately same size (to allow flow
and predictability).

Applied capacity planning © Tomas Rybing 2015 8 of 11

Planning meetings to cover different cadences in software development

We perform planning meetings with four different cadences. Roughly they correspond to the
following.

”Per release cycle” (we do it quarterly)

All the stakeholders meet and agree on the targets and major scope of the
release. It’s very important that the targets are meaningful and understandable
by all. The targets shall be helpful in the daily work. ”Shall I do A or B?”, the
targets must guide the decision. Here is an example of a target: ”The system
shall have zero downtime”.

”Per iteration” (weekly)

Key stakeholders meet and discuss status, make needed decisions (about time and cost in the
The Iron Triangle) but most important continuously discuss the scope. Dividing the work into
smaller pieces and deliver the things with highest value first to the customer. The agenda for those
meetings usually look like this:
• Status - Where are we according to time plan?
• Review of priority pyramid - What has been completed? What is
ongoing? What needs to be started next? Are all priorities correct, shall
we move tasks ”up” or ”down” in the pyramid?
• Adjustments - Changes needed in time plan, team or scope?
• Other - Anything else urgent that affects the delivery?

Constant evaluation of the project using The Iron Triangle is needed to be able to handle the
uncertainties that come along the road. See it as the GPS of your car that re-plans the route if you
have to make a turn that takes you off the original route.

”Dispatch” (daily)

Immediately after the daily standup meetings we perform a dispatch meeting. Many of our tasks
need to pass through this meeting. Definitely all bugs found are discussed here, but also some
sub-tasks for stories/features. Excluded are obvious ones, like sub-tasks for a decided and
ongoing story/feature. In this meeting we discuss each item and then decide on two things:
• Target release - Can be current, next or future. There is also a possibility that we decide not to
fix it all, or if really critical we make a patch.
• Importance - Promised, needed or desired. Promised means things committed to one or more
customers, needed is things deemed important to include, and desired are mainly represented by
internal improvements / maintenance / clean-ups.

Some examples of discussions on this meeting: ”Story X has a potential sub-task Y. Y is not
requested by any customer right now, but it would be beneficial in the future. Shall this desired task
be added to the current release, or wait to the next?” or ”Bug Z is found, must this needed task be
included in current release?”.

Applied capacity planning © Tomas Rybing 2015 9 of 11

”On demand” (when needed)

The team plans story / feature and bring it to the

team Kanban board. Other key stakeholders may
be present on the planning meeting to explain in
detail what needs to be done.

”Estimation is Agile’s trojan horse.” [8]

- David J. Anderson (Father of Kanban and author to numerous books on Kanban)

Summary
Finally back to the project, what happened? With the help of measuring capacity and the
calculations made by using the measured capacity, we did the following:
• Cost - We did not change the team working with the project. Instead we moved some stories
from the project to the other team, thereby adding more people
• Time - We delayed the project
• Scope - We started to very actively manage the scope of the project. We emphasized questions
like: ”Is this feature promised to any customer?” and ”Is this bug fix needed for this release or can
it wait to the next?”. Then we worked ”from the top” (promised & needed) with the possibility to
”drop from the bottom” (desired) if, and when, it was needed.

And the most peculiar thing of all? No questions were asked! There is more power in using
measured data than gut feeling!

Applied capacity planning © Tomas Rybing 2015 10 of 11

References
[1] Methods & Tools, Spring 2015 (Volume 23 - number 1), article ”#NoEstimates -
Alternative to Estimate-Driven Software Development” by Henri Karhatsu
[2] http://moduscooperandi.com/blog/modus-list-4-9-questions-you-cant-answer-when-not-
visualizing-your-work/
[3] http://www.marcusoft.net/2015/01/how-far-have-we-come.html
[4] ”Kanban in Action”, Marcus Hammarberg & Joakim Sundén, ISBN 978-1-617291-05-0
[5] http://theagileist.wordpress.com/2015/03/09/speedometer/
[6] http://www.leadingagile.com/2015/03/estimates-or-noestimates-its-all-a-matter-of-
context/
[7] http://theagileist.wordpress.com/2014/12/08/priority-pyramid/
[8] http://www.djaa.com/noestimates-beef-and-agiles-trojan-horse

More information
Email: theagileist@gmail.com
Twitter: @theagileist
Blog: http://theagileist.wordpress.com

Applied capacity planning © Tomas Rybing 2015 11 of 11