Good agile stories

So what is a good story? I’ve been asked that frequently as of late.

The basic thing about a real story is that it's a metaphor for the work being done. It is not a requirement but a reminder to collaborate about the topic of the story - in other words in agile development (good agile at least), the documentation is secondary to the collaboration. So the story doesn't make you agile, it's the underlying philosophy.

A good story, from our perspective uses the invest model –
Independent – reduced dependencies = easier to plan
Negotiable – details added via collaboration
Valuable – provides value to the customer
Estimable – too big or too vague = not estimable
Small – can be done in less than a week by the team
Testable – good acceptance criteria

But a story is really driven by the acceptance criteria. In other words we try to determine how we'll know when we have satisfied the story before we put any details in it – and we mean actually enough details that we can test the story.

I'd be glad to speak with you in on the phone or via email. Part of my job as agile coach is (surprisingly) coaching agile teams.

Our stories have 3 parts, the title, the description and the acceptance criteria. The description is the only part that can be explained as a reasonable template.

Start by writing the description. It should be long enough to allow people on the team can differentiate it from other stories but short enough to fit on a 3” X 5 “ sticky card when written with a marker. Rule of thumb is that a description should be less than 10 words.

Now write the description. You can use the template below.
As a [user role] I want to [goal] so I can [reason].

Using the description, write acceptance criteria. This is the critical piece of the story. Ask the question “how will I know I’ve satisfied the goal and supported the reason” or “how will I know I’ve done that?”

I'll blog another time with examples.