Skip to main content

Managing Scrum: The Right Tool for the Job

So what is the best tool for managing Scrum? Well, it depends. It depends on you and your situation. Michael Dubakov recently asked When is a whiteboard a better choice? He proposes a decision matrix to evaluate the choices, based on a list of 9 criteria:
  1. Planning process
  2. Plan visibility
  3. Plan update
  4. Velocity tracking, Time tracking
  5. Burn Down Update and other charts update
  6. Communication
  7. Reporting
  8. People involvement
  9. Cost
Agile Tools Decision Matrix

I've captured Michael's Agile Tools Decision Matrix in a spreadsheet which you can download and modify to suit your needs. Just as an aside, he also stumbled upon a great name for cards, post-its and manual burndown charts: tangible tools. Even though he didn't really use it, I love it! It's succinct and correct, and the inherent advantage of tangible tools just jumps off the page - I will use the term moving forward. 

When to use tangible tools

Tangible tools are great for learning the processes and principles. Hung on the wall, they radiate information for all to see. They are extemely flexible for structuring and displaying information. Use them to get started with Scrum. Use them as long as you are happy with them.

I like to use tangible tools for initial planning (getting personae & and first cut at the user stories in a group workshop) and retropectives. In both cases the volume of information which needs to be permanently recorded is small and the flexibility and collaboration requirements for creating the information are high. I would also think about complementing a dedicated tool by hanging burn down charts on the wall: either printouts or manually maintained copies, especially if management is collocated.

When to use Office and Wiki

The use of office tools as a primary agile management tool appears to be on the decline. The dedicated tools are better.

Office tools are really good for slicing, dicing and presenting data. Dedicated tools can be great and do many wonderful things, but there is always something they won't be able to do or won't do the way you want it, and for that you need the flexibility of an office tool suite. So the data import/export is an important feature of these tools.

While using Target Process as a primary management tool, I have used Excel or OpenOffice to record the Sprint Contract, allocate costs between two parallel projects, and do preliminary scheduling. The Wiki has been useful for storing information about the project which does not readily belong to a story, feature, release or sprint (although this is a very small amount of information).

When to use Dedicated Tools?

When you need to. ;-) The advantages of dedicated tools range from information reuse, handling multiple or geopgraphically far-flug teams. A customer of mine wants to have one tool and one process for coorindate work and information flow across 3 suppliers.

How to decide for yourself

Start with Michael's Agile Tools Decision Matrix. Think about the importance of the various criteria. Perhaps there are others which are important to you. But feel free to tweak the weightings and the scores to get a result that you like. (uh - the politically correct phrasing is 'get a result that applies to your situation').

What do I do? I start with cards for teaching Scrum. I like cards for the initial concept and planning workshops and for the sprint retrospectives. I also use cards to manage my own work (just me planning my work a scrum coach and trainer).

Beyond that, I like web based tools. Available everywhere, even on the train. Manage workflows, find information effectively, reuse information. The bigger the project (and the longer the product should live), the more important these advantages. I think these factors explain the growth in dedicated agile project management tools over the last 18 months.


Scrum Tools said…
I personally found that the best tool for managing scrum is Excel. More recently i moved to ScrumEdge ( because it saves time when setting up.

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 …

Money for Nothing, Changes for Free

“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.

A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.

While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit.
Desired Benefit Incentivize both customers and suppliers to focus on functionality that provides genuine value.
Structure This works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budge…