Skip to main content

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]


Michael Dubakov said…
Dedicated tools is the only option for remote teams and viable solution for large collocated teams. But dedicated tool should satisfy the following requirements:

1) It should be web based (desktop tool is a nonsense for remote teams)
2) It should be flexible enough to adopt (team should not look for workarounds in general, especially for fundamental things like release/iteration planning)
3) It should support data flows (Web Services API) for integration with existing development tools

Dedicated tools is a heavy artillery. Often it may be an overhead for small teams, so beware!

If you need more formal process for any reason (remote team, customer requirement, projects visibility) dedicated tool is likely the only way to go. And definitely TargetProcess is the best dedicated agile project management tool I am aware of :)
Dusan Kocurek said…

We are using scrum management tool not only for distributed teams. Results can be good even the team is small. Yeeh, task board on the wall is great. It is perfect because is visible all the time, you don't need to read manual :).

But I'm talking about burn down charts calculation, about integration, planning process support with knowledge of previous progress and history tracking.

I don't think that "it should be web based". Today's technologies enables to use "nonsene desktop tools" in same manner as a web with better UI and performance.

In my experience only few customers requires API to integrate with existing tools. For them it is just another cost - time and money. More preferred is included integration or modification to company's environment.
Daniel Ferenc said…
Our teams are using ScrumDesk (

It is a virtual task board as many other tools.
But, this tool use little bit different story cards look and feel which is good for many stories planned for sprint.
Reports are calculated and visible in one place which is very good for stand up daily meetings. We are using our long-time used bug tracking Mantis inside the tool plus SharePoint for project documentation.

ScrumDesk's SideView provides easy and quick access to sprint and project status.

Also, don't forget retrospective. Good tool integrates retrospective process. Management can easy recognize what is best for development teams.
Michael Dubakov said…
C'mon, you mean WebEx or tools like that? Performance will be bad for sure and overall user experience baaad. Usual web based tools are tending to migrate to SaaS and desktop apps will not survive in the long term.
Adam Feldman said…
I am one of the Founders of Bright Green Projects. I love using a white board and post-it notes early-on in a project, but your team can grow out of these tools as your project matures.

A dedicated, web-based Agile Project Management Tool is almost essential for non-colocated teams. Other times we have found our Agile Project Management Tool most useful is when;

*Team members work on multiple projects
*You have a long product and sprint backlog
*An audit trail is important!
*Reporting and detailed monitoring is needed

Popular posts from this blog

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…

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…

10 Warning Signs, that your team is not self-organizing

How do you know that self-organization is working? The Bern Chapter of Scrum Breakfast Club looked into this questions, and identified the following warning signs (which I have taken the liberty of translating).

The team reports to the Scrum Master at the Daily ScrumPeople wait for instructions from the Scrum MasterTeam members don't hold each other responsible [for their commitments]The same impediment comes up twice"That's the way it is" => resignation"I" instead of "We"Flip charts are lonelyCulture of conflict-avoidanceDecisions processes are unclear, nor are they discussedPersonal goals are more important than team goals
To this list I would add my a couple of my favorites:
you don't see a triangle on the task board (not working according prioritization of stories)after the daily Scrum, people return directly to their desks (no collaboration)there are a least as many stories in progress as team members (no pairing)
P.S. You can join the …