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.

  • 1
    One thing to note is that if you hover your mouse over a backlog item JIRA does display the full summary. So if you use long story names then it will still be possible to read them without having to go into each story in turn. – Barnaby Golden Nov 10 at 18:59
  • 1
    JIRA is a ticketing system, not a user-story system. Stop thinking of the field as a summary, and just use it as a meaningful title to which the team can easily refer. – Todd A. Jacobs Nov 13 at 4:32
up vote 1 down vote accepted

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.)

  • I didn't know about them, but I quickly looked it up and it is a bit eye-opening. I need to research more on job and user stories. Thanks for sharing. Currently we are trying out "I want to... So I can...", but the idea of 'when' makes sense. However, we do have more than 'customers'. We have at least 'customer', 'merchant' and 'service engineer'. I find them useful when I write a story. It helps to understand 'why' part. – Siim Haas Nov 16 at 6:51
  • 1
    I did wonder if you had more roles and had just shared 3 customer ones by chance. Some people think job stories are more useful because user motivations change so fluidly and frequently. Anyway, hope it helps! – Natalie Lewendon Nov 16 at 9:31

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.

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.

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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.