You can’t get there if you don’t know where you are going.
Often, people will ask developers to add or improve a feature and give minimal details. If the developers start coding based on this incomplete information, chances are pretty high that the delivered code will not meet the customer’s expectations. These changes could also introduce bugs in the application. The developer will need to do lots of rework as additional feedback comes in, describing a little bit more accurately what the customer desired. Several back and forth rounds may occur, in an “agile” iterative fashion, causing extensive delays in the delivery of the final product. These delays will cause missed expectations and leave everyone unsatisfied.
Extended cycle times and rework are very costly. There is a better way. At the very least, each request should have its acceptance criteria spelled out in clear language. If the development team commits to having concrete details in their user stories before starting implementation, there will be less rework later on. Forcing the product owner to specify acceptance criteria before the developers write the first line of code will not eliminate all rework, but it should significantly reduce it.
If you know your goal before you start, and you are more likely to achieve it.
(Thanks to David Kidd for contributing ideas for this one.)
Today's Card 