In an agile environment, we split our work down into what we call “stories”, that are the smallest unit of value passing through a workstream. Unfortunately, we have a tendency to over-complicate story writing, making it unnecessarily hard. Done well, it can be a simple process of taking small steps, repeatedly.
A story is the smallest piece of value passing through your workflow.
A story MUST be valuable (to someone who isn’t us) and SHOULD be small. If we have to make a trade-off between those two, valuable must win.
Does this mean that absolutely everything we do has to be valuable for someone else and that we can’t do something that only benefits us? Not at all. Improvement activities, like those that would come out of a retrospective, are an excellent example of things that are only for us. Those are tasks, however, not stories, and we should make them obviously different from things that are valuable. If it turns out that we’re doing a lot of things that are only valuable to us then at some point someone will question why they keep funding us.
Tasks have value for only us; stories have value for someone who isn’t us.
Many teams struggle with the notion of value. How would I know if a thing is valuable? I like to ask the question “If we didn’t build this thing, who would be upset and why?” The “who” is our customer and the “why” is our value.
What if the answer is “nobody would be upset if we didn’t build it”? Then don’t build it. It’s really that simple. If the next statement is “but we have to” (as I frequently hear) then clearly someone would be upset if we didn’t build it. Figure out who that person is and why they care. All too often we build things that nobody actually cares about and that are a complete waste. We do it because promises were made or people didn’t think through things clearly enough, or “we’ve always done it this way before”. Building things that have no value, wastes time and money that could be better spent on things that are valuable.
Saying yes to one thing means saying no to many other things. Prioritize aggressively and build only those things that have value.
We’ve talked a lot about value, what about small?
Saying that stories are valuable is a bit of a misnomer. They’re items of potential value but they can’t actually be valuable until they’re finished and in use. In fact, we won’t even know if they are valuable until they’re in use. When the items are small, it allows us to finish them faster and therefore get feedback sooner about whether or not they truly were valuable.
We want stories to be small so we get feedback sooner and learn earlier whether they really were valuable. Everything revolves around value.
All too often, teams will prioritize size over value. They’ll slice the work so that it fits in some arbitrary time-box and when that happens, we aren’t getting the feedback, and aren’t getting the value and all we’ve really done is optimized for busyness, not effectiveness. We need to stop that.
What about INVEST? You’ve probably heard of the INVEST model (Independent, Negotiable, Valuable, Estimable, Small, Testable). While there are many good ideas in this model, I find it too confusing for newer teams so I don’t recommend it. INVEST gives the teams six different levers to adjust and no guidance on how to make effective trade-off decisions between them.
How do we craft good stories? Start with an idea. We think we should do X. Then ask if it’s valuable to all on its own or if it’s just a stepping stone towards something valuable. If it’s a stepping stone then keep adding to it until it’s large enough that it is valuable. At least, we think it will be valuable - it’s still an experiment at this point.
Then when we have something that we believe is valuable, consider how big it is. If it’s large then we want to see if there’s some way we could split off smaller pieces of that, that would be individually valuable. If we can split into smaller valuable pieces, then we should.
Often we see teams that don’t know how to split a story any smaller without losing value but they want to split it anyway just because they’ve decided it’s too big. If it can’t be made any smaller without losing value then that’s how big it needs to be.
Don’t split a story just to make it smaller, unless all the smaller pieces are also valuable.
Tips for decomposing large stories into smaller ones:
- See Example Mapping, a structured technique for splitting.
- Although it’s often hard to see how to split a large item into smaller items when we’re first starting, by the time we’re done, it’s usually obvious how we could have done it. Make a practice of reflecting on large items when they’re done to see how you could have split it. Take those lessons into the next story slicing work you do. You will improve with practice.
To recap:
- A story is the smallest piece of value passing through your workflow.
- Stories must be valuable and should be small.
- If you’re not sure if there’s value, ask “If we didn’t build this, who would care and why?”
- If the thing we’re looking at isn’t valuable on its own then ask “What would we have to add to make it valuable”
- If the thing we’re looking at is valuable but is large then ask “Could it be smaller and still be valuable”.
- Repeat.