- Have you ever made the assumption that passing information by documentation was the best way to do it?
- Have you ever made the assumption that someone has read and understood the information in full?
The above summarises two of the problems with information passing. Comprehensive documentation can of course be improved with diagrams and structure, this is a good reason for the creation of UML. It is still reliant on the person receiving it understanding those techniques and reading it in full.
- Did you assume you’d made no mistakes in the documentation?
Even if we passed the information perfectly this doesn’t solve the problem of us making mistakes or omissions. How many defects do you find in your software? I doubt it’s zero! Now how many defects are in your specifications? How often do we assume they’re perfect?
A blind allegiance to documentation was the cause of many mistakes with waterfall off-shoring. We made companies sign up to contracts to build software based on documentation we provided then assumed it’d work!
- Agile uses stories and story point estimation to help solve this problem:
A story is starting point for a conversation, it helps drive out the detail, done properly it never assumes we know what it is. That is why the story doesn’t have all sorts of UML diagrams attached to it as standard. All those other diagrams can supplement the story as required.
The story point estimation is done as a team, all members of the team (playing planning poker for example) estimate on what they understand. If the sizes are not agreed the team members ask questions until they understand enough to agree them. If you don’t understand the detail don’t blindly agree!!
Finally the acceptance tests can then be put in place to clarify what the story means in business terms. This often uses the Given, When, Then format.