As my career in software has progressed I have gone from being stumped by the concept of user stories to being able to write them myself. This is mostly due to working from user stories written by a large variety of product owners, some of which were groomed very well while others not so much. What follows are my notes from experience and distilled from Pluralsight courses.
What is a User Story?
- A user story is a single unit of work which defines what needs to be done, while deferring responsibility till the closest possible point of implementation.
- User stories are brief, all requirements are not captured upfront.
- High level to allow deferment of details till the last responsible moment
- Not detailed requirements and not set in stone to encourage interaction by all teams.
- A story is just a placeholder for a conversation
- Electronically or physically or hybrid
Archetypal User Story
As a {role},
I want to {do shit},
So that {I can accomplish a goal}.
A Role represents groups of users, not individuals where the characteristics of the group are derived as a whole. Translate the requirements into specifically segmented groups where a real need is represented vs a feature that is pulled out of someones ass.
A Persona is a fictional character that provides a backstory for a role. Not every role will have a persona. This persona is used to do relationship mapping to determine the depth and weight of each node. When creating a persona it should be lightweight; Name, Photo, Role, and a brief description that focuses what is their motivation and what they want to get out of it (the Why rather than the How of the goal). Optional: key quote, profession, and user demographics
Choosers vs Users
Who pays for the product vs who uses the product matters when it comes to development. For it is going to drive the
The INVEST Model
Good user stories meet the criteria prescribed by the acronym INVEST.
- Independent
- Negotiable
- Valuable
- Estimatable
- Small
- Testable
Types of Stories
Epics are used to breakdown the steps into separate steps which can be broken down into smaller stories and prioritized. This process will highlight gaps in the requirements. Epics are tightly coupled and need to be completed together.
Themes are used to group together stories that are related and server a similar goal. Themes are not a single workflow, which allows for them to be delivered independent of one another.
Splitting Stories
Without going into story points, a user story should be split when the estimated work or assumed requirements are growing to what would take up 60% of the iteration. When portions of the requirements become vague or unknown then the story should be split.
Getting to Done
At the end of the day all that matters is that the work that needs to be done is getting done. What this means is that very explicit exit criteria needs to be defined. If stakeholders are having trouble defining what that exit criteria is then one of three things is true: the story is too large, the stakeholders do not know what they want, or a cruel form of waterfall development is taking place deep within the 9th layer of hell.
Tools
Post-It Notes https://www.amazon.com/Post-Jaipur-Collection-Sheets-654-14AU/dp/B0002DOC68
Version One https://www.versionone.com/
Pivotal Tracker https://www.pivotaltracker.com/
Taiga https://taiga.io/
Trello https://trello.com/
Rally https://www.ca.com/us/why-ca/about-us/acquisitions/rally-is-now-ca-technologies.html
In closing, user stories are a powerful tool used for developing software. It is a way to extract requirements and narrow scope. While not every company will use user stories in the same way, it is good to have a base understanding across teams.