User stories
Outline
- User Story Overview
User Story Overview
Key Points
- User Story describes usable increment of value
- As a [role] I want [function of value] so that [business value] - see also Mike Cohn on User Story template
- Acceptance criteria as pass/fail, so teams know “it works as intended”
- I.N.V.E.S.T.
User Story Criteria
Key Points
- Independent - minimize dependencies
- Negotiable - start with the what/why, not the how; see als AntiPattern 3
- Valuable - business value for each story
- Estimatable - clear and understood enough to be estimated
- Small - small enough to fit in a sprint, be well understood, reliably estimate, but not too small
- Testable - how are you going to test it, to validate the acceptance criteria
User Story Sizing
Key Points
- Estimating should be quick
- Relative sizing using Story Points; story points do NOT equate to hours or days
- Establish a baseline story, one the whole team understands well, and use as the sizing basis
- Planning Poker
- Estimate as a team
User Story Splitting
Patterns
- Pattern 1 - Workflow Steps, key steps in workflow as separate stories
- Pattern 2 - Compound Story, connecting words like “and” and “or” often indicate multiple stories
- Pattern 3 - Multiple Operations, key words such as “manage” can include multiple operations, each can be its own story
- Pattern 4 - Simple / Complex, lots of considerations, variations, and acceptance criteria can be split to separate stories
- Pattern 5 - Variations in Data, separate stories by state, location, product
- Pattern 6 - Defer Performance, a lot can be learned from and value earned on an initial story even if performance isn’t perfect
- Spike - resolving a specific technical question or design problem so the team can estimate a story
SPIDR Splitting
Five Simple Techniquest to split a story
- Spikes - small, prototype implementations to build knowledge; not for building technical components of a larger story
- Paths - alternative processing paths, or options
- Interface - devices or user interfaces
- Data - sub-ranges or sub-sets of data
- Rules - not all rules need to be implemented up-front; see also Anti Pattern 5
Spikes and Enablers
SAFe on Enablers From SAFe - an Enabler helps to extend the architectural runway, especially through exploration, evolving the architecture, improving infrastructure, and compliance activities where needed. They reflect real work, and are represented on the backlog like all other work, including acceptance criteria, estimation, and presentation of results.
As with other work in SAFe, Enablers can be Epics, Capabilities/Features, and even stories, and follow the same rules of each.
Enablers and Spikes are NOT for delivery of a particular subset of application code that delivers no business value on its own. Often such stories are really reflecting a particular task associated with a larger story.
Exploratory Enablers aka Spikes
These support research, prototyping, and other activities to help understand the customer needs or solution options. Any alternatives must be analyzed and evaluated through modeling, prototypes, and development of multiple solution options.
The ultimate goal of an Exploratory Enabler is to arrive at an understanding of cusotmer need or recommendation on solution direction.
Since Exploratory Enablers do not directly deliver user value, they should be used sparingly. The output of an Enabler must still be demonstrable to stakeholders, and accepted by the Product Owner when the acceptance criteria is met. SAFe on Spikes
Spikes for Research, aka Technical Spikes
Research Spikes allow for investigation of approaches in solution, examples:
- product or tool selection, including potentially buy-vs-build decision
- assessment of performance/load impact of new capabilities/features
- evaluate technical implementation approaches and options assessments
Spikes for Proof of Concept, aka Functional Spikes
Proof of Concept Spikes allow for a team to try out something new, and analyze the overall solution behavior, to determine:
- Insights to influence implementation decisions
- Risks and complexity in the solution
- How to break down and organize work to ultimately deliver the solution
##