Story Shaping

Good user stories don't just get written down, they're being shaped. Iteratively. Together with the team to build up a common understanding.

How NOT to use it

Fill it in one go
Do it on your own
Hand over the “finished” story to the team without their involvement in shaping it.

Template (it’s not really a template, but anyway…)

Story Title (Jira calls this Summary)

This shouldn’t be a description of implementation details (implement login) but rather a concise summary of outcomes from a user perspective (existing user can authenticate with their credentials).

Motivation/Background

Describe the overall context or problem to solve here. Don’t purely focus on the user perspective. Also give information relevant to the business.

This section is the place where you outline motivation for major changes as well as introducing new functionality.

If it’s helpful, use the following template to summarise.

As <persona>,
I want <what>
so that <why>.

Hypothesis

Especially for when you are in an exploratory, complex and uncertain phase you need hypotheses

“Hypothesis-Driven Development is a great opportunity to test what you think the problem is before you work on the solution." - Barry O'Reilly

We believe <this capability>
Will result in a <this outcome>
We Will Have Confidence To Proceed When <we see a measurable signal>

Solution Idea

Capture possible solutions to the stated problem. Focus on a broad strokes description from the user’s perspective. Also mention the rough flow of information/data between the systems. Every approach might have its own tradeoffs, take a note of them as well. This has to be aligned with the hypothesis that has been formulated.

Acceptance Criteria

After a couple of rounds of discussing a story the team will hopefully converge to a shared understanding of the problem and the solution. This is the time to capture a list of things that describe the functionality in a way that they can be checked off without doubt or discussion. That’s the Confirmation in the three Cs.

Anti-patterns of Acceptance Criteria

List implementation steps
Detailed description of click paths
Specifying pixel values

Only later move to the BDD-style template

Given <preconditions>
When <key action>
Then <expected result>

Out of scope

List of features/functionality/behaviour that is explicitly excluded. Include a reference to the stories which aim to implement the excluded stuff.

Design

This is the place for

Sketches
Wireframes
Prototypes
links to Zeplin

Open Questions

“Writing stories” as it self is not useful. The goal shouldn’t be to have a perfect write-up but rather to document the conversations.

Capture questions that come up while reflecting, summarising, editing, discussing this story. There is a good chance that during a refinement session questions cannot be answered by the people who are in the discussion. Capture everything that has to be clarified, questions as well as risky assumptions. A a story can be considered Ready for Development if there are no questions left that would impact the scope or the feasibility.

Task Breakdown

Once that the problem is well enough understood and a solution has been decided upon, with a solid discussion of risks, dependencies and in/out of scope decisions being made it’s time to break it down into development tasks. This is done when a pair picks up the story, not before.

The following list is not complete but should serve as good starting point.

what are the UI parts
- non-trivial UI interactions? Do we need to check for cross-browser compatibility?
- which data/state is handled in the UI
what are the backend parts that need to be
- modified/extended
- created
which data is exchanged between
- backend and frontend
- external systems
changes to CI/CD pipeline needed
dependencies to other teams
Feature Toggles: if yes, which and where 
do we have something similar already in our apps? How much effort would it be to re-use it?
Is the quality of existing code and tests sufficient to be able to work off it?
which tests on what level
testdata sufficient? 
are secrets involved
which kind of data are we dealing with?
- GDPR relevant
- what are we sending to the user
- which inputs do we need to validate 
logging
metrics
alerting
tracking
performance implications (call to external services, calls per page load,…) 
do we need to add a new technology/architecture pattern?
do we need to add a new library (does it do what we want, do we really need it, is it maintained, are we using something similar already, license ok, open security issues, …)
documentation (existing and new)
is this covered in our Architectural Decision Records

framegrabber/Story Shaping.md