Resources

User Stories are NOT the same as requirements, use cases, tasks, or any other form of detailed documentation – they are mainly used for PLANNING and as such the following statement written in a classic User Story format was a plan for me to get my act together to write this article. Usually, a team of collaborative specialists come together to discuss, discard, amend, and or implement a User Story over time.

User Story Basics

The format includes the:

WHO (the user, customer, citizen, recipient of the value)
WHAT (problem or opportunity statement that needs to be solved)
WHY (the benefit to the recipient)
It is brief because it serves as a REMINDER of what is possible.

It can be part of a Product Backlog (a prioritised list of things to work on)

The User Story (amongst other work items) may be at the bottom of the list which means it will be worked on at some point in the future (Y.A.G.N.I. - You Ain’t Gonna Need It is a nudge to say work on what’s important now and don’t worry about stuff we aren’t currently concerned with) or at the top of the list which means we are about to work on it.

The User Story we are about to work on is fleshed out through conversation, collaboration, modelling, estimation and trial and error until it is implemented.

A common heuristic to guide User Story creation is Card (keep it brief, fits on a Card) Conversation (it’s emergent and open to discussion during its lifespan) Confirmation (we will get to the detail – just in time)

I.N.V.E.S.T.

I.N.V.E.S.T is another guide to keep the story as Independent as possible, Negotiable (it’s about collaboration and communication) Valuable (the recipient should be getting benefit once the story is implemented) Estimable and Small (should be small enough to be completed within a specified iteration/timebox) and Testable (we can validate it’s done when it has been completed)