4 ms·
I think there's two reasons to have a tool to track tasks: 1. To help ICs keep on top of what they need to do in a given week. I think your post is a great sum
by ryanbrunner 5y ago
I think there's two reasons to have a tool to track tasks:
1. To help ICs keep on top of what they need to do in a given week. I think your post is a great summary of that reason. The tool doesn't matter as much here - whatever has the least overall impact on developers is likely the best tool here. JIRA can be 'OK' at this, but it can very easily get slow or bureaucratic, largely due to -
2. To help communicate to stakeholders outside of Engineering. This can be a bunch of things - whether a project is on track, is the team performing more or less efficiently over time, are we managing the backlog appropriately. Sometimes this is a requirement imposed from elsewhere ("when will project X be done"), but sometimes it can be something that the engineering team wants to communicate to everyone else ("our bug backlog is becoming unsustainable and we'll hit a crisis point soon"). This tends to put pressure on reason 1 - whatever will give you more useful data for this is going to make actually using the tool more cumbersome. Over-emphasizing this tends to result in the JIRA nightmares everyone hates, but ignoring it leads to conflicts between engineering and other teams when they're viewed as unaccountable and haughty.
For me, the sweet spot is Shortcut (used to be Clubhouse) - it's a very smooth UX that gets out of your way, but still offers some pretty decent reporting and analysis, and doesn't let you get too crazy with overconfiguring things so it always feels pretty snappy and gets out of your way.