Ytdyklly

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?

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.

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.