Skip to main content

Managing Scrum with Wiki and Office

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.

[Previous: Managing Scrum with Paper and Cards]
[Next: Managing Scrum with Dedicated Tools]


Michael Dubakov said…
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!)
Unknown said…
I'd recommend using Google docs - u can have an online spreadsheet that everyone can edit live at the same time, works really well.
Peter said…
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.

Popular posts from this blog

Sample Definition of Done

Why does Scrum have a Definition of Done? Simple, everyone involved in the project needs to know and understand what Done means. Furthermore, Done should be really done, as in, 'there is nothing stopping us from earning value with this function, except maybe the go-ahead from the Product Owner. Consider the alternative:
Project Manager: Is this function done?
Developer: Yes
Project Manager: So we can ship it?
Developer: Well, No. It needs to be tested, and I need to write some documentation, but the code works, really. I tested it... (pause) ...on my machine. What's wrong with this exchange? To the developer and to the project manager, "done" means something rather different. To the developer in this case, done means: "I don't have to work on this piece of code any more (unless the tester tells me something is wrong)." The project leader is looking for a statement that the code is ready to ship.

At its most basic level, a definition of Done creates a sh…

Explaining Story Points to Management

During the February Scrum Breakfast in Zurich, the question arised, "How do I explain Story Points to Management?" A good question, and in all honesty, developers can be an even more critical audience than managers.

Traditional estimates attempt to answer the question, "how long will it take to develop X?" I could ask you a similar question, "How long does it take to get the nearest train station?

The answer, measured in time, depends on two things, the distance and the speed. Depending on whether I plan to go by car, by foot, by bicycle or (my personal favorite for short distances) trottinette, the answer can vary dramatically. So it is with software development. The productivity of a developer can vary dramatically, both as a function of innate ability and whether the task at hand plays to his strong points, so the time to produce a piece of software can vary dramatically. But the complexity of the problem doesn't depend on the person solving it, just …

Scaling Scrum: SAFe, DAD, or LeSS?

Participants in last week's Scrum MasterClass wanted to evaluate approaches to scaling Scrum and Agile for their large enterprise. So I set out to review the available frameworks. Which one is best for your situation?

Recently a number of approaches have started gaining attention, including the Scaled Agile Framework ("SAFe") by Dean Leffingwell, Disciplined Agile Development (DAD), by Scott Ambler, and Large Scale Scrum (LeSS), by Craig Larman and Bas Vodde. (Follow the links for white papers or overviews of each approach).

How to compare these approaches? My starting point is Scrum in the team. Scrum has proven very effective at helping teams perform, even though it does not directly address the issues surrounding larger organizations and teams. An approach to scaling Scrum should not be inconsistent with Scrum itself.

Scrum implements a small number of principles and constraints: Inspect and Adapt. An interdisciplinary Team solves the problem. Deliver something of va…