Don’t move onto the next user story before you know that the user story you’ve been working on is done. How do you know when a user story is done? I use the following check list:
- The code compiles.
- All the automated unit tests are passing and test coverage is between 85% and 100%. (Be guided by the need to provide tests for everything that could possibly break)
- The code has a simple design that uses the fewest classes and methods.
- The code is well factored and without duplication.
- The code is clean and structured to coding standards.
- The code is self-documenting and clearly communicates my intentions a the developer.
- The code is checked-in, integrated (and builds successfully).
- All the acceptance tests (automated with FIT ) are passing.
- The customer has verified that the acceptance criteria have been satisfied. I don’t wait for the end-of-iteration review. I like to get this approval as soon as possible after I’ve checked-off the items above.
2 Comments
Just a point of emphasis for those who are new to iterative/incremental development -- all uses of the "the code" above apply to ALL the code (the entire project), not just the code that was developed for a particular story. Team that just apply these rules to the bits of code developed for a story will end up with "one module per story" instead of a really good design.
Good point Keith. User stories should be developed within the context of the whole system and not as something that is bolted on. Keep an eye on the design of the whole system, particularly the parts that a user story touches, and don't be afraid to rearchitect and refactor existing code to come up with a better overall design.