Many user stories fit the model of trigger and response: the user does something, the system responds. For example, if you type a letter, the word processor inserts it; if you press the “Buy” button, the system processes your order.
When stories are too big, we split them. There are many choices for how to split. Is trigger vs response a good one?
Trigger-Response? No, but…
While it’s possible to split many stories that way, splitting trigger from response is a weak split.
Splitting trigger from response is a weak split.
The problem is, these tiny stories are (usually) not valuable standing alone: if you want one, you want the other too — mutual dependency. No user would pick “User presses key” for this release, and hope that “System inserts character in document” is in the next one.
So, keep this split deep in your bag of tricks – only pulled out when you have no other ideas.
Instead, look for a “skinnier” version of the full story, building in both trigger and response, but making either or both do less than the full vision.
Stories at the Domain Level
Stories are sometimes written at too low a level – e.g., talking about “button press” rather than whatever the user is trying to do. It encourages us to write stories about steps in a workflow rather than something a user would find directly valuable. (And I think that tempts us to make that trigger vs response split:)
What is the user really trying to accomplish?
Write stories in the conceptual domain of the system. What is the user really trying to accomplish? That opens up negotiation and the potential for better understanding of value. And that discussion may let you trim down the work you have to do.
“System” as a Role
You may wonder if System ever makes sense as a role.
I generally use System in two situations: when extending an existing story with more system behavior, and when the system is acting asynchronously.
An example of “more behavior”: I’ve implemented the editing part of my word processor, but I’d like the system to also display the number of words in the document as the user edits.
That feature cuts across a number of stories: insert, delete, cut, paste, import, etc. Rather than adding details to each, it’s easier to just say “System displays #words in the document”.
Asynchronous Behavior
In some cases, the system behaves independently of the user. This could be triggered by a clock, an external sensor, or detecting internal conditions. It could be something that runs in parallel with user-triggered behavior.
(I’m talking about this at the system level, not cases where you use threads etc. to implement behavior that appears synchronous to a user.)
Stories like this often come in pairs or groups. For example, consider the story “User schedules notification.” The user expects a synchronous response – “Appointment is scheduled.” But there’s almost certainly another story “System sends notification” that is asynchronous, controlled by the clock.
“System” is a valuable role for these type stories.
Conclusion
“Trigger vs response” is not a first-tier splitting method. When you have to pick both stories to get something useful, it’s not really split. So avoid this split if you can.
If you write stories at the level of the user’s domain, you will probably find it easier to create smaller stories at different levels.
Finally, even though a story about “System does X” sounds like it’s splitting out the response, I do use System in a role in a couple situations: when adding existing behavior (esp. across many stories), and when describing asynchronous behavior.
References
“Twenty Ways to Split Stories” – https://xp123.com/articles/twenty-ways-to-split-stories/