The rich life of stories

Atomic Object has been organizing work around user stories since the very beginning of our company in 2001. Our understanding of stories, their uses, how we write and track them, customer involvement, and level and relationship to testing has evolved considerably over time. A recent experience watching Jeff Patton pull this out of Atomic Object developers made me realize how rich and powerful the story concept has become.

Jeff talked about the life cycle of a story. As a group, we came up with the following phases of this life cycle:

1. Identified
2. Named
3. Structure
4. Estimated
5. Prioritized
6. Selected
7. Disambiguated
8. Implemented
9. Accepted
10. Counted

Identified

Stories are born through a conversation with the customer, or an email, or a planning session. Stories are born generally bereft of detail. Some never make it through the full life cycle.

Named

Stories are given a short name so we can talk about and track them. This happens when they are entered into our iteration planning tool. Some of our customers enter stories directly themselves.

Structured

On most projects we find it helpful to impose a simple structure on the description of a story. We use a template Dan North at Thoughtworks came up with:

    As [a type of user]
    I want to [do something]
    So that [valuable achievement X happens]

Standardizing the language makes it easier for customers to write stories themselves, makes describing stories more efficient by reducing the range of the specification language, and ensures we get the context of the story.

Estimated

We estimate stories so customers can plan the development of their product, and so we have a way of tracking our velocity and projecting the completion date. When stories are given big estimates it often results in conversation between the customer and the developers to break a story apart, better understand complexity and dependencies, and consider alternatives.

We estimate stories in relative complexity points.

Prioritized

Customers place stories into the backlog. Our convention is to keep the backlog loosely prioritized with higher priority stories towards the top.

Selected

The customer selects stories from the backlog to create the next iteration. The customer knows how many stories to place in the iteration by matching the sum of the estimates of the selected stories to the average development velocity.

Disambiguated

Stories typically have plenty of ambiguity, subtlety, hidden crannies, inconsistencies and depth at this point. The structured language we use helps, but doesn’t clarify all aspects of a story—that’s not the intent. Rather than write lengthy requirements in English, or force our customers to write them, we apply the classic, XP definition of a story (“a placeholder for a future conversation with the customer”) and have that conversation. You can think of this as just-in-time requirement specification.

Disambiguating (or the better alternative of “understanding”, as Jeff good-naturedly pointed out) stories now, when you know you’re going to be working on them immediately, saves you from a lot of potential wasted work (stories that are never selected don’t need to have this work done), and makes sure the understanding is gained close in time to when it is needed.

The understanding we gain from the customer is partially captured in structured acceptance tests. These often, but not always, get turned into automated system tests. Whether automated or not, they serve as a means for the customer to know that the story has been understood by the developers, and whether or not it is completed and correct.

We use the following structure for acceptance tests:

    Given [some context]
    When [the user does something]
    Then [the user sees a result]

Implemented

Stories are implemented following our test-driven development practice.

Accepted

At the close of the iteration, a new build of the tool is deployed for customers to evaluate. Customers can refer to the acceptance tests to know the story is complete and correct.

Counted

When a story is accepted by the customer, the developers get credit for having completed it. The number of points this story was estimated at are added to the burndown chart. The total number of points achieved at the close of the iteration contributes to the average development velocity.

If a story isn’t completed, or the customer doesn’t accept it, the developers don’t get credit for the story in this iteration. That in turn lowers the total points achieved, and possibly the average development velocity.

Ten distinct phases in the life cycle of a story? I was struck by the richness of this simple concept when Jeff pulled it out of us and put it on the wall. We’ve so deeply internalized the story as a means for organizing development that we don’t have it written out anywhere. Jeff helped me step back and think about the many phases a story goes through, and all the goodness this simple idea brings to our development process.