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

1. 1. 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.

1. 1. 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.

1. 1. 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.

1. 1. 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.

1. Make sure stories are easily readable – Two different issues. First is if teams take the long route and make story titles too long making it difficult to skim read the backlog. The other issue (and more common) is if they are too short or filled with technical jargon that fails to express anything about what the story aims to get done. While the backlog is largely for the team, it is also used by the Product Owner, stakeholders and occasionally executives, so teams should make sure that at least the story title is easily skimmable and readable by the larger audience.

6. 6. Tag stories that are technical debt – Tagging stories becomes really useful after teams have completed multiple releases and want to use metrics to guide process improvement. The first tagging worth introducing is on technical debt which can be used to serve multiple purposes. First, it creates accountability to the tech leadership to make sure that this debt is expressed in the backlog. Second, you can monitor and adjust the team’s governance if the product owner fails to prioritize technical debt.

6. 6. Test out of the box reporting early – All the agile tools that I’ve used have limited reporting capabilities but provide provisions for developers to enable more advanced reporting and analytics. The problem is programming the more advanced reports requires development time to build and support, so you only want to invest in this level of reporting when it’s needed. That means, you’ll want to rely on out of the box reporting wherever possible, but these reports typically have built in assumptions on what fields you are using and how you are using them. So it’s best to test basic reports like sprint burndowns, release burndowns, defect reports, etc. as you configure the tool to make sure your implementation isn’t limiting you from using them,

6. 6. Develop a filtering strategy and standard – As you get more advanced in agile practices, your sprints and backlogs will get filled with many issues beyond development stories. You might have non-developers taking on tasks, defects being worked on, estimating in progress and that will make it more difficult for individuals to work efficiently with the tool. The tools I’ve seen all have filtering mechanisms to enable personalizing views (show me only stories assigned to me) or other forms of filters (what tech debt is being prioritized? what is being estimated?), so it’s best to enable fields and filters early in your roll out process so that they become standards across projects.

6. 6. Enable some experimentation – Even when you have multiple development teams, it’s unlikely they will be practicing agile in a complete uniform way. It’s equally likely that individuals on the team might discover new ways to leverage the tool that can lead or establish a standard for other projects and teams. So while standard implementations are necessary, don’t box out some forms of experimentation.

6. Involve the whole team – In my experience, there’s usually a few developers that take ownership of the implementation and push the practice and tool configuration forward. Unfortunately, even when there is leadership by example, there are team members that are slower to adopt. So make sure that as you advance the practice and mature use of agile tools that you also take steps to bring the team forward together. Why is it important to record defects in the tool? Why should you add comments daily? How and when should you utilize specific reports?