To estimate, or not to estimate?

That is the question…

The practice of estimating how long it will take to implement work items in order to predict project schedules is being replaced, in some organizations, by a different practice: counting the number of work items completed in a given time period. This article addresses both approaches in an attempt to help you determine which is right for your situation.

Traditional Estimation

You are likely familiar with the traditional way that estimates are created:

  • Learn all you can about the requirements of the product.
  • Create a list of all the activities you can think of that need to be performed.
  • Assign a time (typically in hours) to each task indicating how long you think it will take to do.
  • Add up all those numbers.
  • Add some padding (perhaps 50 to 100%) to the total.
  • Resist your manager’s attempts to shave that number down.
  • Fight the impulse to quit your job when you see that your estimate has become part of the official project schedule.

Anyone who has employed this approach to estimation knows that it can often be time-consuming and unproductive. Fortunately, there are alternatives.

Relative Estimation

The Agile software development philosophy brought with it the theory that people are naturally better at estimating in relative terms (e.g. “which of those two buildings is taller?”) than they are at estimating in absolute terms (e.g. “how tall is that building?”).

Some Agile teams use Fibonacci numbers (1, 2, 3, 5, 8, 13…) for relative estimation of work items because the numbers grow at a reasonable rate and because they express the fact that estimates, being educated guesses, are not precise. The numbers typically represent abstract units called points.

At the end of each work period (e.g. iteration, sprint) team members sum the estimates associated with each completed work item to yield the team’s velocity, commonly expressed in terms of points per iteration. They then use this velocity figure to forecast future schedules.

Item Counting

Some teams don’t estimate at all, even in relative terms, preferring instead to simply count the number of work items completed in a given time period, and use that number to forecast future schedules.

As you might imagine, more accurate forecasts are to be had when the work items are small and close to the same size (meaning that they take about the same amount of time to implement).

This implies that some work must be done in order to break larger work items down into smaller work items, each of similar duration.

Estimation vs Item Counting

Both estimation and item counting can be used to forecast future completion dates. Each method has its own characteristics which can be considered when you are deciding whether or not to use it.

Consideration Estimation Item Counting
Overhead It takes time to go through work items and establish an estimate for each one. It takes time to go through work items and break larger items into smaller ones of similar size.
Scope Estimates can be made for all work items in a product, regardless of item size. This makes it possible to forecast project completion after just one iteration of work without breaking down all items into smaller ones. Large work items must be broken down into smaller items before they can be implemented and subsequently counted. Project completion can be forecast only after all items have been broken down.
Forecasting Schedule forecasting is accomplished by projecting the number of points that can be completed in the future, based on historical velocity. Schedule forecasting is accomplished by projecting the number of work items that can be completed in the future, based on historical work item count.
Availability A dependable forecast cannot be made until some work has been done. A dependable forecast cannot be made until some work has been done.

How much overhead is acceptable?

Both estimation and item counting have associated overhead that is incurred before scheduling forecasting can be performed. When estimating, the overhead is the time the estimation itself takes. When counting work items, the overhead is the time it takes to break larger work items into small ones, all of a similar size (duration).

How much overhead would you tolerate in order to be able to predict future completion dates to within an acceptable margin of error? Four hours per week? Two hours? One? Everyone’s situation is different, but I imagine most would agree that the less overhead incurred, the better.

Deciding which method to use

Like many other things in the Agile world, there’s a simple way to decide whether or not to use any particular practice: Try it! Yes, that’s right–as in most other Agile practices, the decision to use one of these methods or the other needs to be based on empirical evidence. In other words, you have to actually do some work in order to get answers.

More specifically, you can perform an experiment to see which method works best for you. It might go something like this:

Experiment setup

  • Chose a relatively small project, one that you think will produce a completed product in about six weeks. Assume 1-week iterations.
  • Create a set of work items (e.g. user stories) covering the entire product. A mix of large and small items is best for this experiment. (“Large” in this case means “too big to implement in one iteration.”)

Experimenting with relative estimation

  • Perform relative estimation on all work items. Record how long the estimation took.
  • You need to have from 5 to 10 small work items for the first iteration. If you don’t, break some larger items into small ones until you do. Record how long it took to create the smaller items.
  • Attempt to implement as many items as you can in the first iteration (week).
  • Count the number of points actually completed. That’s your velocity.
  • Forecast a project completion date based on that velocity.
  • If you don’t have from 5 to 10 work items for the second iteration, break some larger items into small ones until you do. Record how long it took to create the smaller items.
  • Attempt to implement as many items as you can in the second iteration.
  • Forecast a new project completion date based on a new velocity figure.

 Experimenting with item counting

  • Break all work items, large and small, into items all similar in size, and small enough so that each iteration will contain 5 to 10 items. Record how long it took to create the smaller work items.
  • Attempt to implement as many items as you can in the third iteration.
  • Count the number of items actually completed. That’s your item count.
  • Forecast a project completion date based on that item count.
  • Attempt to implement as many items as you can in the fourth iteration.
  • Forecast a new project completion date based on the new item count.

Evaluating the results

  • Compare the combined estimation and work item breakdown times in the first half of the experiment to the work item breakdown time in the second half of the experiment. Is one substantially less than the other?
  • Compare the number of points competed in the first iteration to the points completed in the second iteration. Are they reasonably close to each other?
  • Compare the number of work items competed in the third iteration to the items completed in the fourth iteration. Are they reasonably close to each other?
  • Compare the project completion dates from the first half of the experiment to the completion dates from the second half of the experiment. Does one pair seem more reasonable than the other?

The answers to the above questions may be enough to help you decide whether you want to use relative estimation, work item counting (or both) in your product development work. Some teams start with relative estimation, then move on to work item counting as they gain experience with making little work items out of big ones. I suggest you try them both to see which works best for you.

Read more about estimation in the 99-cent Kindle pocket guide, Practical Estimation.

Dude, where’s my user?

When crafting user stories, is it OK to name some non-human part of the system as your user? You may be creating requirements masquerading as user stories.

A common user story format

You are probably already familiar with this standard user story format:

As a <type of user>
I want <some capability>
So that <some benefit>

During the course of working with various development teams, I’ve run across stories like this more often than I would have imagined:

As the database, I want to have a Customer table, so that there is a place to store customer information.


As the system, I want to have an account object, so that account information can be seen.

The examples above certainly follow the standard format for user stories, but that doesn’t necessarily mean we’re getting all that we can from them. Either could be re-written as a simple requirement:

The database shall store customer information in a Customer table.
The system shall store account information in an Account object.

What we have here is a case of requirements masquerading as user stories. Note that both the faux and true user stories specify what is to be built. The difference is that the faux user stories leave out important information that true user stories convey, namely who the user is and why the story is being implemented.

These are important pieces of information, as they aid in determining that we’re building the right thing. In short, if a developer knows why something is to be built, and for whom, then he or she can make more intelligent decisions about precisely what is needed. And this can result in building something that is more useful and less expensive.

So if a simple requirement expresses the same thing as a so-called user story, why go to the trouble of bending the requirement into the shape of a story? Why do we see as many examples of faux user stories as we do?

My guess at the most common reason is that developers have been taught, or have led themselves to believe, that all features of a product must be expressed as user stories.

Another reason may stem from claims I’ve heard fairly often that are typically expressed as something like, “The work I do doesn’t have a user.”

Scrum says nothing about user stories

Scrum is the most commonly used framework for Agile development. And contrary to what many have been taught, Scrum says nothing about work items being expressed as user stories, but instead refers to them generically as Product Backlog items. Additionally, Scrum does not even require that all backlog items be of the same type or format, so a mix can be perfectly acceptable.

Now, to be clear, I’ve got nothing against user stories. I think they’re a very effective way to express the capabilities a system provides, and I use them almost exclusively when doing development work. My objection is to time-wasting efforts to express all work to be done in user story format.

Depending on your development environment and culture, you may be most comfortable populating your Product Backlog with a mix of true user stories and technical tasks.

My personal preference is to put only true user stories in the backlog, and to let any user story spark the creation of any necessary technical, under-the-hood stuff. But to do that, I have to engage in a mental exercise that I call:

Dude, where’s my user?

First, when I say “user” I mean some human-type person—not a data structure, a software component or other aspect of the system being built or a system that uses it.

User doesn’t necessarily mean a person interacting with some user interface. It means the person using your product, whatever it is that you produce. So if, for example, you produce web front-ends, your user probably is interacting with a user interface, and you should have little trouble identifying that user. If, however, you produce an API for a web service, your user is likely to be another developer, and you can write your user stories accordingly.

If you can’t easily identify one, you need to ask yourself, “Dude, where’s my user?” Because there probably is one out there somewhere. You may need to follow the path from your product through one or more other connected systems, until you find that person.

And If you can’t ultimately identify a user who benefits from what you are about to build, perhaps you should reconsider whether you’re building the right thing. Products are ultimately created for the benefit of human beings, so if you can’t find those people, either keep looking or stop building.

Scrum is not your process

To gain an understanding of what something is, it is often helpful to understand what it is not. This article outlines one of the important things that Scrum is not.


When training and coaching Agile practitioners, I often hear them use designations such as “the Scrum process” or “the Agile process” (by which they usually mean Scrum). Sometimes these are simply instances of using words casually, but in other cases it has turned out that what something is called substantially affects how it is thought about and used.

In my earlier training sessions, it seems that I met with quite a lot of resistance to the adoption of Scrum. After some digging I found that the primary source of such resistance was a general feeling that someone (typically management) intended to replace everyone’s existing work process with this new thing called Scrum, something of which they were (understandably) wary.

But once I made a regular practice of explaining that Scrum was not a replacement for their process, but instead a framework for inspecting and adapting that process, things tended to go more smoothly and the resistance pretty much went away.

You already have a process

You already have a process in place where you work. It may or may not be clearly defined. It may or may not be well understood. But, regardless of the work you do, you already have a process by which you turn some kind of input into some kind of output. Understanding your current process is important if you intend to make improvements to it.

Scrum is not your process

Let me repeat that: Scrum is not your process. That’s not to say, however, that Scrum is not a process. It certainly looks like a process in that it has well-defined steps which are performed in a specific order (i.e. Sprint Planning, Daily Scrums, Sprint Review, Sprint Retrospective). If you must think of Scrum as a process, then you might consider it a meta-process, in that it is a process which informs you about the state of another (your) process.

Your process may be something more like that shown here:Typical Process

As parts of a simple work process, these activities would need to be performed whether or not you use Scrum. Scrum can help you determine what things about that process might need to change (e.g. batch size, amount of work simultaneously in process, time between releases, etc.). Even so, Scrum isn’t intended to replace your process, but to augment it.

The founders of Scrum, as well as the current Scrum Guide, refer to it as a framework. I like that description, as it brings to mind some kind of skeletal structure or scaffolding that can be erected alongside your existing process in order to provide a vantage point from which to observe (inspect) the process and to change (adapt) it.

As frameworks go, I consider Scrum to be minimally intrusive. If you start practicing Scrum all at once, you will necessarily change some things related to your process (e.g. frequency of product releases, timing of meetings). In those cases, Scrum is not entirely hands-off as relates to your existing process.

I can easily imagine, however, a situation in which Scrum practices are brought online one at a time, in order to minimize disruption and make for a smoother transition. A team could, for example, start by adding Daily Scrums to their regular activities in order to begin inspecting and adapting work progress. Once that became routine, a team might add regular Sprint Retrospectives in order to begin inspecting and adapting the work process. And so on.

In conclusion

Organizations considering a transition to Scrum, and in particular those meeting with substantial resistance to such a change, may find that things go more smoothly if everyone involved understands that Scrum does not supplant any existing processes, but instead provides a point from which to view those processes in order to more easily improve them.


Estimating in the abstract

This excerpt from the Kindle pocket guide, Practical Estimation, discusses the relative merits of the most common units used in relative estimation.

Abstract Estimation Units

When estimating the traditional way, a discussion of estimation units doesn’t happen very often. If someone asks you how long it will take to complete a task, they’re thinking in terms of calendar time. The implication is that they expect you to answer in kind.

But it doesn’t mean that you have to estimate in calendar time. Relative estimation necessarily means that you’ll be working in abstract units. Some examples of this are:

  • Ideal Time - An ideal day is a work day free from interruptions and other overhead.
  • T-Shirt Sizes - Some teams use Small, Medium, Large and eXtra Large to indicate the time required to complete projects.
  • Points - Abstract units representing relative time to complete units of work.

When I first started practicing relative estimation, I was taught to think in terms of ideal time. If, for example, I believed that a task could be completed in 1 ideal day, and the team’s velocity was 2.5 ideal days per week (0.5 ideal days per day), then I could expect the task to take 2 days to complete. But I found this conversion between ideal days and real days confusing. The technique also had the unwanted side-effect of encouraging me to think in absolute time instead of relative time, so was really no better than estimating in real days.

The use of T-shirt sizes has a certain appeal, in that it provides a mechanism for quickly conveying high-level information from developers to managers. In my experience the drawback is that, being non-numeric, these units cannot be used to perform arithmetic, so cannot directly be used to predict schedule.

I prefer the use of abstract points for relative estimation. Point values can be used to express the relative time it will take to complete a unit of work, compared to other units of work. Early on I was encouraged to think of points as representing the “size” of a unit of work or the “effort” required to complete it. Those terms, although somewhat helpful, never seemed to describe what it was I was actually estimating, and I eventually came to think of estimating in points as estimating in terms of relative time.

You can read more on this subject in the article titled What Are We Estimating, Anyway?)

Read more about estimation in the 99-cent Kindle pocket guide, Practical Estimation.

The other theory of relativity

This excerpt from the Kindle pocket guide, Practical Estimation, discusses how we can leverage our ability to compare similar things to help create reliable project schedules.

The Most Accurate Estimates You’ll Ever Get

Here’s a formula for getting estimates that are 100% accurate:

  • First, do all the work
  • See how long it took to do the work
  • Make that your estimate

This simple formula works every time, but it’s not especially useful because it provides no predictability, only information after the fact. A valuable principle, however, is contained in that formula, and that principle is this:

Knowing how long it took to do some actual work can be useful in determining how long it will take to do similar work in the future.

Phrased this way, the principle just sounds like common sense, but there’s a wrinkle. How do we gauge similarity? And what if we haven’t done any “similar work” in the past?

If you’ve ever taken your car to the shop for repair, you’re probably familiar with this principle in actual practice. Repair shops have a guide in which they can look up standardized labor times, allowing them to quote labor costs for just about any repair or part replacement. Those labor times were likely arrived at by measuring and averaging how long each repair actually took some person or people to perform.

In the software development world, things are not so straightforward. I’ve yet to see or hear about any standardized lists of development times for tasks that developers perform. Why is that? Perhaps because software development is a process of discovery more than it is one of engineering—in software we’re always trying to discover (a) what to build and (b) how to build it. There are at least as many ways of developing a piece of software as there are people to develop it. I say “at least as many” because each software developer is capable of coming up with more than one way to develop any particular piece of software. It’s a field filled with choices.

So how do we apply the principle stated above to the world of software development? One approach is to see how long it takes to do only part of the work, and apply that information to work yet to be done. That makes the formula look something like this:

  • First, do some of the work
  • See how long it took to do the work
  • Use that information to inform future estimates

That sounds fine, as far as it goes, but it still doesn’t quite address the need to compare future work with past work. In the repair shop example, we have a guide that (theoretically) contains labor times for all conceivable repairs, based on someone actually having performed those repairs in the past. All we need to know is what repair we want to perform, and we can look up a standardized labor time in the guide.

But no such guide exists in software development. Each new software product has its own unique set of components and component relationships. From a certain perspective, all software is custom software, making it impractical to create a standardized guide.

Fortunately there still remains an aspect of software that we can use for making useful comparisons, and that aspect is relative development time.

What Makes Relative Estimation Work?

Relative estimation seems to yield better results owing to the theory that human beings are much better at it than they are at absolute estimation.

For example, I may not be able to tell you how tall two adjacent buildings are, but I can certainly tell you if one is taller than the other. I can even estimate, for example, that one building is a third taller than the other.

I may not know off the top of my head how long it will take to get to the grocery store, but I know it will be longer than it takes me to get to the gas station. I can even estimate that going to the store will take, say, twice as long as going to the gas station.

These are examples of relative estimates, which are expressions of one thing compared to another, similar thing.

The same principle can be employed when estimating software development tasks. For example, I might estimate that developing a feature to allow user registration for a web service will take fifty percent longer than a feature that allows the user to log in. I may not know how long (in absolute terms) each feature will take, but I feel pretty comfortable saying that one will take longer than the other, and by about how much.

All I need to do to get an idea of when both of those features will be completed is to develop one of them, see how long that took, then apply that information to the other feature.

It is fairly common to express the relative estimates for such features in abstract units or “points.”


At some point, which typically is before you answer your manager’s query about when a project will be completed, you’ll want to convert your abstract (point) estimates to calendar time.

This conversion takes place through the use of a conversion factor that has come to be called velocity.

Velocity says how many points of work were completed in a specific amount of calendar time, so will be expressed in something like points per week or points per sprint (for Scrum teams).

To arrive at actual velocity, you’ll have to do some actual work. Let’s say that you and your team complete 50 points worth of tasks in a week-long period. That would make your velocity equal to 50 points/week.

To predict a project completion date, divide the number of points remaining in the project by your velocity. If, for example, there are 450 points worth of tasks remaining in your project, it will take about 9 weeks (450/50) to complete the project.

You can read more about velocity in the article titled Velocity—it ain’t what it sounds like.

Read more about estimation in the 99-cent Kindle pocket guide, Practical Estimation.

Estimation values: near-Fibonacci vs. true Fibonacci

This excerpt from the Kindle pocket guide, Practical Estimation, discusses the relative merits of using the familiar “near Fibonacci” sequence vs. the true Fibonacci sequence for estimating work effort.

Fibonacci Numbers

Estimates are educated guesses. They are predictions based on past information, therefore we cannot expect them to have a lot of precision. If I spend time agonizing over deciding whether a task is either, say, 50% or 51% larger than another task, I am probably wasting time. Any individual estimate, being an educated guess, is not going to be correct with that kind of precision. Sometimes an individual estimate will be too large and other times too small. We can, given a number of samples, expect these anomalies to cancel each other out over time, yielding fairly reliable predictability of schedule.

We can limit the amount of precision that our estimates imply by using numbers from sets that are not contiguous. The Fibonacci sequence is an example of one of those sets.

A number in the Fibonacci sequence is created by summing the prior two numbers. Starting with zero, the sequence is:

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, …

The extra “1″ is unnecessary, so we can ignore it. Likewise, some may find that the “0″ is superfluous.

The Fibonacci sequence is handy for several reasons:

  • The formula to generate the sequence is easy to remember and perform.
  • The gaps between numbers grow as the numbers get larger, and can be thought of as representing the “uncertainty” of an estimate.
  • Throughout the sequence, the numbers grow at a rate that makes it possible to represent useful relationships such as (roughly) one-and-a-halftwicethree times larger, etc.

Near-Fibonacci vs. True Fibonacci

Some teams use what might be called a near-Fibonacci sequence, which looks like:

1, 2, 3, 5, 8, 13, 20, 40, 100

Notice that this sequence differs from the true Fibonacci sequence after 13. Early on, when I first started practicing relative estimation, I was encouraged to use this “near” sequence, and to think of the smaller numbers (1-13) as being the proper sizes for work items. Anything larger than a 13 was assumed to need decomposition into smaller items.

But tying a specific range of numbers to a specific block of calendar time can have the unfortunate side effect of causing team members to mentally (and unconsciously) map individual estimates to absolute time. When that happens, estimates become little more than alternate representations of calendar time, an unnecessary complication. We might just as well have estimated in hours (which we’re not especially good at).

I like to use the true Fibonacci sequence because it allows expression of relationships between work items of all durations. Using numbers from this larger sequence enables quick, up-front estimation of entire projects, even when its components have not necessarily been broken down into work-sized items.

I also favor the true Fibonacci sequence for its re-scalability. If, for example, I initially estimate a work item as a “1″, then eventually encounter other work items that are smaller, I can re-label any existing work items so that my “1″ becomes a “13″ and then I have all of the smaller numbers (1,  2, 3, 5, 8) to work within. In other words, I can make all of my estimates consistent relative to each other, regardless of size, because there is no upper bound to the sequence.

Another way to think about this is to consider the idea that the following two sequences are roughly equivalent to each other:

1, 2, 3, 5, 8

13, 21, 34, 55, 89

If you’re doing relative estimation, since all you’re really interested in are the ratios of the numbers (and not the absolute values of the numbers), then you should be able to use the above two sequences interchangeably. For example 2:1 is roughly equal to 21:13; likewise 3:2 is roughly equivalent to 34:21 (given a level of precision that is appropriate for estimates).

See other interesting things at the Agile Unlimited website. “To Agility and Beyond!”

Read more about estimation in the 99-cent Kindle pocket guide, Practical Estimation.

Are you really doing relative estimation?

This excerpt from the Kindle pocket guide, Practical Estimation, discusses how estimating with abstract units does not necessarily mean that you are doing relative estimation.  

Traditional Absolute Estimation

As a software developer, I may not really know how long in absolute terms (e.g. hours, days) a particular piece of software will take to develop. If you are a software developer, it is likely that you have experienced this first-hand.

Manager: “How long is this project going to take?”
Developer: “Three months.”

That exchange is an example of absolute estimation. One person has asked for an estimate in terms of calendar time, and another has responded in kind. Nothing wrong with that, on the surface—it is perfectly natural for the developer to answer a question the way it was asked. A difficulty arises, however, if the developer doesn’t yet have sufficient information to answer the question, but answers it anyway just because it was asked.

Early on in my own career, I did software development work on a fixed-price contract basis. That could be a tough game because if I didn’t bid a contract appropriately, I ended up making less (sometimes a lot less) money for the time spent. Working as a programmer making minimum wage wasn’t a career goal, so I had a very good reason to get good at estimating.

Here’s the basic technique I used:

  • Break down the work assigned into as many small tasks as I could think of
  • Estimate each of those tasks, in hours
  • Add up the task estimates
  • Pad the sum of estimates by 50 to 100% to account for unforeseen work
  • Present the estimate to my manager
  • Resist my manager’s attempt to negotiate the estimate downward
  • Do the work, which would take more time than either of us had imagined

I hoped that repeating the above process on each new contract would eventually help me get better at the estimation part, but it never really did, even though I was highly motivated. (Later on I overheard my manager telling someone that he usually took my estimates and doubled them in order to get an idea of schedule.)

I never really got good at this kind of direct, absolute estimation, and it wasn’t until many years later that I learned another way.

Relative Estimation vs Absolute Estimation

Manager: “How long is this project going to take?”
Developer: “The project has been estimated at 720 points, and we’re currently averaging 60 points per week, so 12 weeks.”

That conversation is an example of the ultimate use of relative estimation. Even though the manager has asked for an estimate in terms of calendar (absolute) time, the developer has responded, at least initially, in terms of some different, abstract units called “points,” then performed a quick calculation to convert those points to something the manager can use.

The assumption here is that the project in question consists of a number of individual development tasks, that each of them has been assigned its own estimate (in points), and that those have been added together to arrive at a single estimate for the entire project.

Relative estimation also necessarily implies indirect estimation, meaning that estimates are expressed in some abstract units, such as the points described above. This doesn’t work both ways, however. Using abstract units does not necessarily mean that you are doing relative estimation. It’s entirely possible (and fairly common) for development teams to engage in what might be called indirect, absolute estimation. This occurs when point values are merely substituted for their absolute equivalents.

I’ve worked on and with several development teams that believed themselves to be practicing relative estimation, but who were actually performing indirect, absolute estimation. The telltale sign in every case was that team members mentally mapped point values to calendar values while estimating. The typical thought process was something like, “Well, I think this task will take a full day to complete, and 1 point equals half a day, so this task is 2 points.”

So it’s possible to estimate in abstract units while actually engaging in absolute estimation. This is not especially useful, in that it adds an unnecessary level of indirection to the estimation process, which is no better than estimating directly in absolute units (e.g. hours, days).

Telltale Signs of Absolute Estimation

Relative estimation is always done using abstract units, so it’s easy to believe that, if you’re estimating in abstract units, you’re doing relative estimation. But units alone aren’t enough of an indicator—it’s entirely possible to estimate using abstract units (e.g. points) while still only doing absolute estimation.

Here are some ways to know if you’re just doing absolute estimation:

  • Relative estimation relies on comparison, therefore it requires at least two items (task, features, etc.) to work properly. If you find yourself assigning point values to individual items, without comparing them to other items, then you’re probably engaging in indirect, absolute estimation.
  • If, when you’re estimating, you find yourself thinking of point values as mapping to a specific amount of clock or calendar time (e.g. 1 point = 4 hours), you’re probably engaging in indirect, absolute estimation. At estimation time, estimates should be thought of as relative to each other, not mapped to clock or calendar time.
  • If you find it necessary to introduce new values (such as “½”) into the Fibonacci sequence in order to make some estimates fit, you’re probably engaging in indirect, absolute estimation. The ”½” that is sometimes used in estimation sessions to indicate a small effort is a clear sign of mapping points to clock or calendar time. In true relative estimation, you can simply re-scale your estimates to make room for a smaller estimate.

See other interesting things at the Agile Unlimited website. “To Agility and Beyond!”

Read more about estimation in the 99-cent Kindle pocket guide, Practical Estimation.

Velocity—it ain’t what it sounds like

In the physical world, velocity is a common and well-understood term. In the world of Agile software development, “velocity” means something that, at first glance, seems similar to the physical world meaning, but which is in fact different in an important way.

Velocity in the physical world

Anyone who drives a car is intuitively familiar with the meaning of velocity. It means speed, and is commonly expressed in miles or kilometers per hour. A slightly more abstract expression would be some distance per some unit of time. An even more generic way to say that is the ratio of benefit to time (benefit/time).

In the physical world, whether from the point of view of a commuter, a cabbie or a race-car driver, increased velocity means increased value—in more technical terms, that’s an increase in the benefit/cost ratio. In these cases, the benefit is miles traveled. Time taken is the cost.

To the commuter, traveling a fixed number of miles in less time provides increased value by lowering the time required to get to or from work.

To the cabbie, who effectively gets paid by the mile, covering more miles in a shift provides greater value.

To the race-car driver, winning the race has more value than coming in second.

Velocity in Agile software development

People engaged in Agile software development also use the term “velocity” and, probably because of the physical world meaning of the term, can be inclined to believe that increasing velocity means increasing value (or benefit/time), just like it does in the physical world.

Velocity in software development is typically expressed in terms of (story) points per iteration. At first glance this seems very velocity-like—something delivered in some period of time. But a closer look at what is being delivered reveals something interesting.

Story points don’t represent benefit

Many agile teams use relative estimation in one form or another to project how much time it will take to develop various functional bits (user stories) in a product. It’s common to assign a number of points to each story being estimated. In relative estimation, when we estimate a story at 3 points, for example, we’re saying that we believe it will take 3 times the amount of time to develop that story as a story estimated at 1 point.

So let’s say that we work in 1-week iterations, and at the end of a week we total up the estimated points for all the stories we completed that week and find that we completed 25 points worth of stories. We call that total our “velocity” and we use that velocity figure (25 points per week) both to project future completion dates and to determine how much work we think we can do next week.

But what we call “velocity” in software development isn’t like velocity in the physical world, in that points don’t represent a benefit—points represent time, which is a cost. At best, what we call “velocity” is actually only a ratio of relative time to absolute time. It’s a useful ratio, to be sure, but only so far as it lets us make calculations that convert our estimates to actual (calendar) time. Multiplying “velocity” by the number of weeks remaining until a deadline tells us how many points worth of stories we can expect to complete. Dividing the total number of story points in our backlog by “velocity” yields the number of weeks remaining until anticipated completion.

What we call “velocity” in software development doesn’t represent a benefit/time ratio like it does in the physical world. The largest implication of this is that increasing velocity does not necessarily translate to increasing value.

What’s in a name?

It’s important what we call things. The term “velocity” is certainly more convenient than something like “relative to absolute time factor” but it can mislead if not well understood.

Have you been in a situation where you’ve been encouraged to “increase your velocity”? It’s almost certain that the person doing the encouraging was really asking for you to go faster—to increase the benefits delivered in a certain amount of time.

In hindsight, it would probably have been better to use the term “velocity” to describe a benefit/cost ratio, like it does in the physical world. One of the easiest benefits to understand, at least in a for-profit company, is revenue. Revenue is a benefit, and time is a cost, so revenue/time is a reasonable way to express velocity. Or would be, if the term didn’t already have an accepted meaning.

We may have to live with the term “velocity” to describe what is actually only a “time factor.” After all, we’ve got roughly a decade’s worth of inertia supporting this now-traditional usage.

But we can at least be aware, and strive to make others aware, that increasing velocity isn’t something to aim for. Try increasing value instead.

Read more about estimation in the 99-cent Kindle pocket guide, Practical Estimation.

Estimating for the bottleneck

Your Agile team may employ an estimation technique that requires the participation of all team members. But this kind of all-hands involvement is completely unnecessary if you know where your bottleneck is.

Finding the bottleneck

If you can picture your development process as a chain of dependent operations that are performed in sequence (e.g. development, testing, deployment), then one of those operations will be your bottleneck. And just so we’re clear about what is meant by “bottleneck”, here’s a working definition:

A bottleneck is any resource with no spare capacity.

In other words, one of the operations in your development chain is going to set the pace—to determine the rate at which work items are completed. Find the operation whose throughput matches the throughput of the entire chain, and you’ve pegged your bottleneck.

All-hands estimation is unnecessary

Conventional estimation sessions, even within the Agile community, include input from all team members. It’s common to see teams arriving at an estimate for a given unit of work (e.g. user story, backlog item) by summing the anticipated efforts of each operation. (Development will take 3 days and testing will take 2 days, therefore the final estimate is 5 days.)

The problem with the above scenario is that it assumes that no work is done in parallel, which is rarely the case. In reality, development and testing will be occurring simultaneously most of the time, and the production rate of the bottleneck operation will determine the production rate of the entire chain.

When all operations in the chain are working in parallel, and assuming that there are many units of work to be done, then the time to complete a given unit of work is determined solely by the time it spends at the bottleneck operation. Therefore, in the above scenario, the time to complete the unit of work will be closer to 3 days than to 5.

This means that there’s really no need to involve the entire team to arrive at estimates. Getting estimates from team members involved in the bottleneck operation only will yield appropriate results.

What if we can’t find our bottleneck?

I often hear teams reporting that they have multiple bottlenecks, or that the bottleneck jumps from operation to operation, making it difficult to “estimate for the bottleneck.” If this appears to be the case in your development chain, then you’re most likely observing BINOs (Bottlenecks In Name Only). In any give chain of dependent operations, there will be one true bottleneck. There are several techniques for revealing where it is:

  • Observing Inventory Buildup – Find the operation that has the largest growing volume of work to be done.
  • Matching Cycle Times – Find the operation whose cycle time matches the cycle time of the entire chain.
  • Assignment – Where two or more operations have similar production rates, choose the one you wish to set the pace for the entire chain.


Although the example above talks about estimating in absolute time (days), I highly recommend estimating in relative time (points). We’re generally not very good at estimating in absolute terms, but can be quite adept at relative estimation (e.g. unit of work A will take about twice the time as unit of work B).

See my previous article, What are we estimating, anyway?

Read more about estimation in the 99-cent Kindle pocket guide, Practical Estimation.

That bottleneck may be right where you want it

Mere mention of the word “bottleneck” is often enough to generate a flurry of proposals on ways to eliminate it. But every system has a bottleneck, and yours may be right where you want it.

A useful definition

Examples of bottlenecks, both at work and out in the world, abound. Work piles up on the desk of a co-worker who is out sick. Traffic comes to a standstill on the freeway while driving to and from work. (The most common one in my commute is a particular spot on Highway 101 north of Novato where three lanes turn into two.)

But some things that we think of as bottlenecks, aren’t. In a work environment, it’s common for people to label anyone or anything that is preventing them from starting their own next work task as a bottleneck.

A more useful definition of bottleneck comes from The Goal by Eliyahu M. Goldratt:

“A bottleneck is any resource whose capacity is equal to or less than the demand placed on it.”

That’s a powerful statement. And it’s the “equal to” part that I find the most interesting. If you turn the definition on its head, you can express it as:

A bottleneck is any resource with no spare capacity.

The bottleneck is a pacesetter

It’s convenient to think of a software development environment as a chain of dependent operations (e.g. requirements gathering, design, development, testing, deployment).

The bottleneck in your software development environment is the operation with no spare capacity with respect to the demand on your chain of development operations as a whole. If you measure the rate at which finished product is leaving the end of the chain, you can identify the bottleneck by finding the operation whose production rate matches the system’s rate.

In other words, the bottleneck operation sets the pace of production for the entire system. And that’s why I find it useful to refer to a true bottleneck as a pacesetter.

Deciding whether or not to eliminate a bottleneck

Your system is going to have a bottleneck somewhere, and fixing a bottleneck at one operation will have the effect of moving it to some other operation. You only want to move a bottleneck if you don’t like it where it is.

So how do you know if your bottleneck is in the right place? Just take a look at the rate of production of your development environment as a whole. If delivery of finished product (e.g. features, user stories, or whatever units of work you use) is keeping up with demand, you’ll likely want to leave the bottleneck where it is.

And how do you assess demand? In a software development environment, demand might be determined by your marketing organization (i.e. “We need to have features A, B and C delivered by the end of March”).

A bottleneck side-effect

A development environment that is keeping up with demand, and that has a well-managed bottleneck, will also exhibit what is often perceived as an undesirable trait: Not every operation in the development chain will be occupied 100% of the time. In other words, some people are going to appear as if they’re not working at least part of the time.

But this is intentional. If the bottleneck is the pacesetter for the entire system, then all of the non-bottlenecks will, by definition, have spare capacity which can be used, when appropriate, to make sure that the pacesetter operation is never starved for work.