0 comments
Various 
So I had a discussion recently with a collegae about attachments to user stories. Attaching documents to the story isn’t bad he stated. I agreed, it adds up to the detail and clarifies the definition of done a bit more.
But recently it got me thinking because it conflicts a bit with some of the agile concepts:
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Eventually you already put things on paper and created documents instead of working software. On the other hand writing things down also let’s people think it’s already set in concrete because you wrote it down. Even if the document states it’s in “Concept” state. A stakeholder will look at it if it’s already had a lot of work into it and doesn’t want (on a personal level) you to alter it completely because he or she got a wicked different vision the next day. And also if you write it down and agree on it it becomes harder to respond to change. You need to update the document to reflect the changes because that’s what is the base start for development.
All this got me thinking about User Stories again. About the first and most important rule. The reminder for a conversation. If you stretch this concept a bit you can look at attachments to a story a bit different. What if you consider it always as a concept and throwaway prototypes? As the input for the conversation you will have when you pick up this story in the sprint? Can you even leave the attachments unpolished because you know the polishing will be done in sprint?
For now my conclusion is that attachments on stories need to be communicated towards your stakeholders and developers as only quickly made prototypes and as a start for your conversation. Nothing else. Not a specification. Only the level of detail needed to understand the story and estimate it within ranges.
What is your opinion about this?