I often hear “My stories cannot be made small enough for one iteration. What can I do?”
In real life, I have almost never found this to be the case. The real problem is not “stories cannot be small enough for one iteration” the real problem is some combination of:
- Projects are staffed in a waterfall manner, so that all team members are not present for the whole project, and we are creating stories to match the expertise of the available team members in the various iterations.
- Developers do not want to “touch” a module, component, layer, etc. more than once.
- Designers do not want to evolve the design throughout the project, they want to “do it once and be done with it.”
- Database experts do not want to change the database more than once, they want to “do it once and be done with it.”
- Testers work on just certain parts of the system, so want to do all their work at once on that part of the system, rather than throughout the project.
A lot of these issues come down to an underlying aversion to rework.
There is a perception with small stories that the people on the team will be re-doing work throughout the project. This is true. This almost always happens, whether or not you do Scrum! The difference with Scrum is we acknowledge that rework will happen and we plan for it in a controlled manner.
Redoing, reworking, refactoring is a necessary part of software development to avoid code that becomes un-maintainable over time. Scrum teams become experts on refactoring code and databases safely (because they will do it often throughout the project), thus protecting the corporate investment in software.
Scrum is designed to mitigate the risk that we have made bad assumptions or not understood the stakeholders needs. Since this is the most common reason for projects to have problems, and since no one gets it all right the first time, we work on a little bit (one story), test, verify, and then make course corrections early in the project when mistakes are less costly to make.
The notion that rework is wrong comes from a mistaken belief that if we just are thorough enough, we will get it right the first time. This is almost never true. And so we spend far more time trying to avoid rework (and getting it wrong anyway) than we would if we just were to develop something and show it to the stakeholders to find out what needs to be fixed.
Geri