Please enable JavaScript.
Coggle requires JavaScript to display documents.
Fifty Quick Ideas to Improve your User Stories authors: Gojko Adzic…
Fifty Quick Ideas to Improve
your User Stories
authors: Gojko Adzic and David Evans
Creating Stories
Tell stories, don’t write them
pain
stories with a ton of detail written down
by business representatives
Organisations with such a process
won’t get the full benefits of iterative delivery
solution
requirements by collaboration
discussion between business stakeholders and delivery teams often leads to good questions, options and product ideas
frequent involvement and discussions
Don’t worry too much about story format
pain
user stories are discussion reminders that have served their purpose after a conversation. So the standardisation argument does not really apply here.
solution
experiment with different formats to see if something new comes out during discussion
Think about more than one stakeholder who would be interested in the item – this opens up options for splitting the story. And not just one as Connextra standard suggest (As a ... )
Ask a question as user story declaration
WHY: User Stories should
Describe a behaviour change
pain
implicitly assume that something has value just because business users are asking for it
value of software is a vague and esoteric concept in the domain of business users
task size is under the control of a delivery team, so many teams end up choosing size over value
technical stories
stories that don’t really produce any outcome
INDIPENDENT and VALUABLE are often difficult to reconcile with SMALL
cit. INVEST (Bill Wake's) set of user story characteristics
solution
valuable initiatives produce an observable change in someone’s way of working
cit. Systems Thinking in Human Resource Development (Robert Brinkerhoff)
it’s not enough to describe just someone’s behaviour, but we should aim to describe a change in that behaviour instead.
useful with user stories that have an overly generic value statement, or where the value statement is missing.
HOW: Describe the system change
pain
every story should describe a behaviour change that represents the business value (the ‘why’) of the story
it should also be clear about the change a team needs to make to software (the ‘what’) in order to bring about or enable
that change in user behaviour
the exact nature of what should be changed in the system might be a matter of choice between several design options
solution
differ between now and when the story is implemented
system functionalities
business rules
this is not about specifying implementation details in the story, just the difference in observable system outputs
Approach stories as survivable experiments
pain
teams primarily aim to create something small, instead of something valuable
small chunks of work that can be implemented within an iteration
business users not really caring about individual stories, and waiting for a larger batch of work to be ready for testing
linear plans rarely work due to influences beyond our control (uncertainty)
cit. Adapt (Tim Harford)
users can often decide whether to use
technical or business dependencies can make a solution incomplete
changes in external circumstances and third party systems can make a proposed solution invalid or
obsolete
solution
treat plans as series of survivable experiments
cit. Adapt (Tim Harford)
Stories are based on assumptions about business value, and those assumptions might turn out to be right or wrong
The key questions for story sizing shouldn’t be about the iteration length, but about how much business stakeholders want to invest in learning whether a proposed change will actually give them what they assumed
Watch out for generic role
pain
purely focusing on how to build something
solution
consider how their products will be used
identify and describe user segments that will help you facilitate productive discussion of needs and solutions.
persona checklist
cit. Designing for Behavior Change (Stephen Wendel)
Prior experience with action
action: activity that is assisted or managed by the software product, which maps to the benefit of a story (‘in order to…’)
Prior experience with similar products and channels
Relationship with company or organization
Extisting motivation
Physical, psychological or economic impediments to action
group users by common behaviours
cit. Anatomy of a Live Music Fan (BandsInTown)
Evaluate zone of control and sphere of influence
"areas of systems"
cit. The Logical Thinking Process (H. William Dettmer)
Zone of Control
things in a system that we can change on our own
Sphere of Influence
activities that we can impact, but can’t exercise full control over
External Environment
elements over which we have no influence
solution
A good guideline is that the
user need of a story (‘In order to…’) should ideally be in the sphere of influence of the delivery team
the deliverable (‘I want…’) should ideally be in their zone of control
pains
user need of a story is in the
zone of control of the delivery group
The story might be fake
needs of delivery team members
es. "as a QA, in order to test faster, ... "
misleading
solution and not the real user need
es. "As a back-office operator, in order to run reports faster, I want the customer reporting database queries to be optimised"
micro-story
large business story is broken down into very small pieces, so that some small parts no longer carry any risk
they are OK on short-term plans
track the whole hierarchy
measure the success of the larger story
deliverable is outside the
zone of control of the delivery team
the expectation is completely unrealistic
the story is not completely actionable
by the delivery group
involvement of an external specialist
Planning with Stories
Set deadlines for addressing major risks
pain
Small, easy wins always get prioritised over difficult tasks
by business stakeholders
solution
set explicit deadlines for addressing major risks at a sustainable pace
alternating between ‘paying to learn’ (addressing major risks and reduce them) and ‘paying to get business value’
cit. Alistar Cockburn
In the earlier stages of the projects, the focus is much more on reducing risks than on building value, where in the later stages the focus changes
Use hierarchical backlogs
pain
story card hell
when you have 300 story cards and you have to keep track of them all… When you have 300 cards, you lose the ability to understand what they mean
is dangerous because it provides an illusion that the process is working iteratively, whereas in fact the teams are following a detailed plan set months ago
wastes a horrible amount of time tracking and managing unnecessary items
It becomes very difficult to challenge the value and goal of individual items in such a big pile
When market opportunities change the business stakeholders are faced with a serious dilemma: Aligning the plan to meet the changed circumstances
The story card hell problem starts when a team only has one level of abstraction in their backlog – when the backlog becomes linear by breaking big items into smaller.
solution
divide your plan into several tiers
the team to plan iterative delivery and divide work into small independent items
the business stakeholders to plan and monitor larger business impacts
hierarchical backlog provides visibility and transparency, removing the need to detail all levels of hierarchy at the start
example in 4 levels
big-picture business objective
smaller-scale business change that
might contribute to that big picture
software deliverables
smaller deliverable slices that we could ship independently
avoid breaking down a higher-level item until you complete all the relevant lower-level stories for the previous higher-level item
"A sure way to lose the asteroids game is to break up all the big rocks early. This produces a ton of small asteroids flying all over the place, and makes it impossible for the pilot to navigate without crashing. The way to win is to pick off one large asteroid at a time, keeping the number of midsize asteroids on the screen low enough to be able to navigate, and to vaporise
smaller asteroids as soon as they form"
cit. Jeff Patton
Keep the number of items in each tier relatively small – no more than what’s immediately needed for further planning and delivery
Group stories by impact
pain
organising hierarchical backlogs
solution
impact maps
first level of the mind map is the business goal for a milestone of a project
second level of the mind map contains user segments, stakeholders or actors who will be involved in achieving the goal
third level of the map shows the impacts on users and stakeholders that can contribute to the business
goal, or that could hinder achieving the objective
fourth level of the map is for the deliverables – user stories or even larger deliverables (such as epics) that
can cause the impacts
visually present the information held in the Connextra card format
When an impact is on the map, a stakeholder has an assumption that the change in customer behaviour will lead to the overall business objective.This allows teams to design tests to validate or disprove assumptions
cit. Impact Mapping (Gojko)
Create a user story map
cit. User Story Mapping (Jeff Patton)
The idea came from the
customer journey maps
used in
interaction design
how to make it work
identify the backbone of the story map
– the horizontal axis
Break down activities into high-level steps
steps should not imply a
particular technology or a solution
For example, discovering an interesting book is a step in a purchasing activity that does not imply a solution.
Getting book recommendations from a social network is not a key step – instead, it’s just one way to discover interesting books
identify options for stories
move items vertically to plan releases
Change behaviours using
the CREATE funnel
cit. Designing for Behavior Change (Stephen Wendel)
all five preconditions need to be met for execution. As in most funnel models, people can drop off from the journey at
each stage
Cue
: the possibility of action needs to cross the person’s mind
change cues slightly to reduce the chance of users ignoring them
create associations between user’s existing work tasks, routines or habits and the product
avoid concurrent cues that seek actions.
Reaction
: the person automatically and intuitively reacts to the idea in a fraction of a second, generating an emotional response
build up trust
improve initial usage experiences.
Evaluation
: the person thinks about the action consciously, evaluating the costs and benefits
help users build habits that will make them skip the evaluation and timing parts of the funnel
Support the user’s conscious decision to act
making tasks easier to accomplish or understand
automating repetition or defaulting actions
remove friction
Ability
: the person evaluates whether the action is feasible given the current context
provide clear guides and action plans
provide small wins
reduce risk of failure
Timing
: the person judges whether they should act now or later
use time-sensitive content
encourage early commitments
align with an event that provides urgency
key benefits
can help you create a non-linear, hierarchical backlog
Stakeholders can first choose the target persona for the current milestone, then the behaviour they want to influence, and this pretty much helps you nail down one funnel to work on
splitting stories
If a story is too big and it tries to influence several parts of the funnel, we can split it into several stories that address individual parts
Set out global concerns at the start of a milestone
pain
User stories are not particularly well suited for addressing global cross-cutting concerns such as capacity, performance and security
User stories generally bring small iterative enhancements
solution
to have a separate discussion about global concerns once per milestone
facilitating such conversations through a
FURPS+
mind map
functionality
usability
reliability
performance
supportability
+
global items that don’t fall into any of the five categories
implementation constraints
resource limitations
interface constraints
operational requirements
licensing requirements
Prioritise according to stages of growth
cit. Lean Analytics (Alistair Croll and Benjamin Yoskovitz)
framework for prioritising user stories
Empathy
: figuring out how to solve a real problem in a way that people will pay for
Stickiness
: building the right product to keep users around
Virality
: growing the user base organically and artificially
Revenue
: establishing a sustainable, scalable business model with the right margins in a healthy ecosystem
Scale
: growing the business
pain
Teams working on new product development often struggle to align stakeholder priorities
stories aimed to improve short-term revenue
preparing for long-term sustainability (or sometimes world domination)
marketing initiatives that immediately bring new users
At each stage, the delivery team should focus on addressing a particular set of risks, by tracking the right measurements and setting concrete objectives
User stories need to follow that focus
choose the objectives for the current stage and identify some quantifiable target metrics which will tell the group that the product is exiting one stage and entering another
Prioritise using purpose alignment
pain
most of the items in MoSCoW model end up in the Must have category. Lots of teams suffer from the priority one paradox: the more stakeholders are pressed to identify highest priority items, the more scared they are to leave anything out of that category
Without using a model such as this one, most of the work is often devoted to creating complex versions of ‘must have’ items, even if they could in reality just be good enough
solution
cit. Stand Back and Deliver (Niel Nickolaisen)
two questions for each item
Is it mission critical? (Can the business run without it?)
Is it market differentiating? (Does it bring customers, provide competitive advantage or something similar?)
Once these questions have been answered, items can end up in one of four categories
Differentiating
: both mission critical and market differentiating. This is the area where organisations should focus most of their investment. For such items, good just isn’t enough,
excellence is required
.
Parity
: mission critical, but not market differentiating. These are things that have to be done, but they can just be good enough. Making them significantly better than the competition is an over-investment.
candidate for off-the-shelf solutions, outsourcing, or just doing the simplest thing that could possibly work
Partner
: market-differentiating opportunities that aren’t mission critical, for example opening up an experimental sales channel using mobile devices.
often don’t have off-the-shelf solutions, but the organisation doesn’t have internal expertise, so it makes sense to partner with someone else who has that knowledge
Who cares
: ideas that aren’t mission critical or market differentiating.
Make a stakeholder chart
solution
complement user personae with some kind of large-scale stakeholder analysis
It typically takes 30 minutes to an hour, and it should ideally involve the entire team.
starting with the following questions
Who will be impacted by the project?
Who will be responsible or accountable for the project?
The
accountable
person is the individual who is ultimately answerable for the activity or decision. This includes
“yes” or “no” authority and veto power
. Only one accountable person can be assigned to an action.
The
responsible
person is the individual(s) who
actually complete the task
. The responsible person is responsible for action/implementation. Responsibility can be shared. The degree of responsibility is determined by the individual with the “accountability."
Who will have decision authority on the project?
Who can support the project?
Who can obstruct the project?
Who has been involved in this type of project in the past?
groups stakeholders
how important your product or initiative is to a stakeholder
(interest)
how much ability they have to bring about their preference about a topic
(power)
strategies for each stakeholder group
High interest, low power
: keep informed and encourage detailed feedback. Subject-matter experts often fall into this category. Although this group does not have a lot of power, they might involve more influential groups if they feel that their concerns are being ignored or their interests are in danger.
Low interest, high power
: engage infrequently to understand and satisfy large-scale needs. Involve in milestone activities, such as creating or reviewing business goals and impact maps.
High interest, high power
: work closely with these people, engaging them fully and ideally making them part of the delivery group.
Low interest, low power
: provide general information and monitor them, to make sure their interest or power does not change during delivery, but do not bore them.
pain
Many teams find themselves in a tight spot by ignoring
stakeholders who only function at the big-picture level
, such as people involved in corporate politics and external regulators
Name your milestones
pain
Milestones often get technical or generic names, such as ‘Release 1.1’, ‘Beta’, or ‘MVP’
makes it difficult to create effective plans
solution
Identifying stories within business milestones
helps connect the work being done at the coalface with the higher-level objectives
essential for engaging stakeholders in practical discussions about the details of what belongs inside or outside the scope of each
milestone
name a milestone according to the capability represented by the set of stories included in it
es.
Mobile users can buy concert tickets
Don’t confuse milestones with epics
True epics are simply large stories that satisfy all the other INVEST criteria but are too large to be implemented in a
single iteration
Milestones, therefore, should describe noteworthy points where a cohesive product increment could be delivered.
including stories that bring improvements in many different areas,
providing a balance of features
across your product’s end-to-end capabilities
It can also mean including the juiciest slices of several epics,
Focus milestones on a limited number of user segments
pain
plans based on user stories often turn into streams of consciousness
people first come up with a deliverable (‘I want…’) and then justify it with a plausible excuse (‘In order to…’). They invent a user segment (‘As a…’) at the end, without a lot of thought
system component (‘As an LDAP server…’)
completely generic user segment (‘As a user…’)
Working with user personae can help
solution
try to limit the number of user segments targeted in a particular milestone
prevents stakeholders from constantly inventing new user roles
At the start of each milestone, let stakeholders pick target segments first
Discussing Stories
Use low-tech for story conversations
Imagine the demostration
when the team is discussing a story, in the context of understanding the acceptance criteria or exploring key examples, start by asking the question, ‘How will we demonstrate this story?’
Involve all roles in the discussion
pain
involving an entire team in story discussions isn’t practical or useful
delegate the task of analysing a story to just one person
solution
create small conversations that involve at least one person representing each of the
development
,
testing
and
analysis
roles
ref Specification by Example (Gojko)
ref Agile Testing (Janet Gregory and Lisa Crispin)
start with the analyst or business representative introducing a story and presenting a few initial scenarios
Then the developer considers the story in the context of the existing infrastructure and probes for potential functional
gaps and inconsistencies
tester then considers how the story might be tested and applies testing heuristics to identify scenarios that the others have not
considered
Divide responsibility for defining stories
pain
expect business stakeholders to fully define the scope
bad design decisions
buggy
technical debts
ref What Customer Want (Anthony Ulwick)
product owner or XP customer should be responsible for deciding what the team will work on. But deciding isn’t the same
as defining
solution
Get business stakeholders (sponsors, XP customer, product owners…) to specify only the ‘In order to…,’ and ‘As a …, ‘ parts of a user story
Get the delivery group (team) to propose several options for ‘I want…’
Both sides together evaluate the options and the business stakeholders decide which one will be implemented
Discuss sliding-scale measurements with QUPER
pain
features that together provide value on a sliding scale
non-functional
performance
capacity
startup times
operational responses
aren’t related to the presence or absence of a particular feature
solution
QUPER model
QUality
PERformance
visualises and exposes two types of information about the market need and the proposed architectural solutions
Breakpoints
are thresholds of usefulness for a particular aspect of a system.
The
utility
breakpoint is the point where a product moves from useless to usable.
Differentiation
is where an aspect of the product becomes a competitive advantage.
Saturation
is a point after which any improvements are an overkill, and make no real difference to users.
they do not depend on the actual solution, but on the market
expected user needs and the competition
use breakpoints to start a discussion on which area of the model the solution needs to fit into, and define targets for different stories, releases or even phases of a project.
relationship of cost to benefit of potential architectural solutions is similar to an S-curve
initial investment required to get any value (startup costs)
then the benefits scale with low investment
beyond some point the chosen solution no longer applies, and a large investment is required to get more value
to get more value – either a rewrite or a major change to the architecture
Splitting Stories
starts with the output
ref. Chris Matts
the value of an IT system is mostly in the output
it produces
Instead of thinking about workflows linearly, think about the outputs first
es. instead of thinking about login screen
think about reports
build up the capability
to produce these outputs incrementally
Split learning from earning
pain
Without knowing at least roughly what needs to be done, nobody can accurately predict how long it will take to implemen
solution
Learning stories
help stakeholders plan better
The goal should be valuable to a stakeholder and providing enough information so they can make a planning decision
decide how much time the stakeholders want to invest in getting the information – effectively time-boxing the learning story
split the research tasks into a separate story with a goal of its own
Earning stories
help to deliver value to end-users
