Managing Scrum with Dedicated Tools

…So we started hitting limitations using spreadsheets to manage the Scrum process. What did we look for in a dedicated tool?

First we wanted to manage user stories, the product backlog, the sprint backlog. We wanted to record the conversations with the customer about stories. We wanted to keep information about a story (e.g. the results of an analysis, draft screen designs, test results etc.) together with the story. We wanted to be able to access the information from our office, but also from our customer site or while sitting in the train between sites.

I think the integration of the entire planning and development process is the major arguement for a dedicated tool. You enter stories, maybe group them into Features, Projects or Releases. Then you estimate and prioritize them. Then they are assigned to a Sprint (maybe a team member too) in the course of the Sprint Planing. The team (or a developer) breaks the stories down into tasks.

A virtual Task Board let’s you see at a glance how work is progressing on the sprint. The team members’ dashboards tell them what their top priority tasks and stories are.

Test features let you create tests which can be associated with one or more stories. Combine test cases into test suites, then peform test runs against a particular release or version. Record and report the success or failures (you did define the tests before starting to develop, didn’t you?). Integration with Subversion or other source code control mechanism let’s you associate modified files with particular stories or bugs. So if you ‘fix’ something, but something else breaks, it is relatively easy to identify what could have caused the problem.

Help Desk functionality lets you take requests from your customers or users, convert them into bugs or stories (or just send a response back to the originator).

In short, you get support for an integrated process (Lean Principle At Work: Eliminate Waste, in particular, searching for information), starting from preparation through deployment and operations.

What is the downside of an online tool? Mostly reduced flexibility compared to cards. A physical taskboard is a much effective Information Radiator than a web page. And cards are extremely productive for the kind of group work that occurs in Scrum – brainstorming stories, sprint planing and the retrospectives. A program structures information the way it was designed to. If your needs are different or simply not envisioned by the tool, then you have to figure out a work around. With cards, just write what you want and pin it on the wall where it goes.

Home Grown Tools

By the way, we did consider home grown tools. If you buy something, you invest money to save time. If you have more time than money (or if the products out there really don’t do what you want), you invest time.

My team decided that this was not a good trade off. We would not be able to invoice the time to build the tool. The author is a single point of know-how loss (This point was confirmed when the author of the home grown tool we decided not to use decided to leave the company). The tool will do exactly what we want, but if we want it to do more, we have to invest more time to make it do more.

An active community or a support contract means (or at least should mean) the product will do more next year than it does today, without your having to do something (except install the upgrade). If your development effort is trivial, then this issue doesn’t really apply. But if your effort is substantial, well, be sure to think about where you are going to get resources to meet new requirements on the tool.

[Previous: Managing Scrum with Wiki and Office]
[Next: Managing Scrum with Traditional Project Management Tools]