Should common functionalities be repeated as very similar stories within each context they're needed?

Question

Let's say for a system, there are several stories that would be repeating all throughout but in different contexts.

E.g. Search

"As a [insert role], I want to search through a data list so that I can easily find what I am looking for."

Same with logging in, filtering, editing profile, etc. All of these are stories that each role would need to perform to complete a certain epic (or are epics in themselves).

I am not sure if I should repeat all these stories for every role (and tag them as "Log-in Theme" or "Search Theme") or do I create ONE separate "Search Epic" which I would refer to whenever I'd need to (which of course, contains user stories for searching).

Thoughts?

Answer 1

A user of the system can have multiple roles at the same time that form a hierarchy from a very generic role to a specific role.
For example, if a user is logged in as an Administrator, they will at that time also have the role "Logged-in User" and "User".

If you have a set of stories that is the same except for the role mentioned in the stories, then you should first look for a more general role that can reduce all those stories to a single one.
You don't want to have a dozen stories "As a X-role, I want to edit my profile to keep it up-to-date", when you can have a single "As a logged-in user, I want to edit my profile to keep it up-to-date" for about the same complexity of a single story out of the set.

If the stories are not similar enough to be grouped under a single user, for example because the objectives are different, then it depends on their relation with other stories in the project if and which theme or epic they belong to.

Answer 2

If the only difference in the story is the role, and if the roles don't need different search abilities or UIs, then use a generic term meaning "all roles" and write one story. ("As a person interacting with the system" perhaps)

If some roles need different search abilities or UIs, then write and implement the generic story first, then write one or more additional stories to cover the additional capabilities. ("As a sysadmin, I want to search hidden data so that I can.." or "As an advanced user, I want to search on multiple parameters so that I can find what I'm searching for more quickly")

Answer 3

I'm dealing with something similar on a project at the moment.

Let's not forget that at it's core, Agile is a process of iteration. As such, you shouldn't feel obliged to commit to some approach with these stories up front.

I would argue that ability to search for x is the right story, and ability to search for y is another. You do not need to have a specific story for each user to conduct each search. That is a story that defines those search rules, based on user type.

Then, at unboxing, someone (you?) might then need to drill into this with your developers to break up the story into tasks if needed.

Trust your instinct on this and try something different if it's not getting cadence after a couple sprints!

Answer 4

If only the role performing the action is different, and the actions (add, search, edit, etc) as well as the context (user profile, invoices, etc) of the actions are the same, then you are talking about just one user story.

You can use a broader name for these roles or just type them all if they aren't too many; e.g. As Staff User, I want to search for ABC so I can XYZ. Or maybe As IT Staff or Management Staff, we want to ABC so we can XYZ.

Roles need not represent actual roles in your system.

It also helps if your stories have the INVEST properties by the time they are ready for selection.