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 :)
Anonymous 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.
Anonymous 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

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…