- “That’s not how I read it”
- Versioning Changes
- Big complex software = big complex requirements = never read/hardly understood
- “That’s not what I heard or understood. That’s not what I remember.
- Hallway conversations, informal clarifications that aren’t heard by all parties.
- Complex requirements can’t easily be remembered, conveyed through conversation alone.
- Change management is non-existent.
- Software and business teams change…..leading to a loss of highly valued historical domain knowledge that may or may not be documented in the code or the story.
- An awful lot of time is wasted writing these down, editing them, and then clarifying the exact meaning.
- It’s a fine line. How much to write? How much to discuss? Too little and the story is worthless. Too much and we’re back to writing all our requirements.
- Complex business domains and logic need to be documented in detail. A simple story ( or many simple stories ) with acceptance criteria may not be enough. Think about requirements for the Boeing 787 flight control system.
- User stories assume the business owner will be available ( static ) for clarification during much of the project: not a safe bet.
- The historical integrity of that requirement conversation ( and its vision ) would be preserved for any future teams to review and understand it….nuance and all.
- Verbal as well as non-verbal communication would be preserved and could be analyzed later for better realization of the requirement.
- Whiteboarded artifacts could easily be recorded and saved along with the video. Adding to a thorough documentation of the conversation.
- While this wouldn’t completely eliminate the need for clarification of requirements; it could sharply reduce it.
- Productivity in requirements gathering and recording could potentially jump helping out the entire software development process.
About the Author
Christopher R. Goldsbury is a software development professional who has played the roles of developer, architect, scrum master, development manager, project manager and quality assurance manager throughout his career. Chris writes on his experiences and ideas at his blog: http://www.anagilestory.com.