Agile development : How to design your code for an iteration / Sprint?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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)