Splitting Stories Flashcards
Start with the outputs
the value of an IT system is mostly in the outputs it produces, and that the inputs are just means to an end. Instead of thinking about workflows linearly, think about the outputs first. Instead of thinking about the log-in screen, think about the reports. Instead of slicing the
future system by inputs, slice it by outputs, and then build up the capability to produce these outputs incrementally.
Forget the walking skeleton – put it on
crutches (explain the walking skeleton)
A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.
Forget the walking skeleton – put it on
crutches (explain the dancing skeleton)
A dancing skeleton not only delivers a small function on the target architecture, it also involves an interface for developers to interact with the environment and experiment. When the users need a more complex function, developers can make the skeleton implementation ‘dance’.
Forget the walking skeleton – put it on
crutches (explain the crutches)
The core idea of the skeleton on crutches is to ship out the user interface early, and plan for iterative deployments of everything below the user interface. The
user interaction may change very little, or not at all, while the team improves the back end through continuous delivery.
With a good deployment pipeline, back ends can be updated and reconfigured without even interrupting user flow.
Narrow down the customer segment
Don’t give everyone 2% of what they need, instead give 2% of users everything they need.
Split by examples of usefulness
Instead of slicing technical deliverables and then looking for useful chunks of value, try to start
from the opposite direction: slice value and look for useful technical chunks.
List a bunch of options for how the final technical change would be useful, and don’t worry too much if they overlap. Among these examples, look for ones
where technical delivery would be significantly reduced, where you could reuse large parts of the old system or where you would only need to provide part of the business workflow.
Split by capacity
Splitting by capacity can reduce technical complexity significantly for the first release of a product or service, yield valuable feedback early and provide value to some subgroup of users sooner.
Find a dimension where an initial cut would require only a small subset of the final architecture or where components could be significantly simplified. Make
sure to check that progressive increase in capacity would require progressive improvement in the architecture and not a complete rewrite.
Start with dummy, then move to dynamic
The real value of software is mostly in its outputs, not in its inputs. An interesting strategy for splitting stories while preserving most of the value is to avoid any work around preparing inputs at first. This particularly applies to reference data. Instead of loading such data from the official sources dynamically, split the story so that the first part uses hard-coded reference data, and subsequent stories connect the input fields to relevant data sources.
Simplify outputs
For complex enterprise systems, simplifying outputs can significantly de-risk short-term plans. Getting the right access rights and dealing with all the quirks
of legacy systems can take up a lot of time, and often involves external people with specialist knowledge or administrative privileges
Split learning from earning
Planning for time-boxed learning stories avoids research turning into vague, uncontrolled work that introduces variability. It also removes the need for research outside the regular delivery cycle, preventing long upfront analysis.
Get the team to decide on the output of a learning story before starting. What kind of information do stakeholders need for future planning? How much detail and precision do you need to provide? Will a quick-and-dirty prototype be needed to validate a solution with external users, or is a list of key risks and recommendations enough? This ensures that everyone is on the same page and helps you decide who needs to be involved in the research.
Extract basic utility
In situations where a business process has to be implemented in its entirety to be useful, a good option for splitting a story is to simplify the user interaction
to the bare minimum. Instead of usability, give users basic utility.
The goal is to first make something that enables a user to at least complete a critical task, and
then plan for making it faster, easier or require less effort later. Extracting basic utility often involves semi-automated process execution, solutions which
require careful use to avoid data inconsistency, or combining tools which require the operator to transfer data between them.
Extracting basic utility is one of the last-resort methods, so be careful to use it only when needed. It is mostly applicable in two situations: when the utility of
the underlying business process is questionable, or when there is an urgent business problem that has to be solved and users can survive with a barely
usable interface for a while.
When all else fails, slice the hamburger (explain user story hamburger)
The user story hamburger is a facilitation technique that can help teams start to think about value-oriented slices when they are stuck in thinking about technical workflows and all-or-nothing use cases. It is based on user story mapping, but instead of organising many stories into multiple releases, it organises tasks for a single large piece of work into multiple stories.
How to make a user story hamburger..
- List technical components
- Define quality attributes
- List options at different levels of quality
- Remove unsatisfactory options
- Remove options that don’t produce useful technical slices
- Choose a slice
