Agile BA

INVEST in your User Stories to ensure healthy outcomes

Invest in Agile User Stories

INVEST in your user stories

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

I often see people that 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 requirement in two years and then if it isn’t what we need, we will raise a change request.

Use training wheels first

Fortunately in Agile methods we are forced to think of the value that the user 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 user 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 – Independant: We must be able to swop user 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 user 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 user 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: Stories 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 user 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”.

What’s next?

  • You have read this far so something must have been good. Please be kind enough to share this piece via the social media buttons on this page;
  • Browse our suite of training courses here.
If you enjoyed this, please share it together with your thoughts!

Leave a Reply