Good user stories don't just get written down, they're being shaped. Iteratively. Together with the team to build up a common understanding.
- Fill it in one go
- Do it on your own
- Hand over the “finished” story to the team without their involvement in shaping it.
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).
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>.
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>
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.
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.
- 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>
List of features/functionality/behaviour that is explicitly excluded. Include a reference to the stories which aim to implement the excluded stuff.
This is the place for
- Sketches
- Wireframes
- Prototypes
- links to Zeplin
“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.
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
- https://barryoreilly.com/wp-content/uploads/2015/12/hdd-card.jpg
- https://martinfowler.com/bliki/GivenWhenThen.html
- https://ronjeffries.com/xprog/articles/expcardconversationconfirmation/
- http://www.jpattonassociates.com/wp-content/uploads/2015/03/story_essentials_quickref.pdf
- https://barryoreilly.com/how-to-implement-hypothesis-driven-development/
- https://basecamp.com/shapeup/webbook
Spottet a tiny typo: Missing
.after excluded here https://gist.github.com/framegrabber/9c1e5e2b094c1cc84bc8fda916be015d#out-of-scope