My team is building a web application that has the following high-level user story:

As a user, I would like the ability to bulk exclude components from a given country.

The work breaks down into two distinct tasks.

  1. Create the web application feature that excludes components by country.
  2. Fetch component - country association data on a daily basis

At first, I started to break this down into two user stories. However, the second task doesn't really fit into a typical user story format. I started writing something like this:

As the system, I will parse country data from the XYZ feed.

On one hand, this task is not user-centric. On the other hand, the ability to fetch component - country data is a well defined, vertically sliced task that is independently verifiable.

What is the proper user story breakdown for this type of scenario? Is it improper to have a system focused user story?

  • Why do you have to split it at all? It seems like getting the country data will be part of the act of being able to exclude it.
    – Daniel
    Commented Mar 22, 2019 at 16:06
  • @Daniel I'm considering splitting it apart because each item represents a well encapsulated piece of functionality, and any estimate requires a distinct review of each independent function. Commented Mar 22, 2019 at 16:11

3 Answers 3


Pay attention to the 'V' in the INVEST mneumonic.

A PBI must deliver value to the stakeholders.

Ask yourself: by itself, does the ability to parse country data from the XYZ feed provide any value to the project's stakeholders?

If yes: good, split it. If no: nope, keep it as-is (or possibly split it some other way that doesn't invalidate INVEST.

Note: 'The System' is probably not a project stakeholder.

  • 3
    It's worth noting that Sarov uses the term PBI, not user story. The computer doesn't want anything, so it shouldn't be the 'who' in the user story. Either figure out who actually wants it or don't use a user story. Scrum doesn't say all PBI's must be user stories. This may seem dogmatic, but this practice really waters down the value of user stories.
    – Daniel
    Commented Mar 22, 2019 at 16:09

Sprint Backlog Tasks Aren't Inherently User Stories

You're conflating user stories and tasks. Product Backlog Items often start as user stories on the Product Backlog, but Scrum doesn't mandate the user story format. Those Product Backlog Items get imported to the Sprint Backlog during Sprint Planning. Stories are often refined further at that point, and additional stories and tasks related to the planned work are often generated throughout the Sprint.

The key point, though, is that tasks need not be full-fledged user stories, even if your Product Backlog uses the format. Go ahead and use user stories when it makes sense, but implementation details rarely make sense as a user story because:

  1. The value consumer is often the team, because implementation details serve the team or system rather than a user.
  2. There's no conversation to be had outside the team, because the team is the consumer of the task.
  3. There's often no conversation to be had at all. Usually, by the time something is decomposed to the level of "I will parse X from Y," the team has already had the planning and design discussions around the implementation and designed the tests for the planned work.

User stories are conversation placeholders, and generally provide a value consumer, a shorthand feature description, and some context to guide the implementation and follow-on discussions. User stories are not specifications! So, don't over-constrain your process by trying to shoehorn implementation details or specifications into the user story format. Usually, the juice isn't worth the squeeze.


I agree that the daily DB fetching could be a task that is part of the requested user story.

But if for whatever reason, you don't want to or are unable to work both tasks in the same sprint, it might help to focus on the value (that would be) delivered.

The DB fetching task doesn't deliver any value to the user, but it delivers value to the PO by reducing the cost of implementing the user story.

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.