Rather than breaking the story into tasks or acceptance tests, some teams simply break stories into multiple, smaller stories until they are small enough to build from.
So, for example the story:
As an Iphone user I want to SMS my friends to that I can share my experiences with them
Might be broken into:
As … I want to select a contact to SMS from the phone book so I can send an SMS
As … I want to be able to type a phone number so that I can send and SMS
As … I want to be able to type text to include in an SMS
I often tell people to break their stories down until they are less than half an iteration’s work because that is my rule of thumb for when stories will become unwieldy. But others advise that no story should be more than 1-3 days work.
However, it is important to realise that this does not mean all stories must be broken down to be this small at the beginning of the project. Rather, they can be broken down just before the team use them to build and test their system or other solution.
Since the stories are on the verge of being build, many teams abandon the “As a … I want to … so that …” format. And they call these stories “technical stories” to differentiate them from the larger ones they used for planning. They might even use a different colour card to highlight technical stories on a story wall.
Many teams simply write technical stories as comments or reminders, along the lines of “look up contacts”, or “add lookup”.
But I think it is worth keeping to a standard format agreed by the team. For example:
- “Trigger (who or what triggers an event); event; condition, input needed; output created; constraints; errors:
- When the user selects contacts, the system displays the contacts if there are any. No input is needed and the system will display the phone book;
- “System” must “condition”:
- The screen must comply with branding standards; or
- Information displayed must be accessible to reader programs; and
- Use Cases:
- Many people think that Use Cases are “very 90’s” and thus quite unfashionable, but they do work well with agile approaches.
- I will not describe Use Cases here but they can be used for elaboration by simply treating the stories as use case goals and then expanding the Use Case as required when building and testing.
Watch out for
There is a high risk with this approach that you will trap the team in “panic driven waterfall”. This means that the BA’s will not have enough time to write proper requirements and at the same time the developers will expect ever more detailed requirements before building.
So I suggest that you
- Make sure the creation of the detailed stories is the role of the whole team and not just the BA;
- Keep reminding the team that these detailed stories should only be added where they provide more clarity or better tracking than a conversation; and
- Keep defaulting to acceptance tests and pictures rather than creating new stories if the new story will represent less than a day’s work.
There is also a substantial risk with this approach that it will lead to scope creep.
The team might be quite disciplined up until they elaborate their stories, even carefully prioritising and estimating stories diligently.
But then as they start to write their technical stories the stories become an un-prioritised list of possible things the story could relate to and the team feel trapped into delivering all of those components, even though none of them is prioritised.
So it is a good idea to use MOSCOW or another prioritisation approach to handle the technical stories if you need to, but a better approach is to write less of these stories. Keep reminding the team that the technical stories are not new requirements, they are simply a clarification of the stories, and use conversation instead of “detailed requirements” where-ever possible.
Finally, I recommend tracking the technical stories as sub-components of the original user stories rather than losing sight of which user need (story) the technical story relates to.