Take the 2-minute tour ×
Project Management Stack Exchange is a question and answer site for project managers. It's 100% free, no registration required.

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

share|improve this question
2  
If you could include a bit more detail about your actual epic and user stories, you'll get a more useful answer. Otherwise, you're likely to get truisms that you likely already know but aren't sure how to apply. –  CodeGnome Nov 12 '12 at 23:26
add comment

2 Answers 2

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.

share|improve this answer
add comment

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.

share|improve this answer
    
Hi Vlad, I edited your post slightly so it wouldn't sound so much like a follow up comment to the question, since follow-up questions should be posted as comments, not answers. With that said, the adapter pattern can help with refactoring, and it's one I use a lot. Hope this helps. –  jmort253 Nov 17 '12 at 19:37
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.