Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing

 

Click here to view the complete list of archived articles

This article was originally published in the Summer 2008 issue of Methods & Tools


Acceptance TDD Explained - Part 2

Lasse Koskela

1 Introduction to user stories

User stories are an extremely simple way to express requirements. In its classic form, a user story is a short sentence stating who does what and why. In practice, most stories just tell us who and what, with the underlying motivation considered apparent from the context. The reason a story is typically only one sentence long (or, in some cases, just one or two words that convey meaning to the customer and developers) is that the story is not intended to document the requirement. The story is intended to represent the requirement, acting as a promise of a future conversation between the customer and the developer.

1.1 Format of a story

A number of people have suggested writing user stories that follow an agreed format such as "As a (role) I want (functionality) so that (benefit)." However, I and a number of other proponents of user stories for requirements management recommend not fixing the format as such but focusing on the user story staying on a level of detail that makes sense, using terms that make sense to the customer. This is not to say that such a template would be a bad ideaówhich it isnít; itís just that one size doesnít fit all, and the people in your organization might feel differently about the format than I do [1].

On the physical format of user stories

In part because user stories are concise, many co-located teams keep their user stories written on small index cards or sticky notes, managing them on a whiteboard or other task board. This method is beneficial because communication is clear and progress is immediately obvious. Therefore, more and more multisite projects are also adopting such physical story cards for managing their work locally. After all, the benefits often far outweigh the hassle of relaying the status from the task board to electronic format for distribution. The use of index cards on an early XP project gave birth to the mnemonic of 3 Cs: card, conversation, confirmation.

1.2 Power of storytelling

Hannah Arendt, a German political scientist, has said, "storytelling reveals meaning without committing the error of defining it. [2] This particular quote eloquently communicates how user stories focus on meaning without stumbling on nitty-gritty details.

Inside every story is another one trying to come out

Just like there are multiple solutions to most computing problems, there is always another way to write a given user story. Indeed, it might make sense to take a closer look at a user story before rubberstamping it as a technical story. There is usually a way to express the story in a way that conveys the underlying value - the rationale - of the story. If you canít figure out that value, try again.

User stories are in many ways a form of storytelling, which is an effective medium for transferring knowledge. For one, people like listening to stories. Storytellers are good at keeping our attention - a lot more so than, say, structured documents of equal volume - and itís not just audible stories that have this advantage; prose with a storyline and context is far more interesting reading than a seemingly unconnected sequence of statements.

Letís see how much this property shows through in practice by looking at a couple of examples of user stories.

1.3 Examples of user stories

To get a better idea of what user stories look like, here are some examples of the kinds of user stories I personally tend to write:

  • "Support technician sees customerís history onscreen at the start of a call"
  • "The system prevents user from running multiple instances of the application simultaneously"
  • "Application authenticates with the HTTP proxy server"

These user stories express just enough for the customer to be able to prioritize the feature in relation to other features and for the developer to be able to come up with a rough effort estimate for the story. Yet these stories donít burden the developer by prescribing the implementation, and they donít drown the team with excessive detail.

The first story about a technical-support application doesnít tell us what the screen will look like; and the second story doesnít talk about desktop shortcuts, scanning process listings, and so on. They convey what provides value to the customerónot how the system should provide that value. The third story is a bit different. Itís clearly a technical user story, not having much to do with business functionality. It does, however, have enabling value, and it expresses that need in a clear manner. Furthermore, although harder to quantify, some technical stories might create value for the customer through lower total cost of ownership.

Thatís about all weíre going to say about user stories for now. For a more in-depth description of user stories as a requirements management and planning tool, a great pick would be Mike Cohnís book User Stories Applied (Addison-Wesley, 2004).

As we already mentioned, the format of a user story doesnít matter all that much as long as it communicates the necessary informationówho, what, whyóto all involved parties, either explicitly or implicitly. In fact, just like the format of a story isnít one-size-fits-all, using stories as a requirements-management or planning tool isnít in any way a requirement for doing acceptance test-driven developmentóitís a natural fit.

Now that we know what the mysterious stories are (or what they can be), letís figure out what we mean by acceptance tests.

Go to part 1    Go to part 3    Back to the archive list

Software Testing
Magazine


The Scrum Expert