Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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. –  Yugal Jindle Mar 16 '12 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. –  Yugal Jindle Mar 16 '12 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. –  Yugal Jindle Mar 16 '12 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. –  Yugal Jindle Mar 16 '12 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 Mar 16 '12 at 7:01
show 1 more comment

3 Answers 3

up vote 2 down vote accepted

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.

share|improve this answer
    
Great.. @Ladislav Mrnka , you got the problem right. –  Yugal Jindle Mar 16 '12 at 12:00
    
Does SCRUM (And related tools) covers this aspect of the project ? –  Yugal Jindle Mar 16 '12 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. –  Ladislav Mrnka Mar 16 '12 at 12:10
add comment

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.

share|improve this answer
    
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 ? –  Yugal Jindle Mar 16 '12 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 Mar 17 '12 at 19:10
add comment

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)
share|improve this answer
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 Mar 18 '12 at 0:38
    
@tp1: How long have you been programming? –  Jim G. Mar 18 '12 at 8:08
    
@jim g.: since I was 8 years old. :) –  tp1 Mar 18 '12 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 Mar 18 '12 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 Mar 18 '12 at 16:37
show 2 more comments

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.