Do we create application-level stories?

Question

Quoting an example.

If I have a user story which says:

As an administrator I should be able to query all users (both active and inactive) from my database when in my master configuration (Admin section of application) the flag 'return inactive user' is set as true.

Assume, now if we need to implement we need two developers: one for creating this flag in Master configuration and another one to modify the existing search logic (which exists somewhere else and not in the Admin section) to return Inactive users based on the flag value.

Now the question is, can we create two stories as:

1. Creating master configuration in Admin Module and
2. Updating existing search mechanism to handle Inactive users.

Or we stick to the above mentioned story and create sub-tasks related to Admin Module and Updating existing search?

I hope my question makes sense now?

[Using Jira]

Answer 1

As an administrator I should be able to query all users (both active and inactive) from my database when in my master configuration (Admin section of application) the flag 'return inactive user' is set as true.

This is not following the typical user story approach as it contains implementation details and is not focused on the value derived. A reworked version might look something like this:

As an administrator I want to retrieve a list of either all users (both active and inactive) or just the active users depending on what is the most appropriate search so that I can perform actions on the list.

Note that the user story does not contain implementation detail such as mentioning the master configuration. The implementation detail is typically covered by technical tasks. Examples of these tasks could be:

Create a flag in the master configuration to indicate if user searches should return inactive users.

Modify the existing search logic to return inactive users based on the master configuration flag value.

The important part here is to distinguish between user stories (which are end-user value related) and technical tasks (which are determined by the delivery team when they are deciding on implementation). It often takes several technical tasks to deliver a single user story.

Answer 2

Although Barnaby's answer covers most I do want to add a little bit.

How can we solve your problem?

Your example user story does not explain why the administrator wants this, but it focuses on the how. User stories should try focus on the why instead of the what and how. This so that the team can solve the problem in anyway they see fit. Maybe setting the flag is not the simplest way to solve this request. I have heard about a team that resolved 50% of all their request by not implementing any code at all. Most of the time they just sit with the users to teach them how to use their existing tools to resolve the stories why question for them. Leading to better focus, faster value and less (code) maintenance.

to implement we need two developers

This quote scares me. Why do you need to separate developers to fulfill this relative simple technical request? And does it matter? Let the "cross-functional" team decide how to split the task and resolve it. Just make sure a single team has all the knowledge to resolve any user story in a product they are working on. If they lack the knowledge get sharing as soon as possible.

The Scrum guides team pages states:

Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.

and

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

Your question feels like it is ignore this. As it is telling how to implement the functionality and which developers should be doing it. Let the team decide how to tackle this, just explain them why someone wants what value.