We’ve been doing a few inceptions in agile lately, and the question always comes up… how much work should be done for ‘this’ story? Well, you define your acceptance criteria, then you estimate your work based on that being completed and functional.
Honestly, there is so much more to it than that. There will always be acceptance criteria you miss out at the start, but perhaps you will cover the 80% of use cases. Perhaps you have to design a new pattern, so that other stories like the current one can be done quicker in the future, or perhaps you need to spike first because of the unknown estimate. Perhaps you need a 3rd party library to incorporate, so you need to wire that in and test it too.
Even in agile, I find myself asking, how much (or rather, how little) design is just enough? It really depends on the project. If the code is being rapidly developed, screens changing every day, database schema in flux, then perhaps you don’t want to do anything you don’t have to for that story, lest it be thrown away tomorrow and your efforts wasted.
Any developer hates the idea of their code being thrown away, it’s in our nature 🙂
Two areas I sometimes struggle with is a) only do enough to make the feature work and b) don’t think about things in the future. If you take b) as gospel, it means you will never refactor. I have seen developers go down this path. The code works, they iron out the bugs (with scant test cases) and it goes to production. They develop work quickly, but slowly but surely the code is polluted by duplication, wrong responsibilities in the wrong classes, or tight coupling due to bad design and/or lack of tests.
The begging question is how do you monitor this to stop it happening?