Hi, I am still new to the Scrum process and have been taking responsibility to write stories with the product owner. Since the software was released, there were no further documentation done on the how the released software works. The user stories and QA test scripts have the detail. Since I have been asked to produce documentation so that any person(Developer or non-technical person) can have access to documentation on how the system works, I am in a bit of a struggle on what to produce.

At the moment I am thinking of:

- UML diagram to show the overall context. Each use case links to a user story.

- Since the software contains UI, a website map.

- List of user stories and their link to the actual detail(We are using JIRA / Greenhopper)

- List of business rules related to features and link to user stories.

- Data dictionary which includes field name sizes and rules.

Question here is whether the documentation is too heavyweight ?The idea is to create a baseline of the software and when changes are required, we will then review the 'As is' and then determine what needs to change i.e.. Start another list of user stories indicating the change. During / after sprints I will update the documents based on what has been agreed / implemented.

Any advise on how you document after delivery will be appreciated.

Thanks,

Carl Oellermann

Business Analyst