How to write a summary for a user story?

Question

I'm working hard on user stories and it is paying off, but something itches.

We use Jira, but the problem is that from above the backlog seems clumsy.
We need to write summary for user story so that Jira can display it, but those summaries are sometimes little bit misleading or not helpful to find some particular story.

We don't do scrum, we just use backlog and modified kanban board to visualize our progress.

I would like backlog (and the board) to display stories in (readably) coherent structure so that I can navigate more easily.

At this moment to solve that problem I see that I either:

1. Find a way to establish some consistency in summaries.
2. Find a way to display (visualize) user story in a backlog in other way.

I don't know how to go about point 2.

Some ideas for point 1 so far:

• Use "I want ..." as a summary.
• Use the story in summary field, but that would beat the purpose of a summary.
• Accept that it cannot be done.

More I think about it, I think that user story doesn't have a summary(?). They originated from index cards(?) and represent a small slice of a requirement.

They seems to be as brief as you can get.

Some example stories (please be gentle if they have flaws) in the context of vending machine or pay station that offers card payment option.

As a customer,
I want to be reminded that my card is in card terminal after I have cancelled card payment,
so that I wouldn't forget it to pay station.

As a customer,
I want to be reminded that my card is in card terminal after I have paid by card,
so that I wouldn't forget it to pay station.

As a customer,
I want to know if I have successfully cancelled card payment from card terminal,
so that I wouldn't be confused whether I have paid or not.

Answer 1

Use job stories instead.

All your user stories start with 'As a customer', so you're wasting that line. We know they're a customer. That's a given.

Instead, job stories go:

When... I want to... So I can...

So - for example -

When I have cancelled a card payment, I want to be reminded that my card is in the card terminal, So that I won't forget it.

(And then you can add a final line - 'This need is met when...', so that you know exactly what you have to do. If you like.)

Answer 2

I'll be very hard to find a canonical answer for this question and considering the problem you have might be shared by other community members, I'll share some thoughts.

Your underlying problem is how the team visualises the backlog. Regardless of how detailed the summary is, it's only a... summary. You shouldn't expect to understand everything from the summary.

Try to see summaries as "pointers". Your team should have a session to review top backlog items (to get to know the actual "content"). Next time people look at the backlog, by reading the summary, they should have an idea on what each item is about. Reading about backlog refinement might help you.

Now, taking into account your specific Story examples and your Jira usage. If you use a Scrum board instead of Kanban board, you could group the above stories beneath an Epic called "payment by card"... and then, at the Scrum backlog, you could click on this Epic on the Epic filter on the left side of the backlog. You can see an example in THIS answer.

You could apply the same logic to other Epics, such as "payment by cash" or even leave a specific Epic for "payments". The bottomline is that the backlog should be easy to read and navigate.

Answer 3

Also – it is extremely important to remember that "a 'user story' is not source-code!" A user-story is simply a statement of a requirement in human terms. If you "summarize" it, you run two pragmatic risks:

• You alter it, consciously or unconsciously rewriting it in terms of the evolving software system's design or implementation.

• You impose one meaning – yours – upon something that, from "the user's perspective," might have been intended to mean something else.

Your aim is to use these stories during the process of formulating designs and implementations, so that you can then hold that design up against them to see how the requirement stated in that "story" is to be fulfilled, both by the system and by the hypothetical user who "told the story" when they attempt to use the system. If you summarize (rewrite) them, you very quickly lose their intended value.

Answer 4

Yes that's right, if you are truly using the concept of User Stories, there is no summary. Just the "As a, I want, So that" format.

If you are wanting to, or can, write more of a summary than that, then you are doing, or have performed, analysis work that should be done by the team later. That is the purist approach I guess. It is even a well known practice to add acceptance criteria to the story, maybe in gherkin format, so it is hard to argue that it is always bad to add more than the title. Of course, acceptance criteria are often added later, at refinement.

I think once you are adding a lot of text or diagrams or screenshots then it starts to move away from the essence of a User Story. That might not always be a bad thing, not all agile requirements have to be User Stories. However the way a lot of places use the term User Story, with entire multi-page word files attached, is not really what we should think of as a User Story.

In practical terms, in Jira you could store the acceptance criteria in the summary field.