An alternative to ‘Cost of Delay’

Cost of Delay has become a popular component of a variety of calculations intended to yield information that aids in making decisions about the optimal development order of multiple items (e.g. product features), based on economic data. However, there are several different ways to apply CoD, and sifting through them can get complicated in a hurry. This article discusses a simpler method for prioritizing product features based on relative value.

What’s in a name?

Opportunity cost means “the cost of a lost opportunity.” Investopedia defines opportunity cost as: “The cost of an alternative that must be forgone in order to pursue a certain action. Put another way, the benefits you could have received by taking an alternative action.”

Cost of Delay (CoD) is a specific type of opportunity cost. If that cost is a result of delaying an action in time (e.g. moving a project’s start time back by a couple of weeks), that’s CoD.

It is important to remember that, despite the name, CoD is often not actually a cost at all—it’s more accurately described as potential revenue. It can seem like a cost, perhaps because it’s fairly easy for us human types to think of money we could have earned as money lost, but it’s really unrealized revenue. (An exception to this: If a service you use is currently costing you money, and you decide to get rid of it to save money, but you don’t do that right away, that’s a Cost of Delay.)

I’m reminded of an exchange from the Marx Brothers movie, Animal Crackers, between Captain Spaulding (Groucho) and Ravelli (Chico) in which Mrs. Rittenhouse has hired Ravelli’s orchestra to play at her Long Island party:

Mrs. Rittenhouse: You are one of the musicians? But you were not due until tomorrow.

Ravelli: Couldn’t come tomorrow, that’s too quick.

Spaulding: Say, you’re lucky they didn’t come yesterday!

Ravelli: We were busy yesterday, but we charge just the same.

Spaulding: This is better than exploring! What do you fellows get an hour?

Ravelli: Oh, for playing we getta ten dollars an hour.

Spaulding: I see…What do you get for not playing?

Ravelli: Twelve dollars an hour.

Spaulding: Well, clip me off a piece of that.

Ravelli: Now, for rehearsing we make special rate. Thatsa fifteen dollars an hour.

Spaulding: That’s for rehearsing?

Ravelli: Thatsa for rehearsing.

Spaulding: And what do you get for not rehearsing?

Ravelli: You couldn’t afford it.

My point is that calling CoD a “cost” can be misleading in that, just as in the Marx Brothers’ universe, you might run up a pretty large bill by having no work done. Avoiding costs is a big part of any business, but simply calling something a cost doesn’t make it so.

If, for example, your organization releases individual features when each is ready, and each feature starts generating revenue fairly soon after release, then you can use a method incorporating CoD to assess the lowest-cost order in which to release those features. In this case, treating potential revenue as a cost makes sense.

If, on the other hand, your organization releases collections of features on a regular calendar schedule, and you want to ensure that the most valuable features are developed first (assuming that all features may not be completed by the deadline), then you can use an alternative prioritization method based on the relative values of features. Assigning costs of delay to individual features is less appropriate, and perhaps a little confusing, because changing the development order of any of the features that are developed in time for the release has no effect on the overall cost. Revenue begins accruing only after the entire collection of features gets released, so Cost of Delay has little meaning in this case.

An alternative prioritization method

All we really need to do for the second case above is to determine the relative values of all the features we wish to include in a release, and develop them in highest-value-first order. It doesn’t matter what the actual values are—we just need to know how the features rank compared to each other.

There are 2 components involved in calculating value, and these are benefit and cost. There are some very simple ways to estimate both benefit and cost. Indeed, it’s easier to estimate relative benefit and relative cost than it is to estimate either of those in absolute terms.

Revenue is one example of benefit, but you might not be able to predict how much money, in absolute dollars, a particular feature will bring in. It’s easier to estimate in relative terms (e.g. “I think feature A will bring in about 3 times as much money as feature B”). We can estimate the relative benefits of each of a collection of features pretty quickly. Using a team-oriented exercise to do so lets us get consensus on what is more beneficial and what is less so.

Cost is proportional to the time spent developing a feature, and in a way that is probably counter-intuitive to many people. As it turns out, the cost to develop a feature is directly proportional to the amount of time that feature is worked on by the pacesetting operation. (The pacesetting operation is also known as the process bottleneck.) We can estimate the costs of features in relative terms (e.g. “I think that feature B will take about twice as long to develop as feature A”). Here again, we can get consensus on the relative costs using a simple exercise that leverages the knowledge of the team.

Dividing relative benefit by relative cost yields a ratio that can be thought of as a value index. The value index serves as a basis for quickly assessing relative feature values. The greater the index, the higher the value.

Summary

  • Cost of Delay is often not a cost at all.
  • Calling something a “cost”, when it isn’t, can be misleading.
  • Releasing revenue-generating features one after the other is a good case for using Cost of Delay to determine development order.
  • When releasing a collection of features, prioritizing by relative values is a good method for determining development order, especially if all of the features might not get completed by the deadline.

 

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.

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.”

Velocity

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.

Note

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.

What are we estimating, anyway?

Several schools of thought exist regarding the proper units to use when estimating work effort, especially on Agile teams. This article addresses what just may be “the simplest units that could possibly work” when estimating in order to provide predictability of development schedule.

When I first encountered what was called “Agile estimating” in 2004 or so, it was common to hear people talk about estimating user stories in terms of “size.” The emphasis was not on how long a user story would take, but rather on how big a story was. This seemed like a reasonable viewpoint, as it tended to de-emphasize duration, something that experience told me I’m not very good at assessing. (I tended to be overly optimistic.)

But as I attempted to put this emphasis on size into practice, I discovered that it was difficult to explain what “size” meant. I thought I had a grasp of it myself, but was generally unable to articulate what I meant by “size” to others on my team, and with whom I needed to engage in estimation activities. Often the best I could do was to define size in terms of what is was not (e.g. “it’s not duration” or “it’s not time, it’s size“).

Not satisfied with the inability to communicate clearly about this, I began thinking of and explaining “size” in terms of relative complexity. This was somewhat more satisfying, as the concept was easier to communicate, and my teammates and I seemed to be able to talk about this and use it. We decided that “less complexity” could be equated to “having fewer parts” and that “more complexity” meant “having more parts.”

This was fine as far as it went, but there were still some issues. It sometimes turned out that stories of supposedly equal complexity took substantially different amounts of time to complete, making the predicting of schedules less reliable. Order of story development played a part here. When two equally complex stories shared some underlying infrastructure, the first story to be developed would take longer than the second.

Some time later, I learned of other teams estimating in terms of what they called “effort.” This had a certain appeal, but seemed to raise old issues. Coming to agreement on what was meant by “effort” felt about the same as agreeing about the meaning of “size.” Effort is a slippery term, as it can refer to not only how long something will take, but also the ease with which that thing is accomplished. In other words, a user story that is easy (i.e. enjoyable) to work on may seem almost effortless, yet take more time to complete than a story that is difficult (i.e boring).

It could very well be that the appeal in using any of the above units, (size, complexity or effort) lies in our desire to avoid talking about estimates in terms of time. Perhaps we’ve convinced ourselves that we shouldn’t be talking about time, but about something (anything) else when estimating work effort.

But we should also remember why we’re estimating in the first place. If we’re estimating to provide predictability of schedule, then time is what we’re interested in. I’ll go so far as to state that while we’re not generally very good at estimating in terms absolute time, we’re much more adept at estimating in terms of relative time. (e.g. “I don’t know how long stories A and B will take to develop, but I do know that story A will take about twice as long as story B.”)

Given a choice of all the units described above, relative time may be “the simplest units that could possibly work.” They’re certainly more closely related to what we really want to know (absolute time), and they avoid the ambiguities that seem to be inherent in the other units.

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