Creating Stories Flashcards
Tell stories, don’t write them
User stories are about requirements by collaboration. The stories serve as conversation starters and reminders. Benefits are better understanding of what needs to done, faster analyses, knowledge sharing, and most importantly: better solutions
Don’t worry too much about story format
As long as the story card has the key elements and stimulates a good discussion, it serves its purpose. Try different formats to get more out of the discussion. Avoid feature requests: a solution without a context. The way to avoid trouble is to describe a behaviour change as the summary. For example ‘Get a profit overview faster’, or ‘Manage deliveries more accurately’.
Describe a behaviour change
Valuable initiatives produce behaviour changes. Capture this change in user stories, try to quanify the change. Benefits are easier assessment whether a story succeeds from a business perspective, and makes stories easier to split. For example, if the behaviour change is ‘import contacts 20% faster’, offering a small subset of functionality that speeds up importing by 5% is still valuable.
Describe the system change
Describe the observable system output without going into implementation details. How will the current system change due to realizing this story? In many cases to clarify the scope we also need an ‘instead of’ clause to follow the ‘I want’.
Approach stories as survivable experiments
Stories shouldn’t be small because they need to fit into an iteration, but about how much business stakeholders want to invest in learning whether a proposed change will actually give them what they assumed. This prevents technical stories, stories that are too small to go live and stories that business sponsors don’t care about.
If you have a big chunk of work, identify underlying assumptions and think about the easiest way of proving or disproving them. Design experiments around those assumptions and turn them into user stories. Use the experiments to build up the foundation, so that the rest of the big picture can be delivered with small iterative improvements.
Example: User story asks for a new mobile app. Assumption is that mobile app draws more users. Test this by directing current users to a website that looks like a mobile app when they are on their phone.
Watch out for generic roles
A generic user role can never provide a useful context for discussion. Without considering a particular user segment, it’s impossible to decide whether the proposed solution is the right one, or if it’s just unnecessary scope creep, to effectively plan releases and measure impacts or even discuss completeness.
For internal IT or enterprise projects, try to identify the actual people who will be using the target system, and investigate how work is divided, perhaps by department.
For consumer systems, good starting points are user personae. Checklist:
1- Prior experience with action
2- Prior experience with similar products and channels
3- Relationship with company or organisation
4-Existing motivation
5- Physical, psychological or economic impediments to action
Evaluate zone of control and sphere of influence
- The zone of control includes all those things in a system that we can change on our own.
- The sphere of influence includes activities that we can impact, but can’t exercise full control over.
- The external environment includes the elements over which we have no influence.
The user need of a story (‘In order to…’) should ideally be in the sphere of influence of the delivery team, and the deliverable (‘I want…’) should ideally be in their zone of control. If a story does not fit into this pattern it should be investigated.
When the user need of a story is in the zone of control of the delivery group, the story is effectively a task without risk, which should raise alarm bells. There are three common scenarios: The story might be fake, micro-story or misleading.
When the deliverable is outside the zone of control of the delivery team, there are two common situations: the expectation is completely unrealistic, or the story is not completely actionable by the delivery group.
If a story does not fit into the expected pattern, raise the alarm early and consider re-writing it. Throw out or replace fake and misleading stories. Micro-stories aren’t necessarily bad, but going so deep into detail is probably an overkill for anything apart from short-term plans. If you discover microstories on medium-term or long-term plans, it’s probably better to replace a whole group of related stories with one larger item.
If you discover stories that are only partially actionable by your team, consider splitting them into a part that is actionable by the delivery group, and a part that needs management intervention or coordination.
Fake stories
Stories about the needs of delivery team members. For example, ‘As a QA, in order to test faster, I want the database server restarts to be automated’.
Micro-stories
what you get when a large business story is broken down into very small pieces, so that some small parts no longer carry any risk – they are effectively stepping stones to something larger.
Such stories are OK, but it’s important to track the whole hierarchy and measure the success of the micro-stories based on the success of the larger piece.
If the combination of all those smaller pieces still fails to achieve the business objective, it might be worth taking the whole hierarchy out or revisiting the larger piece.
Misleading stories
describe a solution and not the real user need.
Put a ‘best before’ date on stories
A clear expiry date allows teams to manage time-constrained stories before they become urgent. This reduces emergencies, context switching, technical debt and allows the teams to handle real emergencies more effectively.
The most important action is to ask about potential deadlines and clearly specify them when items come into the plan. It is also a very good idea to mark those items visually so that they can be identified quickly.
Don’t aim to put a best before date on all stories, otherwise everything can become an emergency. Keep this only for stories with a genuine timing constraint, so you can manage them differently from the others. Teams with many stakeholders will probably find it useful to limit the number of stories with an expiry date, either as a percentage of the active backlog or the total number.
