How should we handle separate stories that complete an epic?
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.
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...
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.
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.
"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
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.