Quick Bite #7: Write effective story summaries

User story descriptions in a “who-what-why” format are intuitive and work great in story communication, however not when you manage a multitude of stories.

Photo by Karim Ghantous on Unsplash

Have a look at this backlog of just four items:

1. As a technical expert, I want to manage my job association with the project, so that I can decide which jobs belong to which project
2. As a technical expert, I want to get my job association with the project from XProject, so that I can decide which jobs belong to which project
3. As a technical expert, I want to see if my job is part of the project, so that I can refer to other jobs on the project
4. As a technical expert, when my job is part of the project, I want to see all jobs in this project, so that I can navigate between jobs in this project

How quickly can you locate a specific story when you need to refine it, trace it to another story, or place it on the story map? The mantra “As a … I want …”, especially with a repeated actor, is working against you.

Now see the same list differently:

1. Link job to a project
2. Get job link to a project from XProject
3. See job as part of a project
4. See all jobs in a project

It’s the story summary that does the magic!

The magic works when you write the summary consciously and never misuse it for the description. Issue tracking products offer you an attribute for that, “Summary” (Jira), or “Title” (Azure DevOps), along with “Description.”

To write effective story summaries, think of your user stories as activities in the user journey and suggest their brief names:

• Use active voice: “Link job to a project” not “Job can be linked to project.”
• Use present tense: “Get job link to a project from…” not “link to project imported from…”
• Call to action: Imagine how a story summary would look on a button (indulge the sin of UI thinking for a moment).
• You can derive the summary from the story description (the “what”) but keep the description away from the title.