Let’s consider that perspective for a moment. How many significant things in your personal life would do without at least some planning first? I doubt you would plan a wedding, a relocation to another city, a holiday trip, or any such event without first engaging in some amount of planning.

Suppose you are considering a first-ever trip to Italy. You would plan that–which cities? how long in each city? what’s your budget? and so on would be some of the questions you would consider. Now suppose you are planning your one hundredth return visit to the city in which you grew up. You will even plan this trip–even if the extent of that planning is to decide you don’t need to plan at all.

Planning is the act of thinking about the future. Sometimes that future holds risk and uncertainty. In those cases we plan more than when the future is highly predictable as a hundredth visit to your childhood home town would be. When a future activity is highly predictable, planning may consist of nothing more than a few milliseconds of rejecting the need to plan further.

Of course on a software project it is rarely this simple.

What about estimating? Do we really need to estimate? Yes, because estimating is a pre-requisite to planning. You cannot plan without estimates in mind. Those estimates may be very informal and very implicit. As I write this I am on a flight to California. Before boarding the plane I got cash from an ATM. I estimated my upcoming need for cash to do that. $200 should do it. That estimate took less than a second and I was perhaps not even conscious of it, but it was made.

When a product owner says, “I’d prefer to add this feature rather than that feature,” the product owner is acting with at least some implicit estimate (perhaps guess) of how long each will take. When a programmer chooses late in the day to fix a bug rather than start a new user story before going home, that programmer has made an implicit estimate that fixing the bug fits better with the hours left in the day.

Teams that say, “We won’t estimate. We’ll just make every user story the same size,” are estimating. They are estimating that this user story is the same effort as all other user stories. I’d even argue that it’s harder to make each story the same size than it is to use a small range of effort sizes on various stories.

These estimates must be made. Yes, they can be subconscious but they are made. Those who blog and post to newsgroups saying “estimating is waste, don’t do it” are ignoring these types of estimates.

But are these casual, perhaps subconscious, estimates OK? Wouldn’t teams be better with formal estimates?

Perhaps but not in all cases. A team should estimate and plan only to the extent that further investment in estimating and planning will lead to different actions. If you will do the same thing even if you estimate or plan more, stop. But if further planning is likely to lead to better decisions (more confidence in a delivery date, better prioritization of functionality, or so on), then estimate and plan further.

As an example, we recently added quite a bit of functionality to this website to support our new eLearning course on Agile Estimating and Planning. I did not ask the programmer who did that work to give me more than cursory estimates. I’m still enough of a programmer to have an idea how long the new features would take. I’ve worked with him long enough to know how fast he is. Asking him for detailed estimates would not have changed anything about that project.

So estimating and planning are necessary. They can (and should be) lightweight. You should stop when further planning is not likely to lead to improved decisions worth the extra effort.

The entire course is now available on the Mountain Goat Software site. Check out the free previews. The course can be purchased for streaming or for streaming + download. We also offer group discounts and an innovative, easy way for someone such as a manager, ScrumMaster or similar to buy and distribute licenses to team members.

The 44 videos are interspersed with 9 interactive quizzes. If you miss a quiz question, you get immediate feedback telling you what the right answer is. This approach may not hold up to some certification organization’s rigor, but it’s sure a helpful way to make sure you’ve learned the topic. You can see an example below.

The course qualifies for 4 PDUs from the Project Management Institute and is perfect for PMPs or aspiring PMI-ACP candidates. At the end of the course, you earn a Certificate of Completion as proof of your participation.

Overall this course has been in development for 16 months and we’re hopeful you’ll be able to see the attention to detail we put into it.

I hope you find this news as exciting as I do. Please help me out by spreading the word to your friends, coworkers, grandmothers, and anyone else who might be interested. Thank you.

I’ve wanted to update the design of our Planning Poker cards for quite awhile, and we finally got the chance. The new cards feature an all-new back design to go along with the same faces we’ve used for years.

There are 56 cards in the deck. Thirteen estimating numbers are provided in four colors, each with a matching back as shown above. Additional cards include instructions on how to estimate with Planning Poker and feature full-color photos of goats on the back.

The cards are still the same high quality we’ve always provided. Our cards are manufactured by the same company that provides cards for Caesar’s Palace and other leading casinos. The cards come boxed as before although we’ve updated the art on the box cover–check out the leap of that goat!

Cards are for sale on our store. We will continue to sell our branded cards (like these) at our cost of $2.50 per deck. We also have unbranded cards for sale if you don’t want to see any goats anywhere. And we will continue to sell cards with the traditional goat photo backs as long as our inventory lasts.

Let me know what you think of the new design in the comments below.

I find this unnecessary and, in some cases, detrimental to good planning. These large numbers can play a role in estimating and planning on some projects. Let’s see how.

Suppose your boss wants to know the general size of a new project being considered. The boss doesn’t need a perfect, very precise estimate. Something like “around a year” or “three to six months” is enough in this case. To answer this question you’ll want to write a product backlog. You want to put no more effort into this than you need to. Since the boss wants a high-level estimate, you can write a high-level product backlog. Big user stories (“epics”) that describe large swaths of functionality will suffice.

And these epic user stories can be estimated with the large story point values.

Do you want to do this on every project? No, definitely not. There are some projects where when the boss asks for a plan you better be close. “Heads will roll if you’re wrong,” the boss announces on those projects. On those projects you don’t want to estimate epics and, therefore, won’t use the large values. Other projects (such as contract development) won’t have the tolerance for error that may come when estimating epics and using values such as 20, 40 and 100.

But some projects can tolerate that amount of error in the estimates. Mis-estimating a few epics is probably not enough to change the answer we give a boss who just wants to know if we think a project can be released in Q1 or Q4 next year.

Removing the large values from a deck of Planning Poker cards is like deciding to strike “millions” and “billions” from our vocabulary just because our bank balances are only in the thousands.

Each column of data and pair of bars shows data from stories of the size given in the Points row. The first set of data is for one-point stories, the second set of data is for two-point stories and so on. Looking at the one-point data, we see that the median number of hours to complete a one-point story (at this company) was 21 hours. The shortest (From) took 6 hours and the longest (To) took 36 hours. The shortest and longest are shown in the green and blue bars above the table. The median is graphed as the red line.

Let’s look at the two-point stories. We see there a median effort of 52 hours and a range from 31 to 73. If we assume the 1-point stories were perfectly estimated, we would expect 2 point stories to have a median of 42 instead of the 52 we see here. Or perhaps the 2-point stories were done perfectly and the 52 is right. In that case, the median for one-point stories should have been 26. Most likely, neither is perfect and the “perfect” estimates are somewhere between. Either way, the team has drifted a little bit because the median of the 2-pointers does not equal twice the median of the 1-pointers.

But let’s look at the three-point stories. Three-point stories should presumably be triple the median of the 1-point stories. The median should be 63 and we see that it is 64. Wow. Very close.

The five-point stories should presumably have a median of 5×21=105 and they come in at 100. The eight-point stories should presumably have a a median of 8×21=166 but they only come in at 111. But, hold on, we have to make a bit of an adjustment in this thinking for the 5- and 8-point stories. If you use these numbers the way I recommend, you know to think of them as buckets. An 8 is a bucket that holds all stories from six through eight points in size. That is, if you have a story you think is a six, you can’t fit it into the five-point bucket so it goes into the eight-point bucket.

This means that our five-point stories are really fours and fives. If we have the same number of each, the average size of a story in the five-point bucket is really 4.5 points. Multiplying 4.5 points x 21 hours (length of the 1-point story) give 94.5, off by about 5% from our measured median of 101 hours. Not so bad.

Since the 8-point bucket holds stories of size 6, 7, and 8, we can assume the average story given an 8 is really worth 7 points. And 7 points times 21 hours = 147 hours. The 8-point stories should have a median of 147. They don’t, they have a median observed value of 111. So this team has definitely drifted by the time they reach their 8-point stories.

(Let me add a sidenote here that rather than simply assuming the 1-point stories were perfect and using their 21 for all this mulitplication, a better approach would be to do linear regression analysis, which can be done with Excel. You can then look at the r-squared value to see how well the values fit. But, I didn’t want to go through all that math here and with data like this, we can, I believe, see that things work out pretty well up to 8.)

I encourage you to think about collecting data like this at your company. You need to be careful though. Because you’ll be collecting actual effort expended on each user story, it’s possible that team members feel more than the normal amount of pressure to finish within any estimates they give. They may then respond by padding their estimates. This defeats the whole purpose. So, show a graph like the one above to the team and be clear that having this data can help them. For example, the team above could learn that they put 8s on stories that should perhaps have been 5s. (Looking at the data, they could also learn that they estimated correctly but that they really had more sixes in the eight bucket.)

Most teams who do this will find that they are good through about 8, as in this example. With some awareness of data like this and some additional practice and calibration, just about any team can get good across a 1-13 range. Beyond that is tough and numbers above 13 (and possibly starting with 13) should be used with caution or only for answering rough, long-term questions like, “Is this project a couple of months or are we talking about a year to do it?”

If you collect data like this for your teams, I would appreciate it if you would share it with me. You can just email it to mike@mountaingoatsoftware.com rather than posting it here. I’ve been working on some analysis of data like this and the more teams I have, the better.

My first bit of advice is always to try to put off answering until you’re able to get even one sprint of historical data. But that’s not always possible. When it’s not my general recommendation is to conduct one or more commitment-driven sprint planning meetings and use those to forecast likely velocity.

However, some people are still more comfortable thinking in hours and rather than forecast velocity, they want to forecast the number of hours a product backlog will take. From there they will usually estimate the duration of the project (something that could be done more directly with a velocity estimate). But, since it’s a common question, I’d like to address it.

Here’s essentially the question I was asked. I’ve paraphrased, simplified and left out extraneous information:

We have no historical velocity data. We have a product backlog of 300 user stories. Each user story has been estimated, most in the range of 3-13 points. Would the following approach be reasonable:

1. Grab a random sample of 40 stories.
2. Break each of those stories into tasks and estimate the tasks.
3. From the task estimates come up with an average number of hours per story.

For example, suppose the randomly selected 40 user stories total 150 points and that the tasks identified for those 40 user stories total 600 hours. We would then theorize that it is about 4 hours per story point?

Well, yes, the idea here is fine with two problems:

1. It’s important to remember that the relationship between points and hours is not an equivalence. It is not that 1 point equals 4 hours (which is what our example showed above). It is that 1 point equals a mean of four hours with a standard deviation of plus or minus say 45 minutes. This would mean that most of the time (68% of the time) the relationship would be that 1 point takes from 3:15 to 4:45 to finish. It would mean that almost always (98% of the time), one point would take between 2-1/2 and 5-1/2 hours to finish (two standard deviations).
2. The above approach assumes that 1-point stories and 13-point stories are estimated perfectly in relative terms. In other words, it assumes that if the mean duration of a one-point story is 4 hours, the mean of a 13-point story will be 13×4=52 hours. For many reasons, this is unlikely to be true. And the data I’ve collected from a variety of teams, shows that–as we’d expect–teams are not perfect, even though many are amazingly consistent.

So, what can we do to address these problems? A first really simple improvement is to calculate the average number of hours for stories of each size rather than one overall average. For example, in the example above we said that the 40 stories were 150 points in total and 600 hours for an average of 4 hours per point. But, if we averaged the 1-point stories on their own we might find that they were 3.2 hours per point, and the 2-point stories that were broken into tasks were 4.3 hours per point, and the 3-point stories were 4.1 hours, and so on.

We can then multiply that average number of hours by the number of stories on the product backlog of each size. An example using the average hours given above is shown in the following table:

First, notice in the above that the second column is hours per story, not hours per point. The two-point stories were assumed to take 4.3 hours per point so 8.6 (4.3×2) hours per story is shown in that column.

This table shows that we have five 1-point user stories. Each is expected to be about 3.2 hours so we expect to spend 16 hours total on the 1-point stories. Summing the last column in this table gives an expected total of 170.9 hours.

Note that this approach is subject to all the shortcomings that will have been introduced during the task identification and estimation step. Most importantly that the team will fail to identify all tasks. So this approach will estimate the number of hours to deliver the tasks identified. Some adjustment will need to be made to estimate the amount of work that the team failed to identify and the duration adjusted accordingly.

I’ll write about other improvements to this simple approach in upcoming blog posts.

First, let’s remember that a non-functional requirement is a requirement that is more about the state of being of the system than about one specific thing the system does. Non-functional requirements often have to do with performance, correctness, maintainability, interoperability, portability, and so on. They are often called the “-ilities” of a system because so many end in “ility.”

(By the way, in case you’re wondering, non-functional requirements can be written as user stories.)

The challenge with estimating non-functional requirements is that there are really two costs. First is the cost of initial compliance. Second is the cost of ongoing compliance.

To see these two costs at work, let’s consider an example. Suppose we have a performance requirement and that the team is working on a new product. In the first sprint the team may be thinking about performance but they aren’t going to do any performance testing. There’s no code yet. There’s definitely code being developed over the next few sprints and say by sprint five the team decides there’s enough code that they want to start doing some performance testing during that sprint.

Remember our first cost is the cost of initial compliance. In this case, that is the amount of work the team will spend on performance testing in sprint five. That’s not really much harder to estimate than most other product backlog items. The team here thinks about it and they put some number of story points or ideal days on it as their estimate.

To continue our example suppose they do the performance testing and any necessary tuning it reveals during sprint five. Well, in sprint six the team is adding some new features and here is where the second cost comes in–the cost of ongoing compliance. Once the team accepts a non-functional requirement into the project (as our team did here in sprint five) they need to remain in compliance with that non-functional requirement for the remainder of the project. I think of this cost as a tax. Doing performance testing (or staying in compliance with any non-functional requirement) creates some amount of overhead on the team (the tax). This overhead or tax must be paid regularly.

In some cases, the team and product owner will decide the tax must be paid every sprint. For this team, that would mean that every time they add a feature, they do performance testing of that feature and, likely, the whole system. In other cases the team and product owner may agree to pay the tax every few sprints. After all, a team might reason, it’s unlikely we affected the performance characteristics with the user stories we added this sprint and, besides, we aren’t really shipping after this sprint. The first of these cases, in which the team pays the tax every sprint can be thought of like as a sales tax or VAT. The second, in which the team pays every few sprints, is more like an estimated quarterly tax like independent contractors in the US pay.

So, back to the issue of how do we estimate this type of work? Well, estimate both parts separately. Estimate the cost of initial compliance just like any other user story or product backlog item. The team and product owner will need to incorporate an estimate of when they’ll do this. Adding performance testing after five sprints is different than adding it after 20 sprints. For the tax portion, the team and product owner need to agree on when they will do the work: every sprint or after every n sprints. The team can then estimate how much work will be involved over the planned number of sprints and allocate that amount of work to each. For example, suppose the team and product owner agree that they will do performance testing in every fourth two-week sprint. The team then estimates that it will take six points of work every fourth sprint. That’s about 1.5 points per sprint. If a team has a velocity of 30, 1.5 can be thought of as about a 5% tax. It’s likely that the team could be quite wrong on this estimate the first time. Fortunately, the team can easily track how much effort goes into performance testing over a number of sprints and use that to revise their estimate of the ongoing cost.

1. to be able to measure the amount of “business value” delivered to the organization, usually graphing this sprint by sprint
2. to be able to prioritize user stories by comparing the business value of each story to its cost

There are, unfortunately, some problems with these practices.

First, the value of small bits of functionality are often intertwined. When we get features that are too small (as good user stories are), it is very difficult to put a discrete value on each. Economists call this hedonic pricing. The classic example is putting values on the individual components of a house’s value—size, location, view, etc. How would you value each of those aspects of your house? You can see more on hedonic pricing on Investopedia and this example of pricing clothes dryers shows how complex hedonic pricing can get.

Second, the value of a small bit of functionality can often be said to be the total value of the product. For example, what is the value of the left front wheel of a car? Well, since I don’t want a car without that wheel, the value of it is the total value of the car.

Having identified two problems with assessing the “business value” of a user story, let’s look at a problem with determining the cost of the story.

The Problem of Shared Cost

Finally, when attempting to put business value points on small features (such as user stories) there is the additional problem of determining the cost of the feature. There is often a desire to do some form of return on investment (ROI) analysis on features by comparing the business value points to the cost in story points. However, with small features it is often the case that the true cost of implementing a feature is the sum of the cost of implementing multiple smaller parts of the system, some of which (e.g., architectural work) may not be separately estimated.

For example, the cost of refunding money to a credit card purchase should include some of the infrastructural work done to accept credit cards in the first place. That cost, however, was likely estimated as part of the story to “buy the items in my shopping cart.” Failure to share the cost of this credit card processing infrastructure between both the purchase and refund stories will lead to incorrect ROI decisions.

As with hedonic pricing, this is something economists have wrestled with for years. A simple example is a cow raised and sold for beef and leather. How should the costs of raising the cow be apportioned between the user stories of “beef” and “leather”? We could say the beef cost it all and we get the leather for free but that would be no more correct than the opposite. The benefits (beef and leather) need to be considered together in comparison to the cost of raising the cow.

What Do We Do?

So does this mean that we should never assign business value to features and that we should forego ROI analysis of user stories? Not necessarily. But this type of analysis is best used at the level of epics (large user stories) and themes (groups of stories) because value and cost can be appropriately assessed at those levels.

Here’s the video:

My thanks to my daughter, Savannah, who learned Camtasia for Mac while I was traveling last week and then helped me make this today.

But any dependencies that remain can raise questions about how to estimate the individual product backlog items. One common agile project management question is what to do with work that could be performed as part of either of two backlog items but that only needs to be done once. As an example, consider these two product backlog items, which are written as user stories:

• As a user, I can add an invoice to the system so that it gets paid.
• As a user, I can delete an invoice.

These two user stories share some work. Supposing this is a very simple system, whichever one of these stories is done first will also involve the team much of the database design for invoices. Some database design work (a cascading delete between Invoice and Line_Items, for example) will be done only when a specific one of the stories is developed. But, some work (deciding that a table called Invoice exists at all, perhaps) will be done as part of whichever story is implemented first. Assuming that this work is non-trivial, the estimates given to these stories will be influenced by which will be implemented first.

In deciding how to estimate these and how to handle the common work between them, I suggest there are two guiding principles we can rely on:

• We should assume work will be done in its natural order.
• The sum of all estimates on the product backlog should represent the total size of the project (as understood at that time, of course).

Let’s see how these two principles lead to the answer about how to estimate our two user stories about adding and deleting invoices. Although a good agile team should be able to implement these stories in either order, it is most likely that the product owner will ask the team to add invoices first. After all, you can’t delete an invoice until it has been added. This is what I mean by the natural order.

Although it is natural to add invoices to a database before deleting them, it is not hard to imagine a need to do these in the opposite order. Suppose our team is writing a new system to interface with an existing invoice database. That existing system is full of old invoices from the 1940s and the first thing the product owner wants is the ability to delete old invoices.

When a product wants stories done in the natural order or when it seems likely the product owner will want them done in that order, my advice is that the team should estimate with that assumption in mind and not bother noting it on the story cards. Documenting all logical assumptions about the natural order gets tedious. To document all such assumptions, our add an invoice story would also need to be documented with “assumes login story is done first,” and so on.

But when a team knows or suspects they will be asked to work out of the natural order, they should document the assumption. If the team assumes that adding an invoice will be quicker to implement because deleting is already done, they should add appropriate notes to these story cards.

Teams are, of course, sometimes wrong in their assumptions or are surprised by product owners who change their minds. These situations are resolved by simple discussion along the lines of saying “We assumed you’d want these stories in a different order. So, a few points [or ideal days] of work move off this story and onto that story.”

It is even possible that working outside the natural order can sometimes increase the total size of the work. For example, to do the delete invoices user story before the add invoices story, our team might need to write a short script to preload the database with dummy data just so we can be sure delete is working. Usually when this happens the change in project size is very small and washes out in the noise of other estimating and planning errors. (In other words, it’s rarely worse than someone being out sick for a day.)

Why not get around this problem of potentially moving points from one story to another by assuming that each story is done first, which would be a worst case for its estimate? This is where our second principle comes in: The sum of the estimates should add up to the total size of work being considered. If the total work is 8 and that’s what we’d put on a single add+delete user story then our two user stories need a total of 8. To put a higher number on them overstates the size of the project. This would lead to incorrect projections of the project completion date based on velocity.