Discussing Stories Flashcards
Use low-tech for story conversations
It’s important to record the results of a conversation, but that can
be postponed. With fewer distractions, discussions around whiteboards are
faster and more productive than discussions around a technical tool.
Imagine the demonstration
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?’ This results in a shared vision
Diverge and merge for story discussions
Our preferred way of facilitating story discussions for teams of 10 to 20
people is to split the team into several smaller groups, get groups to capture
their understanding of a story using examples, then bring the groups together to
compare results.
Involve all roles in the discussion
create small conversations that involve at least one
person representing each of the development, testing and analysis roles. A common name for such conversations is three amigos
The typical way to run a three-amigo meeting is to…
start with the analyst or business representative introducing a story and presenting a few initial
scenarios of how they would see a story working.
Then the developer considers the story in the context of the existing infrastructure and probes for potential functional gaps and inconsistencies.
The tester then considers how the story might be tested and applies testing heuristics to identify scenarios that the others have not considered.
The discussion continues until everyone is happy
that they have enough information to start working and that all major risks have been covered.
Measure alignment using feedback exercises
A feedback exercise is a very quick and effective way to measure whether a group is ready to move on after discussing a story.
Someone (typically a tester) comes up with a difficult boundary condition based on the results of the story
conversation. Instead of discussing the condition, everyone individually writes down the expected outcome. Everyone shows their answers at the same time, and if they all wrote down the same thing, that’s a pretty good sign of group alignment.
If people have different answers, then the group is not yet aligned, and they should discuss the different opinions and try to understand the root cause of the misunderstanding.
Play the devil’s advocate
challenge the perceived need addressed by a user
story. Try challenging several aspects of the story:
- Argue that the target user doesn’t really have the need (I don’t want to login)
- Argue that the target user segment is wrong (someone else wants endusers to do that)
- Argue that the proposed solution is wrong (delivering the solution will not provide the benefit)
Divide responsibility for defining stories
Getting business stakeholders to design solutions wasn’t the original intention of user stories – but many teams have fallen into this trap.
Fix it by:
1. 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
Split business and technical discussions
Discuss business needs and divide stories according to value with business users, then let them go and do their day job while the delivery team looks at stories from a technical perspective.
Investigate value on multiple levels
To get the most out of stories, think about several levels of value, and try to identify through discussion whether there is a story within a story. If you end up arguing about which value statement to choose, just list several of them and capture the whole chain of reasoning. Then invest the time you saved into the actual discussion about the story, instead of wasting it on wording.
Discuss sliding-scale measurements with
QUPER (what is QUPER?)
The QUPER (QUality PERformance) model visualises and exposes two types of information about the market need and the proposed architectural solutions: breakpoints and barriers.
QUPER: Breakpoints are thresholds of usefulness for a particular aspect of a system.
The model requires stakeholders to identify three particular breakpoints:
1- The utility breakpoint is the point where a product moves from useless to usable.
2- Differentiation is where an aspect of the product becomes a competitive advantage.
3- Saturation is a point after which any improvements are an overkill, and make no real difference to users.
