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]

  • 2
    Possible duplicate, at the very least worth reading: pm.stackexchange.com/questions/20239/…
    – Sarov
    Jan 26, 2017 at 4:25
  • 2
    Your question is a little unclear. You have dependencies between your stories, and stories are parceled out to different people/teams rather than being collaborated on. Is that right? —If so, what specific problem is that actually creating for you or your team?
    – Todd A. Jacobs
    Jan 26, 2017 at 5:59
  • @CodeGnome it sounds the like OP is exploring his Agile patterns for suitability rather than facing a problem. OP - I would def refer to the link that Sarov put up which answers your question. Jan 26, 2017 at 10:20
  • Thank you for your response's. I have updated my question to be more precise. I hope its better than my previous details.
    – Shubh
    Jan 26, 2017 at 19:33
  • Possible duplicate of Story Decomposition Granularity
    – Sarov
    Jan 26, 2017 at 19:40

2 Answers 2


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.


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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