Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Example: I have a project where I want to import raw data into a new database.
sprint 1: clean up/validate raw data
sprint 2: import raw data to new database
If sprint 1 fails, what is the SCRUM methodology to stop and redo sprint 1, or introduce a new high priority sprint 1.5, before proceeding to sprint 2?
If I truly believed there was no such thing as failure, I would simply import the unusable data, record lessons learned, delete the data and start over?
As written, your stories are probably too big to be properly agile. However, you can't work on dependent stories until you complete their prerequisites, so if you can't do an import until you have 100% of all data sanitized then you would continue to work those stories in subsequent Sprints before getting to what you're calling "Sprint 2."
As described, your workflow just doesn't seem all that agile. User stories should be vertical slices of functionality. While there may be a valid reason to do data sanitation and imports in separate Sprints, in all likelihood you've failed to define INVEST stories. So, revisiting your backlog items is probably the first step.
However, if we assume that you have have the right stories, and that you aren't able to achieve the Sprint Goal defined for Sprint 1, then the story is not done. You should review this during your team's Sprint Retrospective to see if you can identify process issues that led to this result.
The entire unfinished story goes back onto the Product Backlog for refinement, re-prioritization, and re-planning. In this case, since you currently have only two stories, and the second story is presumably dependent on the first (unfinished) story, then you will likely need to continue working on refined data sanitation stories in the next Sprint.
Refine your stories until you comfortably deliver a vertical slice each Sprint. Perhaps you'd sanitize and import user data in the first Sprint, current product information in the next Sprint, and back catalog items in a subsequent Sprint.
Since I don't really know anything about your data or your real use cases, these are just examples. The point is to refine your stories until each one is largely independent of the others, fits within a single Sprint, and can be tested to ensure it meets your Definition of Done.
What you are doing here is running a waterfall project using sprints.
The key focus here, I believe, is how you break down the work i.e. how you break down what needs to be done.
You need to break down the work in a way that value to the business is realised as fast as possible, ideally at a story level but at a minimum at a sprint level.
An example would be instead of having a sprint that cleans the data, have a sprint that cleans half the data and imports it into the new DB. The second sprint would clean the rest of the data and import it into the DB.
