[dasmoth]

Most of these tools seem to exist more for the benefit of managers than hackers.

For small groups, I think I honest-to-goodness prefer TODO.txt in the top level of the relevant repository to any tool. Otherwise, GitHub issues is a pretty nice lightweight-ish tool.

Lack of an explicit model of a "sprint" (which often seems to be where formal process starts to get reified in these tools) is a big plus in my book.

[nrr]

I'll second this suggestion, but I want to add one more thing. I suggest also writing a number 0-9 at the beginning of each line in said TODO.txt that represents some degree of priority, whatever that might mean for your project.

If you do that, you're consequently allowed use of, e.g., `sort TODO.txt | head` to figure out what to work on for the week. In addition, you can add in a regular review cycle to re-evaluate priorities, and that's all then kept in version control with the rest of the project.

It also happens to tick the capital-A Agile checkboxes, and when you grow past the point where you have strictly hackers on your team, the lift to move to another, more manager-friendly project management tool isn't nearly as arduous.

[jespr]

Interesting.. yeah a todo in its simplest form is not a bad idea :)

When you say "explicit model of a sprint" do you think about the whole start-date, end-date kind of thing per Kanban board? Or is it the kanban board itself that sort of leads to this formal process?

[dasmoth]

Good question. Kanban isn't something I've particularly experienced, but I'd be willing to believe that a simple Kanban board might be a useful level of coordination for some people. Although my inclination is to say that if you need a mechanism to track which stuff is being worked on, you might have either too many people, or excessively fine-grained tasks.