 | The Story |
A story is the break-down of a product into functional, “build-sized” pieces
Of all product or scrum backlog items, stories are arguably the key building block from which all others are derived. They represent the smallest stand-alone process that a user can execute when interacting with a product feature. This could be, for example, the workflow of a single button, by which a user completes a simple action.
Basic Format
Stories typically have the following syntax:
- As a <role>
- I want <some goal>
- So that: <some reason>
- And I know I am done when: <acceptance criterion>
A good story is a …
Conversation Starter
A story is the frame for a conversation between the PO and Dev Team. The PO designs the story with the Sprint Planning session in mind. The story takes into account all the functionalities that the product needs to have from a user perspective, while giving the Dev Team what they need to know to determine how to create those functionalities from a technical standpoint and how “difficult” or “complex” the process will be.
Features
Stories must include the following:
- A description of the essential functional elements with no more detail than appropriate. This must be done in non-technical terms and from the user’s point of view
- An estimate of how much “effort” will be needed to complete them. The development team must be able to comprehend what is to be built and how “complex” the process will be. This allows for an estimation of how long each story will take to build and therefore how long it will take to complete all stories in an entire product
- An estimate of the value they will ultimately yield for the overall product (i.e., “business value”)
- Requirements for what is necessary for the item to be considered complete (i.e., built completely, and function successfully and consistently).
- The item’s ordering in the backlog based on its priority
Important: a good story tells the Dev Team what functionalities to built, but not how to build them.
I.N.V.E.S.T. Criteria
The following criteria have come to be accepted as key in creating effective user stories. Stories should be:
- “I” ndependent (of all others)
- “N” egotiable (not a specific contract for features)
- “V” aluable (or vertical)
- “E” stimable (to a good approximation)
- “S” mall (so as to fit within an iteration)
- “T” estable (in principle, even if there isn’t a test for it yet)
Borrowed from agilealliance.org
Detail
A story is a marker along the trajectory of a product build. It marks a point in the future that the build may cross. A good product vision lays out a pathway for how a product will be developed (hence the milestones), but it remains flexible and open to adjustment. For this reason, it is important to have clear markers but not to over-commit or over-specify those markers. Stories should be well-detailed when they will be included in upcoming builds, but only roughly marked out with minimum detail when they are still a long way from development.
Scale
Stories should be as small and simple as they can practically be. Less complexity means
- more accurate estimation
- greater clarity and continuity of understanding across the team
- higher chance of their being build successfully, completely, and on time
Perspective
User stories (usually) describe functionalities from a product user, or client perspective. In an Agile-based framework, the focus is on the end user whenever possible. During the build, there will doubtless be times when stories must contain or embody technical requirements. For these situations, there exists an array of items to choose from (see tasks, spikes, bugs, and tests).
Important: story criteria tell the Dev Team what functionalities must be built, but they do not over-specify how they must be built.
Scope
To build a complete product, there will often be items and tasks that are bigger or smaller than a story.
Bigger
There may often be complex features that are too big to build as a single story but need to be built together and function as a unit. We will address these in the next subsection: Epics & Themes.
Smaller
There are also tasks or to-do items that don’t constitute a story but still need to be tackled systematically. We will address those in the upcoming subsection: Tasks, Bugs, Tests & Spikes.
Typical Layout
