I have been planning for the start of a new project and one of the key decisions to make is how to manage and format the product backlog. I have come up with a few options that all sound like they could work. So, here's the list:

Whatever: The first option is to just put anything in the list. Make it whatever you get from your customers. This option has the advantage of making your customers feel more involved because the list has exactly what they said. It also has the disadvantage of being harder to understand because it is exactly what the customer said. And, we all know there are three sides to every requirement - what the customer says, what the developer heard, and what is actually needed. The fact that the items can be just about anything makes the estimation and prioritization much more difficult. While this is the easiest to collect, it is harder to manage.

User Stories: A slightly more formal way to maintain the product backlog is to use the User Story format. This format starts with a simple template that keeps all the items one sentence long and in the user's perspective. Here is the template: "As a (kind of user) I want to (functionality desired) so that I can (benefit received because of feature)." This is a simple to use template that you can train a group to use in just minutes. I like to print out a stack of index cards or forms that have this written on it with blanks to fill in the user, functionality, and benefit. This format is much easier to estimate and track because of the inherent consistency of form. It sure looks a lot better on those management reports than the Whatever format. Additionally, it forces you to stay somewhat more high level. I think this is good because higher level requirements means that there will be fewer items in the backlog. A smaller backlog requires less effort to maintain.

Use Cases: A Use Case is a narrative story or numbered set of steps to perform a required task. This format is often fairly detailed and may have embedded user interface prototypes. The advantage of this format is specificity. They can almost look like a story board and can give the end user a really good picture of what the application will be like. This allows the developer and user to iron out most of the confusion before coding the application. The problem with this format is the amount of time it takes to make the Use Case is sometimes just as long as it would take to code the feature! Here is a partial sample of what a Use Case looks like.

So, which one do I recommend? The answer is all of them. Let me explain.

I like to use Use Cases as a basis of analysis and discussion about the critical user features of an application. They are especially good at identifying complex usability concerns and human interaction workflow issues. However, they are simply to complex for the majority of requirements. I only use them for the critical user interactions.

I like User Stories for the bulk of the functional requirements in an application because they are simple and consistent. I can train most users to write them in a matter of minutes and the users can generally do a pretty good job with them. They leave out a lot of detail, but I don't think this is a bad thing. I prefer to have the barely sufficient documentation that User Stories give and fill in the details by communicating to the end user on a regular basis. So, each time a developer picks up a User Story to start working on it I expect the very first step to be a phone call to the end user to talk about what the story entails. This communication gives the customer confidence in the team and makes sure the requirement is the most up to date that it can be when we start coding.

Lastly, I use the Whatever requirements to collect the additional stuff that does not relate to the functionality of the system. For example, if we need to produce a burndown chart for senior management or host a training session for end users. These are tasks that eat up time in the sprint, but they do not add features to the application. So, I track them in the product backlog as "other" kinds of tasks.

This is what I call the Common Sense Approach (CSA) to requirements management. I use what works but only in the case where it works WELL! Don't try to schedule meetings with user stories. Build a use case when you can't understand what the user story is trying to convey, but DON'T build them for every requirement. Unfortunately it would seem that CSA is not all that common. You should try it and let me know how it works for you.