Multiple roles in user stories

Question

This seems to be a common problem and, after reading these 2 questions

What is best pratice for user stories containing two roles and User stories with multiple users/roles I'm still confused.

In my case, my system will have reports and 3 roles:

• developer
• team leader
• CTO

all of them can create and read reports, but developers can only read his/her reports, team leaders can read the reports of the developers in their teams, and the cto can read all the reports.

If I have (for example) 30 user stories involving the reading functionality should I have 3 copies of each user story, once for every role?

For example, should I have this??

"As a developer I want to read the number of pull request of the report"

"As a team leader I want to read the number of pull request of the report"

"As a CTO I want to read the number of pull request of the report"

Answer 1

One role per story is a reasonable goal. But that only requires you to break them up if your vocabulary sucks.

What you need is a single name for the role the developer, the team lead, and the CTO play in the user story when they read the report. After all, roles are not job titles.

If user doesn't work for this you need to think about why.

Answer 2

First, I'm unsure that a user story is a worthwhile tool here. It feels like you have a clear implementation in mind and you are retroactively building a user story around it. That said, when you have multiple roles with the exact same need, you generally have two options:

1) select a noun that describes all the roles as a group (as an IT employee) 2) select the role that most benefits from the functionality.

Now, where splitting roles can be really helpful is in incremental building of the product. Let's say you start with this:

As a CTO, I would like to see an overview of all pull requests so I get a snapshot of activity in my department.

Now, to fulfill this, you are probably going to build a report that is a bit light on detail, but very broad. Next, we execute something like this:

As a CTO, I would like to pull a detailed report based on areas of the overview that interest me.

Now that I have this, I may decide that this detailed report would also be useful to a team leader, but it should limit to their team. I can't see any benefit to using a user story at this point, so I say something like:

Give Team Leads access to detailed report: limit to their direct reports.

At each stage, I'm building on the previous stages with functionality that specifically targets the needs of the person most benefitting from the work.

Answer 3

They still feel like separate stories when you get to the “so I can...” part of the story. I largely agree with candied_orange, but in the example you mention, the three roles do have different functionality. (Devs only see themselves, team leads see their team, CTO spans multiple TLs and by extension multiple devs). So hopefully you’re building at least three automated tests for this group.

Ultimately what does the team think? If they can deliver all the functionality in a single iteration, then a single story is probably fine, if not work with them and the PO to determine how best to split it up.