SCRUM Sprint and tasks/user stories that cannot fit into a sprint!

Question

Say I have an Epic that is estimated to take 3 sprints to do.

And the Epic is broken down into A to Z tasks/user stories.

Problem is, to do B, we need A, to do C we need B, etc.... And in sprint one, we only complete A to E,

and I do not think it can be classified as "Done/Done" within a sprint, as that functionality cannot be tested as it breaks existing functionality, what is the best practice for such a scenario?

Eg.

1) Epic = Revamp of Super Calculator Functionality.

2) Calculator has Calculate A, Calculate B to Calculate Z Functionality and a final result.

3) You need to do Calculate A to do Calculate B, as Calculate B requires the result from Calculate A, etc until Z.

4) Existing calculator has A to Z, but their rules have all changed.

5) The final calculator result is wrong if only Calculate A to B are changed, as existing C will break.

6) They can be unit tested per unit, but cannot be checked in and tested on the ui by testers and cannot be defined as done, as the release should not include partial changes, as customers are using the calculator.

Such scenarios are affecting our burndown chart per sprint and bosses are complaining, hence this question.

Cheers

Answer 1

User-Visible Functionality

The goal of a sprint is usually to complete one or more user-visible features. However, there are certainly projects where this is not always possible. It may be worth re-evaluating whether this is possible in your situation.

For example, math certainly supports the concept of sub-expressions, so each sprint could have a goal of completing one or more sub-expressions. You could demonstrate the successful execution of each of the new sub-expressions during your Sprint Reviews.

If your software was designed in a non-modular way, and features can't be replaced incrementally, you can still develop new modules alongside the old ones and show off those increments each sprint. You will then have a big "swap-out" user story at the end of your project, where you have some kind of cut-over to the new modules, but it's certainly an option in some cases.

Sprint Length

You can always adjust your Sprint length to ensure that you have adequate time to deliver functional features. While most Scrum projects vary between 2-4 weeks per sprint, I've seen projects with 90-day sprints too---but the methodology still requires that each sprint meet a Sprint Goal and deliver at least one element from the Product Backlog to be a success.

Projects with Zero Incremental Value

If your project truly has zero value unless all elements are fully functioning, then Scrum or any other form of purely iterative development is not the right approach. For example, if you are rewriting a piece of software that is too tightly-coupled to replace a piece at a time, then the benefits of iterative development are not obvious.

You may want to consider Kanban, Lean, or even traditional waterfall development if you can't deliver any value to the users until the very end of the project. A car can't be driven with only one wheel; at the risk of a faulty analogy, perhaps your software project can't be used without 100% of all new pieces in place, either.

Personally, I think all projects can be refactored into incremental-value projects, but that may require a complete re-engineering of the project plan and the project management process. If that simply isn't possible for political or practical reasons, then you must search for a methodology based on something other than incremental features.

Answer 2

If you can, create a backwards compatibility adaptor from module E that you just finished to module F that is legacy. This way you can modify the flow each sprint, replacing old modules and placing a adapter at the end, so the rest of the modules still receive the data in the way they expect it.