please enable javascript

Points Are About Relative Effort Not Ranking

February 19th, 2012

I’m thinking of buying a new car. So I’ve put together a list of cars to consider. Here they are in priority order:

  • Bugatti Veyron Super Sports
  • Pagani Zonda Clinque Roadster
  • Lamborghini Reventon
  • McLaren F1
  • Koenigsegg CCX
  • Porsche Carrera GT
  • Aston Martin Vanquish
  • Toyota Prius
  • Toyota Camry
  • Tata Nano

Unfortunately, though, I’m not sure I can afford my top priority car. So let me put some points on each car. I’ll start with the least desirable car and put a 1 on it, a 2 on the next car, etc. That reorders our list so with points on each car we get:

  1. Tata Nano
  2. Toyota Camry
  3. Toyota Prius
  4. Aston Martin Vanquish
  5. Porsche Carrera GT
  6. Koenigsegg CCX
  7. McLaren F1
  8. Lamborghini Reventon
  9. Pagani Zonda Clinque Roadster
  10. Bugatti Veyron Super Sports

Now I think about my personal spending limits and I can spend between $25-$50k on a car. I’d like to be closer to $25k but a good salesman might get $40-50k out of me. Since the Tata Nano (at one point) goes for about $2500 that means I can afford between 10-20 points.

So, looking at the list again and the points assigned to each car, I think I’m going to buy a Bugatti (10 points), a Pagani (9) and a Tata (1 point). Unfortunately, when I show up at the Bugatti dealer, I am somewhat informed that the Veyron lists for $2,400,000.

What went wrong here?

The problem is that points are not a ranking. When we rank product backlog (or car backlog) items we use ordinal numbers (such as first, second, third). We cannot add ordinal numbers together. We cannot say that the distance between first and second is the same as from second to third. The Bugatti in this example is not ten times the cost of the Tata.

Ranking stories (or cars) like this is worthless. We want story points to instead reflect the relative effort involved. For cars we could put points on as follows:

Tato Nano 1
Toyota Camry 12
Toyota Prius 14
Aston Martin Vanquish 102
Porsche Carrera GT 193
Koenigsegg CCX 218
McLaren F1 388
Lamborghini Reventon 640
Pagani Zonda Clinque Roadster 740
Bugatti Veyron Super Sports 960

These points are of course based on the relative costs of these cars. I need to be able to do the math on these estimates that someone would want to do. Someone can afford 20 points on a car–which should they buy? Should I buy this item for 10 points or those other two for 5 points each? You can’t do that when points are assigned via a ranking.

Story points on an agile product backlog represent the effort to implement the backlog item. Since cost on most software projects is made up almost exclusively of labor (rather than buying parts), we can think of a story point estimate on the product backlog as being the cost, as in the car example here.

And, when I look at the relative costs here, I can tell I belong in the Toyota dealership rather than the Bugatti dealership.

Posted in Agile Estimating, Agile Planning | 13 Comments »

Agile Succeeds Three Times More Often Than Waterfall

February 13th, 2012

Agile projects are successful three times more often than non-agile projects, according to the 2011 CHAOS Manifesto from the Standish Group.

The report goes so far as to say, “The agile process is the universal remedy for software development project failure. Software applications developed through the agile process have three times the success rate of the traditional waterfall method and a much lower percentage of time and cost overruns.” (page 25)

The Standish Group defines project success as on time, on budget, and with all planned features. They do not report how many projects are in their database but say that the results are from projects conducted from 2002 through 2010. The following graph shows the specific results reported.

Agile and waterfall success and failure rates

Posted in News | 42 Comments »

Estimating and Planning Are Necessary for Maximizing Delivered Value

February 6th, 2012

Because I’m so interested in estimating and planning, I always take notice when I see a new blog post or news group posting claiming, “Estimating is waste! Don’t do it!” The thing that never shocks me about these arguments against estimating and planning is that they never come from the business people for whom we are developing products or systems. They understand the value of estimates and plans (and the shortcomings of poor estimates and plans).

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.

Posted in Agile Estimating, Agile Planning | 26 Comments »

Announcing an Online Agile Estimating and Planning Course

January 31st, 2012

I’m very excited to let you know that we now have an online course on Agile Estimating and Planning. The course is a series of videos and interactive quizzes. Videos are a combination of screencast (slides) and live action of me. All videos are extremely professionally done–no handheld video camera or recordings of me talking into my iPhone.

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.

Sample quiz question from online agile training

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.

Posted in Agile Estimating, Agile Planning, News | 8 Comments »

Rotating the ScrumMaster Role

January 26th, 2012

Some teams that struggle with choosing the best ScrumMaster decide that an appropriate strategy is to rotate the role among all team members. I don’t advocate this, as I don’t think it demonstrates an appropriate respect for the challenges and significance of the role. In my family, we rotate who cleans the table and loads the dishwasher. Any of us can do that job. We do not, however, rotate who cooks dinner. My wife is a far better cook than anyone else in the family. We want the cooking to be the best it can be, so we don’t rotate that job. If you want your Scrum team to be the best it can be, I do not recommend that you make a habit of rotating the job of ScrumMaster.

However, there are some occasions when you may want to rotate. The most common is when you want to create learning opportunities. For example, if team members are struggling to understand the duties of the ScrumMaster, they may want to consider rotating each team member through the role. This may allow each to develop an understanding of what it means to be a ScrumMaster. Similarly, if a team identifies four or five good ScrumMaster candidates among their ranks, it may want to rotate among them, giving each a chance to try the role. Then by considering the performance of each, the team will hopefully be able to choose the most appropriate ScrumMaster.

Bob Schatz and Ibrahim Abdelshafi of Primavera Systems point out another reason why rotating might be useful.

With time the team can begin to treat this position as their manager. And the person in that position typically detects and dutifully fills the apparent need. The result is a breakdown in the team’s self-management practice. By rotating the responsibility at the start of each sprint, it diffuses the role and makes it a shared team responsibility and establishes a balance of power. (The Agile Marathon in the Proceedings of Agile 2006)

So, although it is possible to rotate the job of ScrumMaster, I recommend doing it only for specific reasons, such as those just given, and only temporarily. Rotating should not be a permanent practice. There are simply too many problems with it, including the following:

  • Someone who has rotated into the role usually has other, non-ScrumMaster tasks to perform during the sprint, and these often take priority.
  • It’s hard to train enough people to do the role well.
  • Some people will use their time as ScrumMaster to try to push through changes to the process.
  • Designating someone as ScrumMaster for a sprint or two does not automatically make someone value the job, which can lead to ScrumMasters who think Scrum is a mistake.

Posted in Scrum/Agile Roles | 18 Comments »

Please Help Me List the Problems with Using Agile or Scrum

January 3rd, 2012

I’m trying to create a list of the biggest, most common, or hardest to overcome problems that a team might face when adopting Scrum or agile. I could really use your help by contributing to the list by adding a comment to this post. I’m thinking of things like:

  • We have five product owners. What do we do?
  • We drop work from every sprint. How do we get out of that habit?
  • We can’t ever get things “potentially shippable” at the end of a sprint. How can we?
  • We spend forever in planning meetings. How can we spend less time doing that?
  • etc…

So, what problems have you encountered or heard of teams encountering?

Thanks for your help.

Posted in Musings, Transitioning to Agile | 88 Comments »

Recommendations not Rules

January 2nd, 2012

I seem to be encountering more and more people who want to codify agile into a set of rules. I’ve seen this lately in authors of books, blogs or PDFs about agile or Scrum that say “You must do this” or “If you don’t do this or all of that then you’re not doing it right.” Over the last few months I also encountered this in conversations with a few Project Management Offices (PMOs).

That leads me to my new year’s resolution for 2012 and one that I hope a lot of others will make with me: make recommendations not rules.

There are very few hard-and-fast rules to agile software development. I’d put things like:

  • work in iterations of no more than a month long
  • by the end of each iteration be “done” with something to some pre-agreed upon definition of done and solicit feedback from your key stakeholders on it
  • at the start of an iteration, get together and figure out what you’re doing to do during the iteration
  • at the end of the iteration, reflect on how well you did during the iteration
  • talk a lot during the iteration

Beyond that, it’s much more about recommendations. And there are plenty of things we’ve learned in the nearly 20 years that some agile processes have been around in even informal forms. For example, I recommend teams use user stories as their approach to requirements. I recommend teams use story points for estimating. I recommend that the team pick a day other than Mondays for starting their iterations. I recommend the Szechuan Chicken at Spice China. But, none of these things is required for success with agile. Each may help a team be better, and I have reasons I recommend each. But, these things are not required.

So, my resolution for 2012: Make recommendations not rules. I’d kind of like to make it a rule that you join me in this resolution, but I’ve just resolved not to make such rules.

Posted in Musings, Transitioning to Agile | 30 Comments »

New Planning Poker Card Design

December 4th, 2011

Blue Planning Poker Cards

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.

Fan of Planning Poker Cards

Planning Poker Card box

Posted in Agile Estimating, News | 6 Comments »

In Defense of Large Numbers

November 28th, 2011

People are often surprised that I allow (or even encourage) people to estimate with story points as large as 20, 40, and 100. We include these values in the decks of Planning Poker cards that we sell and give away in classes and at conferences. Yet many people tell me they start out my taking the 20, 40 and 100 cards out of the deck and throwing them away.

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.

Posted in Agile Estimating | 21 Comments »

Stories, Epics and Themes

October 24th, 2011

I’ve been getting more and more emails lately from people confused about the difference between “user story”, “epic” and “theme.” So I thought his month we’d return and cover some basic–but very helpful–territory by explaining those terms.

First, the terms don’t matter that much. These are not terms with important specific meanings like “pointer” to a programmer or “collateralized debt obligation” to whomever it is that’s important. Story, epic and theme are merely terms we use to help simplify some discussions teams have. The terms do have standard meanings that date back to some of the earliest Extreme Programming (XP) teams. And it’s nice to use terms in industry-standard ways. But, if these terms didn’t exist, you’d make up your own.

So let’s see what each means.

A user story is simply something a user wants. Stories are more than just text written on an index card but for our purposes here, just think of user story as a bit of text saying something like “Paginate the monthly sales report” or “Change tax calculations on invoices.” Many teams have learned the benefits of writing user stories in the form of “As a I so that .” But it is not necessary that a user story be written that way. The advantages of that format are covered elsewhere on this site.

An epic is a large user story. There’s no magic threshold at which we call a particular story an epic. It just means “big user story.” I like to think of this in relation to movies. If I tell you a particular movie was an “action-adventure movie” that tells you something about the movie. There’s probably some car chases, probably some shooting, and so on. It tells you this even though there is no universal definition that we’ve agreed to follow and that an action-adventure movie must contain at least 3 car chases, at least 45 bullets must be shot, and …

So, “epic” is just a label we apply to a large story. Calling a story an epic can sometimes convey additional meaning. Suppose you ask me if I had time yesterday to write the user stories about the monthly reporting part of the system. “Yes,” I reply, “but they are mostly epics.” That tells you that while I did write them, I didn’t get the chance to break most of them down into stories that are probably small enough to implement directly.

Finally, “theme” is a collection of stories. We could put a rubber band around that group of stories I wrote about monthly reporting and we’d call that a “theme.” Sometimes it’s helpful to think about a group of stories so we have a term for that. Sticking with the movie analogy above, in my DVD rack I have filed the James Bond movies together. They are a theme or grouping.

Hopefully you’ve found this short explanation helpful. I look forward to your thoughts.

Posted in Sprint Artifacts | 27 Comments »

« Older Entries