If you were/are shopping around for your team’s next tool for managing the work, what are the table-stakes capabilities you’d be deciding on?
Assume user-story stack ranked workflows. After that, what else?
2 Likes
The biggest pain I'm trying to solve right now for myself is honestly the vertical height that a card takes up in an Asana column. Right now every single column in the Asana board looks full to bursting since it overflows the page. When I pine for tracker, which I only do on days that end in 'y', the whitespace is a huge part of what I pine for. Is there a lot of pointed backlog? Are there a lot of stubs that need fleshing out? Once I've installed red labels, is there anything that needs immediate attention?
A tool that solved that for me - that let me get great situational awareness with a single screen that gives a good overview of a project - would motivate me to switch.
4 Likes
Assigning story points to stories, tracking velocity and allowing you to set a release marker which uses historical velocity to indicate whether you’ve got a chance of hitting it.
2 Likes
Speed and simplicity*.
A tool that developers on the team find to be low friction, and ideally valuable to use for their own needs (e.g., quickly updating the status, jotting down notes to self and/or for their immediate collaborators).
Not to say that the needs of other roles don't matter (product managers, designers, etc), but my sense has been that the more friction for there is for developers -- either in the form of unnecessary clunky features, or lack of responsiveness of the app itself -- the more likely the tool itself will be avoided or the team will see it as a burden rather than a tool.
* this may be a bit of a loaded and unhelpful term in of itself. Hopefully the elaboration helps a bit.
1 Like
You’ve probably already thought about all of these points but here’s my take anyway.
The critical one is honesty. Or the capabilities that mitigate against humans who may, deliberately or otherwise, try to obfuscate the truth and ensure that what any team sees, no matter how they use it, is the honest truth of where they're at right now. So when I assess a new project management tool, I’m looking for things that aren’t there. For example:
-
Users should not be able to set a priority field on backlog items and risk there being unclear, conflicting, or diluted priorities. Anyone should be able to to easily understand what is the 1 most important thing for me right now. That's why a single stack-ranked list works.
-
Users should not be able to input delivery estimations (dates) and risk creating gantt charts. If the tool provides delivery estimates, it should be based on data or things that people can reliably assess – average velocity, relative complexity estimations, and team strength. If I see a gantt chart or a priority field, I ain't buyin'.
Important capabilities that I would look for:
-
Users should be able to easily understand the delivery status of anything. Users should not have to write a damn query. Kanban boards are usually the easiest way to visualize this, but then priority can get lost. I loved how tracker had a single priority list but also grouped by status at the top of the backlog. Because if you start work on something further down the list, it implicitly becomes the next highest priority. As part of understanding status, users need to be able to understand the workflow and blockers:
-
Users should be able to easily understand what is blocked and what it's blocked by so that they can plan their work around it. I always struggled a bit with this in Tracker trying to remember what the black or red arrows mean and trying to dig into what the blocker was.
-
Users should be able to quickly and easily understand the workflow for an item. I thought having 1 opinionated workflow like in Tracker was good because there were strong reasons for it – if a team didn't want to have a delivery step they could skip through it. But maybe there were some missing steps that some teams may need to enable before they can adopt it. I felt the reviews/design reviews feature in Tracker was clunky. For most teams, todo, in progress, done could be enough but it doesn’t encourage any quality control steps. On the other hand giving users full customization of workflows just ends up messy and confusing. Maybe there’s a middle ground.
-
-
Users should be able to add collaborators. Rather than setting a horrible matrix of permissions
*jira ahem*. It’s important to be able to see histories on backlog items to trace what changed and by who so that users know who to go to for context. Transparency encourages honesty. -
Users should be able to demonstrate to their team and stakeholders how changing the priority of the work impacts delivery so that they can make better informed decisions.
-
Users should be able to make projects private or very hard to find. My assumption is that this would be necessary for adoption in a lot of places.
If you give me all these 
then take my 
.
Nice-to-haves that teams can create workarounds for:
- Item types – we could have agreements on what to put in the summary to relect features/tasks/bugs
- Attachments and documentation – as long as there's a way to write a description for each backlog item then you can include links to any other documentation or files
- Analytics – this can be tracked manually on a spreadsheet
- Subtasks – this can be tracked somewhere else
—-
For context, I was a Pivotal Labs product manager in Singapore for a few years. To manage projects, I’ve used physical whiteboards, virtual whiteboards, Trello, redmine, github issues, Jira (extensively, including a lot of configuration and development of plugins to hack it how I want), Linear, maybe some others, and of course Pivotal Tracker. I have not tried shortcut or clubhouse yet.
What I miss about Tracker is its opinions. That’s something that seems distinctly lacking in these Jira-in-hotpants tools like Linear - it feels like they’re giving us what we think we need, not what we actually need. The Homer Simpson car. The reasons behind those Tracker opinions were probably not very clear to anyone who did not experience a Pivotal Labs engagement, but once you understood them, and realized that they forced focus on the right things, the tool got out of your way and helped a team to just work on delivering.
2 Likes
To answer two questions:
- What is being on right now, and whats next?
- When will it be done?
The second is what Tracker called "emergent iterations", basically given a teams velocity and points assigned to a story, place iteration markers automatically, or show in RED a fixed release marker with a release date that is unlikely to be hit given the points to be delivered preceding it.
3 Likes
Additionally, would like some extra stages post "done".
- Is it in production? This would (ideally) be a short list if releasing regularly, but would help show teams who have "done" but not "released" work to fix that.
- Is the feature verified, i.e. did it have the impact we thought it would. This could be a long-running watch, taking weeks or months to see if a story (or maybe an epic might be better) had the desired outcome, which is separate from the build and deliver cycle.
1 Like
It's wild to me that this remained an extension rather than a feature. I used it so habitually that I sometimes forgot that it wasn't what everyone was experiencing.
2 Likes
My hypothesis is that the value for Product Managers and other stakeholders is a function dominated by the extent to which implementers live in the tool. Implementers live in the tool to the extent that it provides constant value and doesn't repulse or distract them.
A really good coordination tool is making a bid to be open and maybe even visible all day every day for all members of the team, open at standup, open in planning meetings, maybe even open in retros. Almost everyone not working off the backlog needs it to be valuable to those who are working off the backlog in order to get their own value out of it, but this isn't something they're necessarily aware of.
You see this in PMs or whoever bothering people to "update their tickets" or whatever. While Pivotal teams occasionally did in fact need to work on Tracker discipline, it wasn't this habitual haranguing I see and hear about elsewhere and elsetool.
1 Like
I really like that way of putting it. The value I get as a PM is really about the value the team gets.