Agile Advisor

The Cost of Stories

How can Agile teams put price tags on features? Gregg Boer covers two methods that teams can use to estimate costs.

• By Gregg Boer
• 12/20/2012

Would you like a cookie? If you ask any child that question, they will likely say "yes," unless the cookies are really awful. However, if the child had to choose between a cookie or a piece of candy, they would have to think about which one they really wanted.

This is what I call, the "cookie principle." That is, if you ask a customer if they would like to have a feature, they can almost always think of a good reason to have it. However, what you don’t know is the price they would be willing to pay, and every feature comes at the price of another feature.

One of the most important jobs of a product owner is to put price tags on the features. I’ve often seen a product owner and customer go through an intensive stack-ranking exercise, but without the knowledge of cost. The customer typically picks the coolest features and ranks them at the top.

This is like taking your daughter shopping for a dress, but staying outside of the store and window shopping. Your daughter may pick the prettiest (and probably the most expensive) dress. But you aren't done shopping until you know the actual price. That's when the real trade-offs happen.

A stack-ranking exercise without any kind of cost analysis is like window shopping. Maybe you didn’t know your customer liked feature x. But you aren’t done stack-ranking until the customer knows the price tags for various features, and begins making real tradeoffs.

Both the "cookie principle" and the "pretty dress principle" represent the same, simple concept: A decision to include a feature should never be made without some cost analysis. These principles are simple, but often forgotten.

In Agile, one of the most common methods for pricing a feature is to use story points. Story points give the customer and the product owner some idea of cost.

Many teams don’t estimate the story until right before they commit to working on it--during the sprint planning meeting. This is like deciding to buy the pretty dress, without knowing the cost until you check out at the register. Some Dads may have the cash to make decisions that way, but most don’t.

An Agile team has a limited set of resources that need to be spent wisely. Simple math tells you that a team of seven people could cost $12,000 to $17,000 a week to run. A three-week sprint can cost close to $50,000. That kind of investment warrants some cost research. Cost is a key piece of information that should be used when spending those resources, and deferring the knowledge of it to the very end isn’t wise.

Story Pointing Blitz
Two simple approaches enable Agile teams to do cost research. With the first approach, the team takes a backlog that has been prioritized without cost information. The goal is to quickly discuss each story, and immediately estimate it. If the team is fairly close in agreement on the estimate, someone is designated to pick the estimate to go with, and the team moves on.

A story pointing blitz can be a bit unsettling, however. Engineers love precision, and this is not a precise exercise. Everyone on the team should understand the following:

• The goal isn’t to get accurate cost information. It's to get any cost information. The estimates produced in this meeting are only to put price tags on stories, and to facilitate more productive discussions with the customer.
• This will not be the only time the story will be estimated. It will be estimated again, once the story has been groomed and the team has more information. Knowing this, the team can cut short discussions about whether something is five or eight story points. The difference of three story points does not mean much in the grand scheme of things.
• The estimates will never be used for commitments. It’s very tempting to take these estimates and begin crunching numbers to determine what features will be done by a certain important release date. The product owner must be very careful with this, because when a feature set is communicated and associated with a specific date, others may turn that information into a commitment, even if that wasn’t the intent.

As fuzzy as these estimates are, it's amazing how valuable they are when you start trading features against each other. Think of it as scanning Amazon and eBay for prices. It's not precise cost research, but it's still useful.

Grooming Estimates
The second approach is to do the estimates during grooming meetings, before the sprint planning meeting. Estimation almost always comes with emotional and political baggage. Estimating right before a commitment only increases that baggage.

A weekly meeting can be used to groom the stories before they are brought to sprint planning. The product owner presents upcoming stories to the team. The team has time to understand the stories, ask questions, and even push back or offer tradeoffs.

It’s a good idea for the team to see the story in one meeting, and estimate it in another meeting. This allows the team to think about it over the week. Amazing ideas can emerge by letting intelligent people ponder something! I’ve seen the team offer amazing solutions that are better and cheaper when they are given the time to think it over.

After the team believes they understand the story, they estimate it. This estimate is used to make the final prioritization decision: What to bring to the next sprint planning meeting.

If your backlog is like most, it has lots of cookies and pretty dresses. Your job, however, is to give customers the most important features first.