When naming stories in my backlog should I mention who the intended User is?

[Reshad Asrani]

Hi Guys!

So I've complied a list of stories in my backlog and I've followed the standard conventions for

a) describing the requirement ("As a ..., I want ... so ...") and

b) naming the requirement in the backlog (<verb/action> <activity/thing> e.g. Creating an Account).

The hiccup is, I have a bunch of stories that have the same objective but differ in motives and/or origins. For instance :

'Creating an account as a Kid' vs. 'Creating an account as an Adult' vs. 'Creating an Account as an Admin'.

The workflows could vary a bit (or they may be the same) and the wire-frames and VD could vary substantially.

I'm expecting my designer to link his InVision designs to my stories. My acceptance criteria and test cases are going to vary too in most cases depending on which user is performing the action.

How do you guys handle these instances? Do you maintain separate stories? Or do you handle it as a single story? Or maybe use sub-tasks?

Looking for a best practice here.

Thanks a ton!

[Ste]

Hi @Reshad Asrani

I would consider INVEST when writing these user stories, which is:

• Independent
• Negotiable
• Valuable
• Small 
• Testable

You need to consider how much variance there is between the different types of customer being delivered to - there is nothing wrong with having a similar objective if each story can deliver independent value that is testable and releasable. 

You also want the stories to be small - and have testable acceptance criteria. It sounds like you could have some substantial differences in flow and UI/UX - could these be classed as small if grouped together? Could one set of acceptance criteria cover all scenarios?

An alternative here is if the creation of accounts is quite large - could Account Creation become the Epic with a collection of value being delivered through the stories based on the different users (i.e As a child, I want...., As an adult, I want...)

Ste