Agile User Stories – A Recipe for Exceptional Stories

Agile User Stories – A Recipe for Exceptional Stories
By Joel Oosthuizen

INVEST in your user stories

Why do so many of us battle with writing good stories?

I often see people who struggle with user story slicing and dicing. “Is it too big”, “where should I slice it?”, “can this be included in that user story as part of the same user journey” are questions that I’m faced with daily. And naturally so. Many of us come from processes that worked the other way around. I.e. back then it wasn’t required to think so hard about the value of a requirement, because we will probably only see this change being implemented in two years. If it isn’t what we need, we will raise a change request.

Use training wheels first

Fortunately in Agile methods we think of the value that the story we are pondering up will derive for the customer. If we are lucky enough we have the customer on the team with us to take much of the guess-work out of this value question. But many don’t have this luxury and need a set of practice wheels while getting acquainted to the way of writing good user stories.

INVEST criteria for healthy stories

When I train people new to Agile on the practices of writing user stories, I am satisfied when they are comfortable with the INVEST criteria for good story writing. Let’s dive into the meaning.

I – Independent: We must be able to swap stories out quickly without causing a ripple effect of replanning. Stories should be free of any sequence so that they can be individually prioritized.

N – Negotiable: Stories are reminders to have conversations and should not be seen as a signed-off contract. The actual result of a user story is the collection of conversations that occurred during the sprint between customer (or product owner), developer and tester at a minimum. Always remember that the goal is to meet the customer need and not to develop each user story to the letter. If you prefer the latter then get back to waterfall.

V – Valuable: Every story must yield value to either a customer or an internal process like non functional requirements. If it doesn’t add value it mustn’t be done. Period.

E – Estimable: A story must be sizable so that it can be planned for. If it is inestimable then it is probably too large or too many unknowns exist. Break it down more and pin down some assumptions if you can’t figure out all ambiguity.

S – Small: A story should be as small as possible but still deliver value. Having a constant stream of same-sized work packages through the system aids our predictability and reduces variance. Do the simplest thing and then stop. Steer clear of gold-plating at all cost.

T – Testable: If we cannot test a story then we should reconsider if it’s a user story at all. Otherwise how would it ever be done if we can’t measure it against defined acceptance criteria? Acceptance criteria being defined upfront proves that the user story is testable and encourages collaboration around the story early on.

Putting it all into practice

The proof is in the pudding. For your next user story workshop/ backlog refinement session, practice writing user stories with INVEST in mind. When in doubt ask “how will I know it’s done”. Learn more about writing brilliant Agile requirements.

Article Source: Agile User Stories – A Recipe for Exceptional Stories