In Agile development you work on small user stories and produce a working iteration.

But what happens when the next user story comes in and affects the design for the already done iteration?

Sometimes it seems like re-doing the last iteration or another user story to incorporate the new user story in the last iteration!

How to approach on this?

  • 1
    I mean Design depends on requirements and in agile requirements come in iterations, therefore may work for 1st iteration but may not be suitable for the next. Commented Mar 16, 2012 at 6:52
  • 1
    Coding decisions may be correct for 1st iteration but may be fatal for 2nd. This what I mean by code quality. Commented Mar 16, 2012 at 6:55
  • Your approach on 1st iteration may be too focused on focus user story, and in the 2nd user story you might also have to use the same module to handle totally different style of requirement. Commented Mar 16, 2012 at 6:59
  • In case when you would have designed it totally differently if you would have known the 2nd user story in the first place. Commented Mar 16, 2012 at 6:59
  • I understand that the OP thinks about this similarly to requirement changes in traditional software processes. Changed requirements may lead to re-designs and tests have to be re-evaluated as they may have turned into false-positives.
    – Frank
    Commented Mar 16, 2012 at 7:01

3 Answers 3


The problem you describes is related to YAGNI.

In pure agile mindset you can follow YAGNI and code exactly what current user story demands without any upfront decisions about further needs of your code. It can really end with the problem you describe.

In pragmatic way you can look into your backlog and priorities of other known user stories and somehow reflect further needs in your current implementation. It doesn't mean that you will code your current stories with features required for future stories but you will lay the design of current implementation to be extensible for expected needs.

In contrast YAGNI is still in the game in case of unknown future requirements. If your backlog doesn't contain high prioritiezed story demanding some significant changes in your current implementation you will simply code your current implementation in the simplest possible way to fulfill just the current story. The reason is avoiding gold plating of your code = delivering something nobody really wanted.

Conclusion: If you can predict what happens next (items in your backlog are mostly stable) you can add such decisions to your current implementation. If you cannot predict what will be needed in future simply follow YAGNI.

  • Great.. @Ladislav Mrnka , you got the problem right. Commented Mar 16, 2012 at 12:00
  • Does SCRUM (And related tools) covers this aspect of the project ? Commented Mar 16, 2012 at 12:01
  • The Scrum by book probably doesn't talk about this directly but it feels quite natural. You have a product backlog and Product Owner has the vision what will really be needed in near future so during discussion on current story and its implementation you can already prepare some necessary abstraction for upcoming stories. Commented Mar 16, 2012 at 12:10

As there seems to be a bit of debate on where exactly the question is heading, I'll try to give a few pointers:

  • In non-agile process models you typically have changes being made to requirements, which roughly corresponds to your scenario. In that case, the effects are especially easy to see when you consider the waterfall model: you have to go through your whole product and all previous process steps in order to adjust for the new or changed requirement.

  • In Agile development, before you start your sprint you should have a meeting to discuss which user stories/epics/features/.. you plan to realize in the upcoming sprint along with an estimation of the required efforts. It is this latter emphasized part, where you as a team member should raise the bar significantly if you see that a major design change and lots of refactoring will be required.

Everything becomes more problematic, the less competent the team is of course. So, if you get told a user story and you say you can implement it in 2 weeks, but only later come to realize that you need to redesign and it'll take you at least 4 weeks, it is too late. You will already be mid-way in the sprint and the sprint will fail. At this point, the only option pretty much is to cancel the sprint right-away. You re-start at that point by having a new meeting and look at the user stories you want to realize in the then next sprint including your new knowledge of the design problems, which will lead to more accurate time estimates.

To finish with a more positive statement than that: It does help enormously to rely on good time estimation methods (f.ex. planning poker) in order to reduce the risk of estimates going way off.

To extend the answer with regards to your comment: Code quality ensurance remains basically unchanged by this. You ensure code quality by testing, and you do so no matter if you have to redesign or not. Of course, a chair cannot be cast into a table. But this simply means, that you have test cases which try to do that, but fail. This is actually the easy case (because the failure pops up easily when you run your tests), in which your test no longer matches the updated design. Do not forget that the process of redesigning involves updating your existing tests. If requirements change, your old tests cannot be trusted anymore!

Here are a few pointers to articles specifically on testing in an Agile context.

  • You got my question right. I see this as a side-effect of agile. How can you ensure good quality of code after enormous number refactoring over-time. You can-not cast a chair into a table, it will not be as good as it could be. Can you link to some article that discusses this part of agile approach ? Commented Mar 16, 2012 at 10:28
  • @YugalJindle: At least you'll get something close to a table. The problem Agile tries to solve is delivering a chair when the customer wants a table (but you don't know that yet).
    – Guy Sirton
    Commented Mar 17, 2012 at 19:10

I'm handling it like this*:

  1. Build your code in small modules. If the modules are independent, you'll never need to modify existing code. New task=new module.
  2. Avoid intersection of old code and new code.
  3. Replace empty lines of code with new code.
  4. (do not refactor)
  5. (only write perfect code - no modifications needed later)
  6. (make adding new modules as easy as possible. If it takes longer than 1 minute to add a new module, it's broken)
  • 1
    What is perfect code? Why shouldn't you refactor? Replace empty lines of code with new code? I agree with number 6. As for point 1. There will ALWAYS be situations where you need to modify existing code. It's kind of a learning process. Code should be easily modifiable, not necesarily 100% modular.
    – Tjaart
    Commented Mar 18, 2012 at 0:38
  • @tp1: How long have you been programming?
    – Jim G.
    Commented Mar 18, 2012 at 8:08
  • @jim g.: since I was 8 years old. :)
    – tp1
    Commented Mar 18, 2012 at 14:38
  • @Tjaart: Perfect code is something which uses all your knowledge about programming to find best possible combination of language primitives for the situation. Replacing empty lines with code allows "modifying" existing code without breaking old functionality - even if you didn't have unit tests; think of adding a new case to a switch-case -- it's a modification that is unlikely to break any existing functionality.
    – tp1
    Commented Mar 18, 2012 at 14:45
  • @tp1 Unless you're lazy, you are always using all your knowledge about programming to find the best possible solution. I often have multiple refactoring and redesign passes on the same code. Every new task shows me how the base of the solution should be, so the whole system evolves. As time passes less and less changes to the foundation become necessary. I see it like sculpting and not building.
    – Tjaart
    Commented Mar 18, 2012 at 16:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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