We set up a Scrum area on the wiki. It had hierarchical structure:
- Sprint 1
- Sprint 2
- Sprint n
- Sprint Contract
- Product Backlog at start of sprint (xls and pdf, as sent to the customer)
- Status Overview from the Planning Meeting (current burndown chart, estimated resources for next sprint, definition of done, time/location of next demo meeting, etc.)
- Sprint Backlog at start of Sprint (pdf - this is the actual contract)
- Daily Scrum Spreadsheet (xls - updated daily)
- Status Review from the Demo (stories/points accomplished, costs etc)
- Sprint Stories
- Story 103 Some story -> all project documents related to that story
- Story 105 Some other story
- Story 106 yet another story
All other documentation gets uploaded into the corresponding task for within the Sprint. Confluence had a very nice feature that it would take first sheet in the daily scrum .xls file and display it directly in the browser from a Wiki page, saving the media break of having to download the spreadsheet and opening it in a dedicated program.
The advantage of this approach is self evident: you have these tools and you know how to use them (well, actually we had some user acceptance issues with the wiki). A spreadsheet is very flexible, so you can slice and dice the data as you see fit. Data reuse is not a problem per se. Backup is handled by whatever mechanisms you have in place for your PC. (You do have a backup, don't you?! If nothing else, copy the data to a memory stick and store it separately from your PC).
The wiki requires a lot of discipline so that you can find things. The basic Scrum flow was relatively easy, but data which did not obviously belong to a single sprint were always somehow special cases and finding them later was hard. A good search tool is a prerequisite for using the Wiki.
What finally drove us to a tool based solution was the need for a better tool manage the product backlog. The Wiki was too inflexible as a data structure and the spreadsheet was too flexible. The customer, when he had the data, could too easily change the structure of the spreadsheet. Assuring the quality of the input was a problem and we had "file locking" problems: Either the customer could update or we could update, but we could not see changes made be other until we got the spreadsheet back, nor could we update unless we had agreed with the customer that we had the writable copy.
[Previous: Managing Scrum with Paper and Cards]
[Next: Managing Scrum with Dedicated Tools]