Managing Scrum with Paper and Cards
17-06-2008Managing Scrum with Dedicated Tools
19-06-2008For 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.
[Previous: Managing Scrum with Paper and Cards]
[Next: Managing Scrum with Dedicated Tools]
3 Comments
The problem with Wiki and Excel is quite common. These tools are simple, but general. They do not have business logic behind, but provide frameworks to resolve simple data manipulation problems.
It is good, but what are the benefits? Wiki+Excel will not work in distributed environment and will not work for large collocated team s well. Concurrent access, real-time reporting, integration with other dev. process tools. It is just not there.
Maybe it will work for small collocated teams? Yes, sure. But for small collocated team I prefer tangible cards, white boards and markers. For me Wiki+Excel is a dead end. No benefits, more repetitive work to have all up to date, still poor reporting (take a photo of your white board and send to manager instead sending spreadsheet!)
I’d recommend using Google docs – u can have an online spreadsheet that everyone can edit live at the same time, works really well.
I used google docs to manage distributed testing once.
The customer had not defined test cases but had a team of testers. So we created a main sheet with the user stories to describe the function of the system. Then we cloned the sheet, one sheet for each tester, where s/he entered his/her test results. On the main sheet, we linked to the individual tester sheets, one tester per column.
For the limited scope of this problem, it worked quite nicely, was easy to set up and available across company boundaries, with no license fee.