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.

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.

As you probably know I’m a big fan of writing the product backlog in the form of user stories and of writing user stories in the form, “As a , I so that .” An example being, “As a frequent flyer, I really want to be able to connect to the internet while flying so that I can update my blog while traveling rather than having to save this as a text file and updating my blog later.” (Can you guess where I am while writing this?)

What I’ve found makes a user story in this format very easy to work with in a spreadsheet is to take the boilerplate parts and put them into column headings. So we’ll have column headings like “As a” and “I” and “so that”. The meat of each story is then clearly visible in each row. Additional columns can be added for things like a unique identifier, notes, status and such. In this example, I’ve also included a column for the theme or grouping of which the story is a part. You can see this in the screen capture below. You can click the image for a larger view.

But what about a bug found today in something the team wrote a month or a year ago? And what about the existing bug database that a team new to agile is almost sure to bring with them?

The ideal situation is to put the bugs right onto the product backlog. To see why, consider the situation from a user’s perspective: Do you think a user cares whether something is considered a New Feature or a Bug? No. The user just wants the system to behave in some way different from how it behaves today. They don’t care what it’s called.

But notice I called this the ideal situation. It isn’t always practical–and sometimes for reasons out of the team’s control or influence. Bug databases have a way of becoming embedded into organizations. The tech support group uses them as a primary way of communicating with the developers. The marketing group uses the bug database in a similar way. This makes it quit the bug database cold turkey.

In these cases, the most common solution teams use is to have two backlogs

• a product backlog of features
• a bug backlog

This approach is a bit harder on the team and the product owner but allows an agile team to work more easily with existing processes in the organization.

Sometimes when we make such accommodations to the overall organization, the accommodation can damage or destroy the agile adoption. Allowing everyone to work on five concurrent projects is an example of a crippling accommodation. Accommodating the organization’s use of a bug database is not crippling. It’s just a bit more work.

The product owner takes on most of the additional work by having to prioritize two separate work queues and then present them to the team in a more or less consolidated manner (“My top priorities are the first three items on the product backlog, then bugs #12403 and 12415, then these next two items on the product backlog…”). This isn’t too onerous as the items would need to be prioritized even if all were in one backlog.

So: Ideally bugs belong on the product backlog just like any feature request. But, that would often necessitate a significant change for the rest of the organization so two backlogs are used.

Thinking back into the dark ages, I can remember when I first read about “non-functional requirements.” The term threw me for a loop. “If it’s non-functional, why do I care about it?” I’m sure the author of that book clarified this for me a page later, but the term has always seemed an odd one to me. I prefer to think of non-functional requirements as “constraints” we put on the system. When a product owner says “this system must perform adequately with 100,000 concurrent users” the product owner is putting a constraint on the development team. The product owner is effectively saying, “Develop this software any way you’d like as long as you achieve 100,000 concurrent users.” Each constraint we put on a system narrows the design choices a bit; calling these “constraints” rather than “non-functional requirements” helps us remember this.

Fortunately constraints / non-functional requirements can be easily handled as user stories. Here are a couple of examples:

• As a customer, I want to be able to run your product on all versions of Windows from Windows 95 on.
• As the CTO, I want the system to use our existing orders database rather than create a new one sot that we don’t have one more database to maintain.
• As a user, I want the site to be available 99.999% of the time I try to access it so that I don’t get frustrated and find another site to use.
• As someone who speaks a Latin-based language, I might want to run your software someday.
• As a user, I want the driving directions to be the best 90% of the time and reasonable 99% of the time.

As you can see from these I was quite easily able to stick with the “As a <type of user>, I want <some goal>, so that <some reason>” template that I prefer for most user stories. I do this for a couple of reasons but want to comment further on only one of them here. Consider the example of the CTO constraining the team to use the existing orders database. (This was the real situation; the team was considering a second orders database that would be sychronized at night. The CTO overheard this and said “no!”) If we wrote this requirement as simply “Must use existing orders database” it would be entirely possible that a few months down the road we wouldn’t remember why we should be constrained in that way. We’d ask the product owner if she cared if we used a secondary database, and she’d say she had no objections. And we’d make a mistake of using one. Embedding the person who wants something can be very useful.

But, you should be careful not to get obsessed with that template. It’s a thinking tool only. Trying to put a constraint into this template is a good exercise as it helps make sure you understand who wants what and why. If you end up with a confusingly worded statement, drop the template. If you can’t find a way to word the constraint, just write the constraint in whatever way feels natural

At a recent conference, someone asked me why. Because I get that question fairly often I want to give three reasons why here:

Reason 1
Something significant and I’m tempted to say magical happens when requirements are put in the first person. Obviously by saying “As a such-and-such, I want….” you can see how the person’s mind goes instantly to imagining he or she is a such-and-such. As for the magic, Paul McCartney was interviewed and asked about why the Beatles songs were so amazingly popular. One of his responses was that their songs were among the first to use a lot of pronouns. Think about it: She Loves You, I Wanna Hold Your Hand, I Saw Her Standing There, I Am The Walrus, Baby You Can Drive My Car, etc. His point was that these helped people more closely identify with the songs. I tried briefly to find a source for this interview tonight and the closest I found was this. The information in that reference fits my recollection of hearing McCartney says this during a radio interview in 1973 or 74 that I assume was recorded when the Beatles were together.

Reason Two
Having a structure to the stories actually helps the product owner prioritize. If the product backlog is a jumble of things like Fix exception handing, Let users make reservations, Users want to see photos, Show room size options, and so on, the product owner has to work harder to understand what the feature is, who benefits from it, and what the value of it is.

Reason Three
I’ve heard an argument that writing stories with this template actually suppresses the information content of the story because there is so much boilerplate in the text. If you find that true then correct it in how you present the story. I’ve seen backlogs in Word that present the boilerplate in grayed text with the unique parts in black. I’ve created product backlogs in Excel that use column headings to filter out the common text. Look and you’ll see what I mean:

Seriously take a look at the image above before continuing….I’ll wait……Please, really look at it before reading further…..

OK, here’s how I bet you read the spreadsheet. I bet that as you read most of the rows you added in the “As a…”, “I want….” and “so that….” text, possibly even by looking at the heading as you read across each row. I’ve experimented by asking people and this is what most people do. If that text is unnecessary, why do we mentally mouth the words to ourselves or even glance at the heading while reading the row? Perhaps it’s not so non-essential after all.

For now, and probably a long time to come, I’ll be sticking with the “As a <type of user>, I want <some goal> so that <some reason>” template for these and other reasons.

• While there may be users of the system they are not often not direct users (i.e., with hands on the keyboard waiting for something to happen)
• The functionality is often larger than will fit in one iteration

So that we can deal with these challenges, let’s make up some more context for the example. Suppose our financial system takes in a lot of daily data and produces flat files that will be sent to banks and other partners at the end of the day. Some of the files are simple formats. Other files are in more involved formats with multiple record types within the file and possibly with multiple lines for some of the transactions. This would be a fairly standard batch-processing type application.

I want to write user stories in the template I recommend in the book: As a , I want so that . So, let’s deal with these challenges in order and first try to figure out who the user will be in our stories? Given the context provided above the user, is probably a bank or business partner. This will let us write stories like “As a bank, I want…” It’s entirely possible that we will want to get more specific and sometimes write stories for more specific users:

• As a commercial bank, I want….
• As a savings & loan, I want…
• As the Bank of America, I want… (assuming we have some specific business partnership that provides BofA with unique functionality)

Now, what is it these banks want?

At a high level we can start out with some epics, perhaps like these:

• As a bank, I want to receive a file showing all checks to be cleared so that I can debit and credit the right accounts.
• As a bank, I want to receive a correctly formatted 5300 file so that I can adjust balances as appropriate.
• As a bank, I want to receive a file showing the status of all resubmitted transactions so that I can update the database with new information.

(Note that I am liberally making up specific business rules or details. Presumably someone writing the real user stories could add real and relevant detail instead.)

First, notice it is OK to humanize the bank with “As a bank, I want…” Programmers do this all the time in conversation. “OK, suppose I’m the bank and you send me a 5300 file with a bad record. In that case, I’ll…”

As I said at the start of this post, one of the challenges in an application like this is that some of these user stories we just made up could be large. Suppose our mythical file format 5300 includes a header, three different record types, and a footer. We could break up the 5300 file user story above into things like:

• As a bank, I want to receive a 5300 file with the correct header and footer so that I can process the file correctly.
• As a bank, I want to receive a 5300 file with correctly formatted prearranged payment records so that I can process those correctly.
• As a bank, I want to receive a 5300 file with correctly formatted deposit entry records so that I can process them.
• As a bank, I want to receive a 5300 file with correctly formatted addendum records so that I can process them.

If those were still too big, I would find ways to split them smaller based on the specific formatting of the records. Suppose our deposit entry record type sometimes fits on one line but can also span multiple lines. In that case I could write these user stories:

• As a bank, I want to receive a 5300 file with correctly formatted single-line deposit entry records so that I can process them.
• As a bank, I want to receive a 5300 file with correctly formatted deposit entry records that include continuation lines so that I can process them.

Is the system “potentially shippable” after each of these user stories is delivered? Yes, it kind of is. While I’ll admit that we’re unlikely to find a bank that will take a 5300 file with only a header and a footer, it’s possible. Especially if we think of the situation in which the bank is simultaneously writing their own software to process the 5300 files we send them. Imagine meeting with the bank before the start of the next iteration and perhaps agreeing, “OK, in this iteration we’ll create some blank 5300 files with just headers and footers. But that will let us make sure that the communication problems are worked out, that you can read the files we write, and so on….” These stories also work well because they will likely fit with how the programmers will want to build the system.

Suppose a tester and I are working on the story about auto-incrementing the next check number in a checkbook management system. We would talk before getting started and agree that I’m going to go code the simple scenario where the user enters one check after another and that we’ll force the session to start with check 100. So entering five checks will give 101, 102,…105. The tester goes and writes an automated test for that while I code it. We check that in tomorrow morning and it becomes part of the nightly build. We’ve just exchanged work at a level smaller than the individual user story / product backlog item. Let’s do it again.

Next the tester and I talk and agree that we want to read the last check number from the file storage part of our product. So now our check numbers have to start at the right place rather than always starting with 100. The tester writes the automated tests while I code. We both check in our work and add it to the nightly build.

Next we decide to tackle the situation where the user doesn’t enter one check after another. Instead of check, check, check, check we want to handle sequences like check, check, deposit, EFT, check, deposit, check and make sure the check numbers are incrementing correctly.

Then we decide to handle the case where the user manually types in a check number, overriding the default. Perhaps an analyst figures out what to do in some edge cases around this part of the user story (do we warn the user they’re missing a check? does the sequence start to go off the last entered check number or the highest check number?). While the analyst figures that out the tester is automating and I’m coding. And so it goes….

About two weeks later I’m again on the road and Tonya emails me saying, “Did you want me to find a different hotel in Denver or are you just not going to do that class?” I’m very confused because she’s told me the “hotel is booked.” Since that’s the case why is she asking me about booking a different hotel? We exchange a few more emails until I finally realize that her reply to me (“The hotel is booked”) did not mean “I’ve finished with that task; the hotel is booked.” It instead meant “The hotel is already booked by someone else; now what should I do?”

What’s interesting is to look back over the communication–nothing is wrong with what either of us typed into our emails except that we were each coming out the question from a completely different context.

Here’s a second example of how easy it is to miscommunicate: I’m in London this week teaching some classes for my good friends at Conchango. Since I can’t watch the basketball playoffs as I normally would this time of year I’ve been taking the opportunity to try to learn the rules to cricket. To someone with absolutely no prior exposure to the game it’s quite confusing especially as it seems to go on forever. I mentioned to my class today that I’m trying to figure the game out. One of the participants in the class shared with me the following instructions. These are apparently marketed as “Cricket Rules for Foreigners” throughout the UK:

You have two sides, one out in the field and one in. Each man that’s in the side that’s in goes out, and when he’s out he comes in and the next man goes in until he’s out. When they are all out, the side that’s out comes in and the side thats been in goes out and tries to get those coming in, out. Sometimes you get men still in and not out.

When a man goes out to go in, the men who are out try to get him out, and when he is out he goes in and the next man in goes out and goes in. There are two men called umpires who stay all out all the time and they decide when the men who are in are out. When both sides have been in and all the men have been out, and both sides have been out twice after all the men have been in, including those who are not out, that is the end of the game!

These rules are obviously intentionally obtuse. Notice how they are (probably) perfectly correct yet they say nothing about how to really play cricket. What strikes me is how similar these rules are to many requirements documents I’ve seen in the past–they may be accurate and perhaps clear to someone who already knows what is being said but they sure don’t convey any true understanding to the reader.