User Story breakdown - Technical Task + User FeatureStory Points to Ideal DaysQuickly explain how to make estimation work to an external business stakeholderUser Stories in JIRA for a project that covers several platformsEstimating user stories at the start of the project so that the PM can determine a quote for the clientCreating a user story for a back-end processHow to write user stories for our UI development process?Technical user stories or development related tasksJira Sprint Structure for Software TeamIs it OK to defer implementation detail and consider user story to be done?In Scrum, how to handle a functionality that could be used by more than one feature?
Landlord wants to switch my lease to a "Land contract" to "get back at the city"
Why is my log file so massive? 22gb. I am running log backups
How can I fix this gap between bookcases I made?
Is "plugging out" electronic devices an American expression?
Doomsday-clock for my fantasy planet
A poker game description that does not feel gimmicky
How to manage monthly salary
What causes the sudden spool-up sound from an F-16 when enabling afterburner?
Where else does the Shulchan Aruch quote an authority by name?
Are cabin dividers used to "hide" the flex of the airplane?
How to make payment on the internet without leaving a money trail?
LWC and complex parameters
Can I find out the caloric content of bread by dehydrating it?
Is it wise to hold on to stock that has plummeted and then stabilized?
Why did the Germans forbid the possession of pet pigeons in Rostov-on-Don in 1941?
Ideas for 3rd eye abilities
Does the average primeness of natural numbers tend to zero?
Is there a name of the flying bionic bird?
Can a planet have a different gravitational pull depending on its location in orbit around its sun?
Domain expired, GoDaddy holds it and is asking more money
Pristine Bit Checking
What happens when a metallic dragon and a chromatic dragon mate?
What is the meaning of "of trouble" in the following sentence?
Is domain driven design an anti-SQL pattern?
User Story breakdown - Technical Task + User Feature
Story Points to Ideal DaysQuickly explain how to make estimation work to an external business stakeholderUser Stories in JIRA for a project that covers several platformsEstimating user stories at the start of the project so that the PM can determine a quote for the clientCreating a user story for a back-end processHow to write user stories for our UI development process?Technical user stories or development related tasksJira Sprint Structure for Software TeamIs it OK to defer implementation detail and consider user story to be done?In Scrum, how to handle a functionality that could be used by more than one feature?
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.
- Create the web application feature that excludes components by country.
- 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?
scrum agile user-stories tasks sprint-backlog
add a comment |
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.
- Create the web application feature that excludes components by country.
- 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?
scrum agile user-stories tasks sprint-backlog
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
Mar 22 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.
– The Gilbert Arenas Dagger
Mar 22 at 16:11
add a comment |
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.
- Create the web application feature that excludes components by country.
- 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?
scrum agile user-stories tasks sprint-backlog
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.
- Create the web application feature that excludes components by country.
- 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?
scrum agile user-stories tasks sprint-backlog
scrum agile user-stories tasks sprint-backlog
asked Mar 22 at 15:01
The Gilbert Arenas DaggerThe Gilbert Arenas Dagger
1183
1183
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
Mar 22 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.
– The Gilbert Arenas Dagger
Mar 22 at 16:11
add a comment |
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
Mar 22 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.
– The Gilbert Arenas Dagger
Mar 22 at 16:11
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
Mar 22 at 16:06
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
Mar 22 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.
– The Gilbert Arenas Dagger
Mar 22 at 16:11
@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.
– The Gilbert Arenas Dagger
Mar 22 at 16:11
add a comment |
3 Answers
3
active
oldest
votes
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
Mar 22 at 16:09
add a comment |
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:
- The value consumer is often the team, because implementation details serve the team or system rather than a user.
- There's no conversation to be had outside the team, because the team is the consumer of the task.
- 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.
add a comment |
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.
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "208"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fpm.stackexchange.com%2fquestions%2f26044%2fuser-story-breakdown-technical-task-user-feature%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
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
Mar 22 at 16:09
add a comment |
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
Mar 22 at 16:09
add a comment |
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.
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.
answered Mar 22 at 15:59
SarovSarov
9,70932142
9,70932142
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
Mar 22 at 16:09
add a comment |
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
Mar 22 at 16:09
3
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
Mar 22 at 16:09
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
Mar 22 at 16:09
add a comment |
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:
- The value consumer is often the team, because implementation details serve the team or system rather than a user.
- There's no conversation to be had outside the team, because the team is the consumer of the task.
- 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.
add a comment |
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:
- The value consumer is often the team, because implementation details serve the team or system rather than a user.
- There's no conversation to be had outside the team, because the team is the consumer of the task.
- 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.
add a comment |
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:
- The value consumer is often the team, because implementation details serve the team or system rather than a user.
- There's no conversation to be had outside the team, because the team is the consumer of the task.
- 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.
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:
- The value consumer is often the team, because implementation details serve the team or system rather than a user.
- There's no conversation to be had outside the team, because the team is the consumer of the task.
- 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.
answered Mar 22 at 16:10
Todd A. Jacobs♦Todd A. Jacobs
33.7k333121
33.7k333121
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Mar 23 at 0:41
Vicki LaidlerVicki Laidler
2,376615
2,376615
add a comment |
add a comment |
Thanks for contributing an answer to Project Management Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fpm.stackexchange.com%2fquestions%2f26044%2fuser-story-breakdown-technical-task-user-feature%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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
Mar 22 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.
– The Gilbert Arenas Dagger
Mar 22 at 16:11