At some point you need to dive into the detail.

At some point you need to dive into the detail.

A user story is a simple statement of need. A common format for a user story is “<persona> <goal> <benefit>”. Typically when a user story is initially formed it is not ready to be developed. Stories can lack detail because they don’t include acceptance criteria, might need additional detail or might to be broken down.

Acceptance criteria provide confirmation that the story does what was intended and can be used to create an acceptance test. They provide additional detail that helps the team develop an understanding of the story. I have found that acceptance criteria also provide an excellent platform for generating the conversations the user story process expects. In a perfect world acceptance criteria would be written when the story is originally developed or during backlog grooming at the latest.

As team members and stakeholders talk about user stories knowledge is generated. The knowledge that is generated can be housed in pictures, notes, wireframes, paper or functional prototypes to name a few tools in the team’s arsenal for generating a conversation and capturing that conversation. These “documents” need to be captured and linked to the story. The one attachment mechanism you do not want rely on in the long term is your memory.

Large user stories, almost by definition, lack detail. Epics (large user stories) need to be broken down so the team can gain a better understanding of the story, so they can complete the story during the sprint. Splitting stories is as a mechanism to expose functional detail. In Splitting User Stories Based on Elementary Processes, we used an example of large time accounting data entry story. The story was:

  • As a time accounting user, I want to maintain my time so that I can account for the work I do.

The story is well formed (it fits the format we are using), but because it is too large and it obscures a lot of important detail. The story could easily be broken down into smaller stories. For example, add time, change time, display time and delete time would be a quick functional split. Once the story is broken down and the new functionality is exposed, acceptance criteria can be generated providing which generate more detail and further even more knowledge (a virtuous cycle).

User stories evolve. In almost all scenarios I have witnessed additional information and knowledge is generated by the team as they split stories, digest acceptance criteria, have conversation, build models, prototypes and designs.