Question

Planning is very difficult. We are not naturally good at estimating our own future, and many cognitive biases exacerbate the problem. Group planning is even harder. Incomplete information, inconsistent views of a situation, and communication problems compound the difficulty.

Agile methods provide one framework for organizing group planning--making planning visible to everyone (user stories), breaking it into smaller chunks (sprints), and providing retrospective analysis so you get better at planning. But finding good tools to support these practices is proving tricky.

What software tools do you use to achieve these goals? Why are you using that tool? What successes have you had with a particular tool?

Was it helpful?

Solution

OmniPlan

Mac OS X planning tool.

Pivotal Tracker

Useful even if you aren't doing "agile" development.

FogBugz

Incredibly useful and featured issue tracking.

I use these in conjunction. OmniPlan is great to lay out all the tasks that need to be completed and divide them among your team. You can setup critical paths (things that must happen for completion) and breakdown overall effort. Also great visually for management.

Pivotal is excellent for keeping up your development pace. If you fully subscribe to agile methodology it's excellent, but still very useful to track features, dependent components, and currently active status.

FogBugz provides an easy to use interface for non-programmers to submit bugs or feature requests and monitor progress. Issues that come in are evaluated and logged in Pivotal. Then they get moved into OmniPlan if it becomes a larger task with multiple components.

OTHER TIPS

We use Redmine -> http://www.redmine.org/

We log all our dev in there along with support calls so we can see how much time we have free to allocate to a sprint on our latest bit of development. It is useful because it ties in nicely with our email system and our Version Control System (Git in our case, but it works with others).

Easy to get going out of the box (written in Ruby, will run on most small servers) and with some fairly powerful addons which are easy to install and use.

Is it ok to answer none?

You seem to imply that software tools are required for successful agile planning. I don't agree. If your team is using scrum or XP correctly ("by the book"), you shouldn't have to use any software tools at all for planning.

In many cases, adding software tools to an agile process is just a way to avoid having to deal with the actual underlying problem related to poor communication or trust. Such problems are best solved by other means.

My recommendation is to start without any digital tools and only add them later when you really understand why you need them.

(Distributed teams are a special case)

I've used both Rally and JIRA with Greenhopper.

I'll start with JIRA. JIRA is an excellent bug tracking tool. Greenhopper is an add-on that enables teams to begin working with agile. Because it was not designed as an agile tool from the ground up, some of the processes feel awkward. The tool is also time consuming and hard to use. However, it is extremely customizable. In general, it feels like a tool you have to cram you agile processes into.

Rally was designed from the ground up to be an agile tool and it shows. It follows a lot of the agile processes extremely well and it complements the process. I've used this tool in an extremely agile organization and it allowed us to keep track of cross-team dependencies and complicated projects that involve several agile teams. Cross-team coordination is something other tools struggle with, but Rally has done this well. Also, Rally has an excellent web services based API. It allowed my team to write some custom software using Rally as our backend as well as generate some custom reports.

We use TFS for Source control and Work Item Tracking (unfortunately), and I use Telerik work item manager to help me record sprint plans and keep the taskboard in sync. If you're forced to use TFS then telerik makes it less painful.

We use an issue tracker called FIT (I work for this company as on outsourced contractor so it was my choice what to use). Fogbugz was expensive in comparison. It has a small footprint, web based, inexpensive and does the usual things. I looked at Redmine which is a wonderful package but management was uneasy about an open source package that was still bleeding edge.
For a tool like an issue tracker I didn't want to maintain it or upgrade it or customize it: I just wanted it to work right out of the box and stay that way.

Licensed under: CC-BY-SA with attribution
scroll top