Managing Feature Backlogs

Rails
1

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

2

Mark -

On 12-Jun-09, at 1:38 PM, 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.

Thanks,
Mark

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

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

Jodi

3

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

4

Jodi S. 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,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

5

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.

6

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

7

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,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

8

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)

On Jun 12, 11:17 am, Marnen Laibow-Koser <rails-mailing-l…@andreas-