Managing Scrum with Paper and Cards17-06-2008
Managing Scrum with Dedicated Tools19-06-2008
For my first Scrum project, I consolidated all of the wish lists into one spreadsheet which became our product backlog. Initially, I had 4 columns: Name, Effort, Priority and Estimate. I quickly added a “reference number” column to make it easier to find individual stories.
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
The daily scrum spreadsheet had 4 Columns: team member, yesterday plan, yesterday was, today plan, and impediments. “Yesterday plan” I copied from the previous days’ “today plan’ column, the rest corresponded to the three questions of the daily scrum. I updated the spreadsheet every day, adding one sheet per day in the sprint, copying “today plan” into “yesterday plan” and updating the remaining fields according to the results of the daily scrum. Then I uploaded the file into the wiki. There are pros and cons to recording data this way (particularly related to its impact on the flow of the daily scrum), and today I would do the daily scrum differently, but the traceability was awesome.
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.