Large organizations that transition to agile practices often get trapped between two competing principles:
- The agile principle of empowering self-organizing teams to solve problems on their own and to manage the collaboration in the team.
- The need for organizations to develop governance, standards, reporting, and key performance indicators that can be applied across multiple agile teams.
The two seemingly conflict. If you put too much governance or standards in place, you constrict the freedom of the team to make tactical decisions that enable its success. But providing too little guidance can make it difficult for new teams to adopt best practices or make it easy for a team to inadvertently put the organization out of compliance. Organizations without standards in place also don’t know where and how to manage agile teams that are going off course or may be underperforming.
Finding the right balance requires agile leaders to define where and how to apply consistent standards while still empowering teams to self-organize.
To do this, some organizations adopt standard frameworks to scale agile such as the Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), or the Squad framework popularized by Spotify. Many organizations develop their own practices around their objectives, culture, and logistics by adopting a hybrid of best practices and often using agile coaches to steer them.
In my experience being the “agile sponsor” in several organizations and then leading their agile transformation programs, I have found that one place to find aligned interest is in configuring the agile project management and collaboration tool. Teams would rather not have to invest a lot of their time configuring these tools, and they are usually open to standardized configurations if they are simple to learn and use. Organizations can then create standards and governance baked into the implementation as long as teams don’t find the implementation overbearing.
Here are some of my standards that I configure in Jira, Atlassian’s popular agile collaboration tool. Although my suggestions revolve around Jira, you are likely to find equivalent configurations possible in other agile tools.
1. Standardize conventions on defining epics, stories, and subtasks
Jira has a three-level hierarchy in which epics can contain one or more user stories and other issue types. Jira used the generic term “Issues” to reflect epics, stories, tasks, subtasks, defects, and other custom types the organization chooses to configure. Some teams then break down their user stories into subtasks and assign them to individuals.
Here are my guidelines on making the configuration and language useful across multiple teams:
- Epics should be themes that are relevant across multiple releases, and projects should be configured with a manageable number of active epics. Stakeholders should be able to review the backlog efficiently, and that can be done best with between five and 12 epics. Anything less and the epics may be overloaded with too many user stories, whereas creating too many epics requires more work scanning and scrolling to digest the project. Also, when epics are meaningful across several releases and months of development activity, reporting around epics is a lot more useful.
- Follow basic agile story writing guidelines and make story summaries consumable by product owners and stakeholders. It’s critically important to get business leaders active in the sprint process and to make the tools easy and efficient for them. They will rarely click into the details of a user story, so it’s important that the epic name and story summary be written in business- friendly language.
- Let teams decide whether and how they use subtasks. For example, subtasks can be useful for geographically dispersed teams, for teams that are new to working together, or when there is technology complexity to the implementation of one or more user stories. Under these circumstances, teams may want to use subtasks to get a shared understanding of who is doing what and when. On the other hand, more experienced teams that are colocated may find adding subtasks administratively overbearing and unnecessary to complete their commitments.
- Some teams need a fourth level of hierarchy, a “feature” that comprises multiple user stories and has an epic parent. This can be useful to help a product owner that wants a set of features completed in a release and wants an easy way to track it. It’s also useful to track feature improvements and costs associated with a feature.
Out of the box, Jira doesn’t support this added hierarchy but there are a couple of ways to implement it. You can do it with a custom Label or with the Select List custom field, but that requires some administration to maintain the list of features as options. The other option is to ask story writers to add a one- or two-word prefix to their story summaries separated by a delimiter. For example, “Login: Allow user to enter their email if they forgot their password” could be one story in the feature “Login” and in an epic “User authentication and authorization.”
The main thing leaders should remind team members is to make the epics and stories consumable to stakeholders who may not be looking at Jira every day.
2. Define convention for sprint names and versions
Defining standards on epics, features, stories, and subtasks helps communicate whatteams are working on in a consistent way. The next thing to do is to communicate whensomething is going to be delivered. The way to do that is with a sprint-naming convention and some guidelines on creating versions.
By default, Jira auto-numbers your sprints and creates separate sprints for each project. I believe it’s critically important to override the default and to have a sprint naming convention that assigns a consistent sprint number across all projects followed by the start and end date. For example, it might look like “SP 011 10-14 – 10-28,” to mean the 11th sprint starting on the 14th of October and ending on the 28th. This simple convention lets casual Jira users understand the timeline. It also means that sprint 11 is consistent across projects.
I prefer having one sprint that’s used across all projects, but this may not be practical if you have a very large number of teams. In addition, if you have multiple teams working in a single project, Jira’s parallel sprints may be useful.
Versions are best used when they correspond to actual production releases of software or other changes. My guideline to teams is to create versions as soon as they are conceived even if the team doesn’t know the full scope of what will be released or has a target release date. This allows tagging stories and other issues types to the version and enables using the release burndown charts earlier. It’s also important to create guidelines on version numbers, and semantic versioning is an easy one to use.
3. Agree on estimating standards
Once there are standards on whatthe team is working on and when, adding in estimating guidelines helps teams commit in consistent ways and business leaders interpret forecasts and roadmaps appropriately.
In my tutorial on how to do estimation the right way, I provide many basic guidelines on using story points and how to use them in reporting.
When working with multiple teams, it’s important to set guidelines so story points can be interpreted somewhat consistently. Organizations with multiple teams should adopt guidelines; for example, “One- and three-point stories should quantify only minor user interface changes with no changes to business logic or APIs” while 21-point stories might be “Any story that requires creating a new API and user functionality.” Teams can then define how to interpret a one versus a three-point versus a five-point story appropriate to their projects. For example, a team developing a Node.js application may further define its point definitions based on the guidelines, so a one-point story involves only user interface changes while a three-point story includes small improvements to front-end functionality.
4. Define a tagging convention to categorize Jira Issues
Out of the box, Jira offers labels and components to further categorize the stories and issues. Components can be used in various ways, but I like using them to represent different architecture components. For example, if a story requires changes to a Node.js component and a database, two components could be used to capture what aspects of the architecture has been affected. This may be useful to organizations that want to track and forecast the demand for specific technology skills, or to know what components are changing with a release.
Labels offer a less-structured tool for categorizing stories but can highly valuable when standardized across projects and teams. Consider labels like “technical debt,” “UX”, “performance,” and “security” that correspond to the types of improvements being addressed by the story. These can then be used to recognize when teams are making proactive investments in their application architecture and alert leadership on other teams that are underinvesting in addressing technical debt.
5. Align practices with standard reports and dashboards
There are plenty of other areas worth configuring in Jira to better align teams.
Most organizations will define one or more workflows to define how stories transition from a to-do state to a done state. Larger organizations and those that go through compliance audits must configure a standard for roles and permissions that is likely different than Jira’s out-of-the-box defaults. Some will configure additional issue types, screen schemas, and other customized fields that address organizational needs.
But organizations have to create feedback loops to help drive behaviors, and that can be done by standardizing the reports and dashboards that are used on a regular basis. Inside Jira, I tend to use the epic and release burndown reports. The velocity chart is useful for teams that want to make sure they deliver on their commitments, and the control chart is particularly useful for devops teams with CI/CD in place and conducting frequent releases.
Organizations can also look to Atlassian’s marketplace for third-party capabilities and integrations. For example, I use one integration to help link Jira data into Tableau to visualize burndowns and team velocity broken down by dimensions stored as labels and components.
The approaches I describe here shouldn’t impede your team’s ability to manage its commitments, sprints, story completions, and releases. But they do require some overhead to make sure epics, stories, sprints, and versions comply with standards, which can be managed by the scrum master or with a rotating responsibility across team members.
Agile leaders can use these standards to promote productivity and quality across teams while empowering them to manage internal collaboration, problem solving, and delivery.