How would you document efficiently in Agile?

A User Story, which is a placeholder for a conversation about an evolving requirement, is a good example of just-in-time documentation, and it is often to be found in agile practice.

Hi Ian,

Great answer. I just would like to know more about using the user stories as a just-in-time documentation. For instance, when a developer needs to come back to the dropped story when trying to do some bug fixes, how they would efficiently find exactly what they need? I agree that a user story could be an extremely helpful communication stimuli for the team. More precisely how would you preserve a user story for further reference? I, for example, collect all the done stories in a sliding plastic panel shelf which have turned to be a very helpful asset to our low-tech documentation approach. I would like to know how you would do it in your organisation.

Looking forward to your reply…

I think a release plan would be a useful artifact to have. It could be updated atleast at the end of every iteration to help us see where the release is going. Our teams also write a specification dossier so that it acts as a reference for the maintenance team.

I work for a large organisation and we need this document to ensure maintenance irrespective of changes in supplier.

I know that it goes against the LEAN principle of avoiding "too many handovers" but this is an unavoidable situation for us. It is either updated during every sprint or after every two sprints.

We can have as many documents for ourselves as scrum masters, for tracking purpose. For example, I use a estimation tracker, where I log the scrum team availability in terms of hours and user stories considering their leave plans and other stuffs , which I can use it in sprint planning. and I also use a powerpoint in retrospective, which is used to document what went well, and the improvements - this stuff can also done using Jira or version one tool. again its all just for me. 

For team, we dont need any documentation unless its some technical stufss that need to be put into documents and share it sharepoint or with the team,. i am saying these because, I have used tools like Jira, Version one, where product backlog, sprint backlog, user stories(all scrum artifacts) are recorded with version control. so I dont think we need any documentation for team that will be helpful. only thing I see as documents is, defect documentations that has to be put into squids or QC. ok I may be totally wrong. I think I am. what you guys think the documentation we need for the scrum team?

> when a developer needs to come back to the dropped story

>  when trying to do some bug fixes, how they would efficiently

> find exactly what they need?

That would be the start of a new conversation for a new story. Perhaps the best way to trace the original requirement would be by the corresponding acceptance tests. However, there's nothing to stop a PO or the team from archiving old stories any way they like. They can also mandate that they be documented a particular way in the Definition of Done.