Managing Feature Backlogs

What techniques and tools do you use to manage your feature backlogs?
It could be as low tech as a post-it note, TODO file in your Rails
project tree, or as high tech as a web-based collaborative tool.

Thanks,
Mark

Mark -

We're using a Google spreadsheet, with a lot of rules and formulas.
Low-tech, but it works well enough.

Jodi Showers wrote:
[...]

we use redmine - http://www.redmine.org/

and as a rails project, you can tune to your needs

I do too, with some of the Agile Alliance plugins thrown in. It's not
perfect, but neither is any other tool I've found.

Mingle is great when it works, but it's expensive if you're not using it
at the free level, it's trouble-prone, and ThoughtWorks' support is a
joke.

Jodi

Best,

Pivotal Tracker -http://www.pivotaltracker.com - is a good tool.
It is hosted, which may be a good or bad thing depending on your view/
needs. (It's also a RoR app hosted at EngineYard)

What techniques and tools do you use to manage your feature backlogs?

A combination of notes in the source code tree (TODO/NOTE/etc) and
Redmine or GitHub Issues. For personal projects I use org-mode (http://
orgmode.org/). I generally prefer to have these things available right
in my editor, when possible.

Mark A. Richman wrote:

What techniques and tools do you use to manage your feature backlogs?
It could be as low tech as a post-it note, TODO file in your Rails
project tree, or as high tech as a web-based collaborative tool.

Requests from the onsite customer go on index cards pinned to a cork board. In some circles this is an industry Best Practice. Using a more advanced system, such as a website, represents a failure to simplify your process.

Each card has a difficulty rating in the corner - 1 to 5, representing ideal half-days. That makes estimating a week's worth of stories easier.

I keep all engineering tasks in TODOs in my source, because that's usually where I am keyboarding when I think of them. I use this format:

  TODO must do this before this iteration (or downgrade to CONSIDER)
  CONSIDER this potential code improvement awaits activation energy
  FEATURE the client said to do this, and it should get an index card
  REVIEW I made a decision that I need the client to review
  STORYTEST this stretch of code would make for some good Cucumbering

I have a rake task which searches for those - rake todo, rake feature, etc, and I frequently run this and burn-down the count of outstanding items.

Phlip wrote:

Requests from the onsite customer go on index cards pinned to a cork
board. In
some circles this is an industry Best Practice. Using a more advanced
system,
such as a website, represents a failure to simplify your process.

Here I totally disagree. A list of tasks on a website is not
necessarily "more advanced" or a "failure to simplify". I find Web
interfaces that emulate these cards extremely useful: I'm.a freelancer
generally working with remote clients (and/or remote colleagues!). If I
were on a co-located team, I might feel differently, but even in this
case, I like to have a database in one place rather than a fragile array
of slips of paper (which I tend to lose). Paper story cards are great
for client brainstorming sessions -- but then they go into Redmine for
ease of tracking.

Best,