10 Best Practices in Configuring your Agile Project Management Tools

organizational change
10 Best Practices in Configuring your Agile Project Management Tools
If you are serious about agile development then you most likely selected a tool to enable team collaboration and manage the backlog, sprints, and releases. While I have heard of some teams and even organizations staying low tech and using stickies, cards, or spreadsheets, it's really hard to scale to multiple teams, manage distributed teams, or develop metrics to support process improvements without an agile tool in place that is configured to match the practice.

I am not here to preach one tool over another and have experience using different products over my last three agile transformations .  However, I believe that whatever tool you select needs to be configured properly to match the release cycle, sprint schedule, and other practice standards. While the agile practices that I have used across three companies have slightly different mechanics to match the specific business needs, there are several best practices that I can recommend to everyone.

One team, one backlog - This seems obvious but can become more difficult when there are multiple product owners for different products that need to be fulfilled by the same team. Another issue is when resources with specialized skills are needed part time across multiple teams. While there are different ways to handle these issues from a process standpoint, it is often better to configure agile tools to handle the basics. Agile tools help teams commit and report on team productivity, so it's best to configure them so that the team operates off a single backlog. So for multiple product owners but one team, implement one backlog.

Backlogs must contain all work - There is one school of thought that the backlog should only contain Stories that embody product requirements. This is a purist viewpoint that keeps out other responsibilities and tasks outside the scope of the tool and potentially gives the team a false readout on velocity. A best practice is to include all commitments in the backlog and use the tools configuration options to represent them. For example, use Story Types in Jira to represent Feature Estimation, Decisions, Meeting Notes, and Tasks.
Normalize to a fixed capacity - Some tools enable you to record when resources are unavailable or only partially assigned to a specific team, while others don't have this capability. If you're going to track and improve team velocity, then learn how to use the tool you have to manage when resources are on vacation or unavailable. For tools that don't have this capability, a cheap option is to account for the missing capacity directly on the backlog so that out of office time is scheduled directly in the sprint.
Align Epics to the product owner - Most product owners that I've worked with don't have the time or technical skill to write stories and are usually expressing their requirements as Epics that are then broken down to Stories by business analysts and technical leads. When these product owner open the agile tool, they are more likely to review progress at the Epic level and only dive into stories when they need to review detailed requirements or better understand what part of an Epic has been completed. It's for this reason that the name, scope, and order of Epics are best aligned to the needs of the Product Owner.;