Better User Stories is a video course from Mike Cohn of Mountain Goat Software designed to help you with user stories in your organization.
https://www.mountaingoatsoftware.com/training/courses/better-user-stories
Below are my notes on this course.
Course Modules
- What Stories Are
- Users, User Roles and Personas
- Story Mapping and Story-Writing Workshops
- Adding Detail with Conditions of Satisfaction or Acceptance Criteria
- INVEST in Good Stories
- Splitting Stories
- Overcoming Common Problems
- Things That Are Not User Stories
What Stories Are
User story - short simple statement told from the perspective of a user.
A story can be improved with a so that clause.
Story template:
As a <type of user>,
I <want/can/need/am required to> <some goal>
so that <some reason>
Qs answered by using the template:
1. Who wants it?
2. What is it they want?
3. Why?
3Cs of a user Story
- Card
- Conversation
- Confirmation
Card
A starting point of a story.
Represents the following:
* A promise from the development team to ask questions
* A promise from the product owner to be available for clarification
* An opportunity for the product owner to avoid writing long specification documents
Conversation
Starts with a two-way promise represented by a story Card:
- from the dev team - a promise to ask Qs
- from the product owner - a promise to be available to answer Qs (As a product owner, I write just enough that the team and I have good conversation so that we can be agile.)
Confirmation
Product owner’s way of telling the team what needs to be done in order for the story to be considered complete.
- what are conditions of satisfactions
Adding detail to a user story
Multiple ways of doing it:
1. split the story into smaller stories
2. addict to a story a list of the things that a product owner expects to be true about the completed story (acceptance criteria)
A story is a pointer to a requirement
- attach additional supporting information/diagrams to the story
Users, User Roles and Personas
User role is:
- a collection of characteristic needs, interests, expectations, and behaviors in relation to a particular system
- users who share common needs, interests or behaviors
- combination of users who have enough in common that we may think of their needs as largely similar
Context, Characteristics, and Criteria
To identify user roles, consider user similarities in:
- context
- physical environment
- social environment
- domain knowledge
- proficiency (developer vs grandma)
- system access (slow vs high internet connection speed)
- characteristics
- frequency of interaction with the system
- regularity of interaction
- complexity of work performed
- the volume of work performed
- user’s mental state (using the system under stress vs not)
- criteria
- user’s main goal
- secondary goals
- ease of use
- reliability
- accuracy of results
How to Do User Role Modeling
The process will provide meaningful; insights into who the product users are, how they differ, and what functionality they need
4 Role Modeling Steps:
- Brainstorm an initial set of users roles
- done once in the beginning of the project
- the whole team is present
- fast and furious - no judgement
- Organize the initial set
- group similar roles together
- identify aggregate roles
- Consolidate
- look at each role and see if they can be combined
- rename the combined role
- Refine
- eliminate roles that are unimportant for the product
- remove roles that are too broad
Documenting a User Role Model
Outcome documents include:
- model itself - a diagram representing hierarchal relationship among user roles
- one page description for each role
Structure:
User role title
- Context (category 1)
- attribute 1.1
- description
- attribute 1.2
- description
- attribute 1.3
- description
- Characteristics (category 2)
- attribute 2.1
- description
- attribute 2.2
- description
- attribute 2.3
- description
- Criteria (category 3)
- attribute 3.1
- description
- attribute 3.2
- description
- attribute 3.3
- description
User role template link [].
Personas (Intro)
- Highly descriptive and detail archetypes representing each user role.
- user role on steroids
- it’s given a name, specific goals, attitudes, and an environment
IMPORTANT:
- If you get a persona wrong, you end up building the absolutely right product for the absolutely wrong type of person.
- Without the data to backup the details, a persona is just a guess
Create a persona when:
1. You are creating a high-consideration product.
- a product the requires a lot of thought either before a user buys it or while using it
2. You aren’t guessing at the extra detail.
- use data on users of current products
- do research on likely users of a product
- talk to actual users
- observe real users
Attributes to Consider When Creating a Persona
Consider ONLY the attributes that are important for your product.
Set of attributes to look at when defining a persona:
- Demographic (quantitative)
- age
- gender
- geography
- income level
- education
- Psychographic (qualitative)
- fears
- preferences
- attitudes
- opinions
- lifestyle
- values
Documenting a Persona
Give persona a name, you may also attach a photo, and a dd a quote from real user interviews.
Describe their:
- Demographics
- Personal
- Goals
- Skills or experience
- Fears
- Attitudes and feelings
- Environment
Persona template link [].
Decorated User Roles
User role types:
- first-class citizens
- decorated user roles (as in decorated symbols in maths)
- create by adding a descriptive introduction to a first-class citizen name, as in:
- first-time user, first-time visitor, first-time registered member
- forgetful registered member
- as a user who has completed CyQu, I can download a report
Writing User Stories for the Right User
Principles:
- do not write all stories using the role at the top of the hierarchy (aggregate role)
- use a role most likely to perform a story. This:
- prevents every story from being “As a user, …”
- puts us in the mindset of that user
- if you feel constantly compelled to write the same story for different user roles, this could be an indicator that you should rethink the user roles you have identified
- put multiple roles into the story when:
- roles are equally likely to perform the story
- roles are so different that one may be forgotten
- roles will use the functionality in slightly different ways
Story Mapping and Story-Writing
The Four Times to Write Stories
1. Whenever a new idea occurs to you
2. During iteration review meetings
3. During product backlog refinement/grooming meetings
4. During story-writing workshop - the most strategic
- attended by the whole team
- attended by important stakeholders
- being help quarterly
A Significant Objective Focuses the Scope of a Story-Writing Workshop
Define a significant objective for the quarter: an MVP or an MMF
- MVP vs MMF (Minimum Marketable Feature)
MMF - a chunk of functionality that delivers a subset of the customer’s requirements, and that s capable of returning value to the customer when released as an independent entity.
Significant objective includes:
- business objective
- user objective
Significant objective:
- provides focus
- leads to greater creativity
Story-Writing Workshop Attendees, Duration and Preparation
Important Qs:
1. Who runs the workshop?
- scrum master/coach
2. Who attends?
- product owner
- entire dev team
- stakeholders
- users/customers
3. How long does it last?
- 4-5 hours with breaks
- influenced by:
- number of participants
- whether there’s a shared vision
- whether the work is new
4. What preparation is done in advance?
- basic meeting stuff
- product should already have user roles/personas identified
- print out user roles/personas and attach them to the wall
- product owner should be ready to present the significant objective for the quarter
- sticky notes, pens, markers
The Story-Writing Workshop Agenda
5 Steps:
1. Product owner presents the significant objective
2. Discuss user roles and personas relevant to the goals of the workshop
3. Story generation - all stories that achieve the significant objective
4. Story selection - which stories will best fulfill the significant objective
5. Schedule follow-up sessions if needed
Story Mapping
Adding a second dimension (sequence/narrative) to the backlog list (usually unidirectional and prioritized from most to least important)
Story map concepts/terms:
- Narrative - a sequence of items read across the story map
- Backbone - the topmost one or two narratives
- Step - any item on the map
- Activity - a collection of steps that are performed to achieve a goal
Making Decisions with a Story Map
Story maps can help:
- identify missing functionality
- plan a release to determine an MVP
- create a product road map
Qs to ask in regards to each step:
1. What else might a user want to do?
2. What additional info might a user find helpful?
3. What could go wrong?
Adding Detail with Conditions of Satisfaction or Acceptance Criteria
Progressive Refinement - Adding Detail over Time
Stories are initially vague on purpose. They open up a conversation.
When starting a project, include large, placeholder stories for functionality you are aware will need to be built but which will not be started until well into the future. Then refine those stories into progressively smaller and smaller stories over the course of the entire project. Going through a list of stories only once at the start of a project will not be sufficient.
Progressive refinement of a story includes:
- splitting story into smaller stories
- adding details to a story
Epics and Themes
Epic - single large user story. A story that is bigger than one team can do in one iteration.
Theme - a collection of related stories.
- a story can be in two themes at the same time
Two Ways of Adding Detail to a Story
1. Ask product owner questions and split into smaller stories accordingly
2. Add tests to the stories
Both approaches are functionally equivalent. Anything that can be written as test to a story, could be written as a substory and vice versa.
When chose one over the other?
- When you have a bigger story, split it.
- When you have a small enough story already, add tests.
Condition of Satisfaction
To be considered done, a user story must fulfill the product owner’s expectations. The best way to determine those is through one or more conversations with the product owner. If team members have specific needs from a story, it is fine to meet and discuss the story with them, too, but a first step should be a conversation with the product owner.
How Much Detail Is Appropriate
Just enough detail that the team can finish the story in the iteration.
Working with a Team That Wants too Much Detail
- Product owners should not specify every small detail.
- Product owner may not be the best person to make a decision.
A Definition of Ready and Why Having One Could Be Dangerous
- A **Definition of Ready** enables a team to specify certain pre-conditions that must be fulfilled before a story is admitted into an iteration.
- Goal - prevent problems before they start.
- Each team decided on their own Definition of Ready for each story to be included into an iteration.
- Some of the rules can cause trouble and prevent the team from being agile locking it into a stage-gate flow (one thing cannot start until another thing is done).
If a Definition of Ready is needed, it will be best if it focuses on guidelines rather than hard-and-fast rules. And with a Definition of Ready, the team will need to take care to emphasize working concurrently. For example, a little coding is going on even while some design is still occurring. This avoids creating a stage-gate process in which all of one activity must be completed before ANY of the next activity can begin.
Agile teams should practice concurrent engineering in which activities overlap -> most teams should not even use the definition of ready.
INVEST in Good Stories
Attributes of a good story:
- Independent
- Negotiable
- a story opens up a conversation between product owner and dev team
- Valuable
- to customer
- to user
- to stakeholder
- Estimatable
- a story should not be too big to estimate
- if a story is not estimable today, leave it and come back to it later
- Sized appropriately or Small
- top of the backlog always contained smaller stories that are ready to go into the next iteration
- Testable
- being able to identify confirmation criteria
Splitting Stories
Why split a story?
- different priorities
- lack of time
- size - too big to be completed in one iteration
2 types of large story:
- complex - fundamentally large and cannot be split: these are rare
- compound - combines multiple user actions into one: can be split
The SPIDR Approach to Splitting Stories
- Spikes
- research activity intended to build knowledge
- timeboxed
- should only be used to remove excess uncertainty from a story -> do not overuse spikes
- Paths
- drill down to find underlying steps/paths
- Interfaces
- story that has multiple user interfaces
- Data
- split by the data handled by the story
- Rules
- look at the conditions of satisfaction and pull out any rules that make the story too big
Tracer Bullet Story
A story is a tracer bullet through a system technology stack
Advantages:
- reduce architectural risk
- easier to prioritize
- make early releases possible
Closed Stories
When splitting stories try to create a closed story
Closed story - the one that finishes with the user having achieved a meaningful goal
Three Things to Do when You Can’t Split a Story
1. Try harder
- most stories are compound rather than complex
- walk through the SPIDR approach
2. Let it take more than one iteration
3. Feel guilty
- if you allow a story to span more than one iteration, feel guilty
Overcoming Common Problems
Managing Dependencies Between Stories
Techniques for dealing with dependencies between stories:
1. Combine stories
2. Split stories as late as possible
3. Reconsider the way in which stories were split
4. Annotate stories with important dependencies
Do not document obvious dependencies
Stories with Too Much Detail
- when you first write the story, focus on WHAT the user wants to achieve and HOW they want to achieve it
- initially leave UI assumptions out
Just in time and Just enough
- developers need just enough information provided to them just in time
Spending Too Much Time Splitting Stories
If you spend too much time splitting stories, consider the following:
- assess whether stories are too detailed
- consider whether stories are small enough already
- consider changing to a longer iteration length (avoid iterations longer than 4 weeks)
Stories Involving More than One Team
- Indicate all the team need/can work on a story
- mark appropriate dependencies
Stories that Are Really Tasks
Bad habit - creating tasks that masquerade as stories
Stories vs Tasks
- story
- generally something that is worked on by more than one person
- contains multiple types of work
- task
- generally worked on by just one person
- contains single type of work
Stories that are really tasks create problems:
1. The duo not deliver value
2. They are risky
3. They lead to phased development
Not Everything Needs to Be a User Story
Nonfunctional Requirements
Requirements that have to do with operation of the system rather than its specific behaviors
Often called —ilities
- portability
- maintainability
- testability
- scalability
- usability
They are constraints on how the system is developed
Stories and Bugs
Reporting a bug and asking for a new feature is fundamentally/conceptually the same thing - a desire to introduce changes to the system
Bugs should not be written in a story syntax.
Features from Feature-Driven Development
FDD - feature driven development
- feature list = Scrum’s product backlog
- syntax: <action> the <result> <by|for|of|to> a(n) <object>
FDD feature syntax can be helpful:
- when the is no immediate user present.
- for more technical parts of the system
- for API development tasks
Job Stories
Variation on User stories
Job stories are addressing two problems identified with user stories:
- Many users have the same goal
- Users do not know the solution to their problem
Template for Job stories:
When ______ I want to ______ so I can ______ .
When to use job stories:
- When knowing a user’s motivation is more important than knowing details about the user
- When dev team members and user already talk often
Top comments (0)