Skip to main content

How should we handle separate stories that complete an epic?

Last post 01:21 pm July 10, 2023 by Jacek Markiewicz
5 replies
04:56 pm July 7, 2023

We have just started moving from a waterfall to an agile/sprinting pattern. There's constant debate about handling stories created by the PO that use the same data behind the scenes. For instance, we have an epic "Having the ability to manage health care assessments" Inside that epic we have multiple user stories created with success metrics, "As a doctor I want the ability to add an assessment to a patients profile", "As a doctor I want the ability to clear all current assessments from the patient's profile".  

The argument amongst the development team is how can you clear an assessment without having first added an assessment, therefore blocking the clear from getting started until the add has been completed. There has also been the suggestion that the user story should just be managing the assessments, but then it would take 3 weeks to do the entire story if not longer which is far too long.

There have been suggestions that we build the add, clear, edit, etc as "components" so that we can then create a story to implement all these pieces together into one feature that can be shipped out the door. 

Looking for solutions to this problem or to get pointed in the right direction of the handbook that would explain a solution.


07:00 pm July 7, 2023

To make long story short, you should try, and try and try, untill team will learn to refine PBI's (product backlog items)into what some practitioners call "ready" items(ready user stories if you prefer it that way). It means PBI" s which are shaped in such way that they can meet Definition of Done at some point during a Sprint, if they will be moved from product backlog into Sprint backlog at sprint planning or whenever, making way to Increment. It takes practice...


08:54 pm July 7, 2023

We have just started moving from a waterfall to an agile/sprinting pattern. There's constant debate about handling stories created by the PO that use the same data behind the scenes. 

Excellent, this debate is precisely what you want. Now, what are the smallest experiments the team can run, using that "agile/sprinting pattern", which will validate any assumptions or proposals being made?

Remember that a user story is a placeholder for a conversation about a potential requirement.


10:17 pm July 7, 2023

It's definitely possible to implement "clear all current assessments" before implementing "add an assessment". You can also demonstrate this functionality, at least in a demonstration or test environment, and get feedback on your implementation of "clear all current assessments" by simulating the requisite data in a manner that allows it to be shown in the UI. You can then, potentially, act on that feedback before you finish the complete flow of work.

The real question is if you could deploy such changes to production. In some industries, especially regulated industries, there are rules about certain functionality needing to be implemented in production systems (such as audit trails), having non-production or test data in production, and so on. So you may need to manage how you build and enable this functionality to ensure it's only available in development, test, or demonstration environments until it's more complete.

Now, just because you can do things "out of order" doesn't mean that it's a good idea. Perhaps the team is right and it would make more sense to implement creating/adding first, then moving on to editing, and finally clearing, receiving feedback from stakeholders at the appropriate times in development or at the Sprint Reviews. But it's something to consider.


07:50 am July 8, 2023

"The argument amongst the development team is how can you clear an assessment without having first added an assessment, therefore blocking the clear from getting started until the add has been completed. There has also been the suggestion that the user story should just be managing the assessments, but then it would take 3 weeks to do the entire story if not longer which is far too long."

The general concept of doing scrum is to work on details as a run the project

Basically if you have ANY PBI item(something which many people call "user story") developers, scrum master and PO, its enough to start a Sprint. Nothing should be perfect, you just move on and the work process with provide daily feedback loops and learning how to do find best solutions. The Sprint backlog, and PBI which you call "user stories" can change DURING THE SPRINT, so instead of waiting 3 weeks.

Remember that you can add the non functional requirements to the backlog, and this includes the tasks of improving the performance, anyway developers suggest. So if they want to organize the process certain way it is perfectly possible to do it WITHIN the sprint, instead of waiting


01:21 pm July 10, 2023

Scrum is very much goals/value oriented.

When you brainstorm with the team about product backlog management, you may want to emphasize the goals/value perspective.

What is our current 'product goal'? What value it is going to realize, and how do we measure this value?

What might be the interim Sprint goals leading toward this product goal? what value those Sprint Goals will deliver and how do we measure that?

How do we make our Product Backlog transparent about the goals and the value, so that it is visible how the product can incrementally increase its value to the stakeholders?

"Having the ability to manage health care assessments"

That sounds like a nice Sprint Goal, which is both concrete and also flexible since you can probably do it many different ways. 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.