Can agile scale? Absolutely. We are going to take a look at project portfolio management for agile teams.
Program managers, this blog series is for you. You’re charged with being on top of everything going on at your company. You’ve got to keep executive stakeholders aware of what’s going on, and keep tabs on all the teams you’re working with. Agile can help, because it enables your organization respond to change. It works at higher levels in the organization when applied at scale correctly. To be agile at Atlassian, program managers use Jira, Jira Agile, and Confluence as our main communication tools.
Some readers may see similarities between this blog series and the Scaled Agile Framework (SAFe). I don’t want to align this series too closely with SAFe, as Atlassian products are platform and methodology agnostic. The techniques described here can be used flexibly within your organization.
As the backdrop for these articles, I’ll be using Atlassian’s sample company, Teams in Space – a new company that’s revolutionizing space travel for teams.
First, let’s take a look three levels of hierarchy in an organization:
Focus on epics
An epic is a very large user story (congruent with features in SAFe) which get deconstructed into smaller user stories that can be delivered by the team. Epics can be key features, product themes, or any large area of work. Great epics are easily communicated by their title. Remember though, epics do not roll on forever; they are scope bound, and need to reach “done.” (If you’re interested in managing a set of user stories contained in an epic with a single team, check out our working with epics documentation.) Epics can be cross team, and involve multiple Jira projects.
In this article we will look at the project level (a single color on the chart above). At our sample company, Teams in Space, there are two different engineering teams working on a shared software platform: the web team and the mobile team.These two engineering teams makeup the software business at Teams in Space. How can we create a view with Jira Agile so that the stakeholders can follow the progress of the software team?
Plan your workflow
In Jira, epics are an issue type that can have a custom workflow. At Teams in Space, our epics flow through five states: to do, ideation, ready for development, in progress, and done. I set up the workflow using global transitions so that issues can be moved between any state freely. We didn’t feel the need to force a tight workflow, so teams can flexibly work with their epics. Epics don’t change statues frequently, so they don’t need to be as tightly controlled.
Set a base filter
Most of the time, boards in Jira Agile are based on a single project. In this case, we want to track epics between two projects. Let’s create a filter that returns epics from both the Teams in Space core project, and the mobile project. Ensure that you sort by rank so you can prioritize epics against one another in your agile board. Just like stories and bugs, at this level, epics need to be prioritized against one another.
[cce]type = epic AND project in (“Teams in Space”,”Teams in Space – Mobile”)
ORDER BY Rank[/cce]
Once you have a filter, share it with everyone who wants to follow the project.
Now that we have our filter, create a kanban board based on that filter. This kanban board will be the primary view highlighting the progress of both teams. Create a column on the board for each state in your workflow.
When done correctly, epics from both teams should appear on this board. I’ve used swimlanes to separate work between the mobile and web teams with labels. I can also tag each epic with a theme that becomes a label in Jira
Let’s look at the configuration below:
Seeing detailed status
Sometimes stakeholders want to drill down into a particular epic to see its detailed status. With Jira Agile 6.3, agile concepts are fully integrated inside of Jira so you can see agile information inside the detail view (below), and query agile data with JQL. Let’s take a look at Teams in Space’s large team support epic inside of Jira.
There are four main areas to gather information on this epic.
- The people section – The people section in Jira provides context around who is involved in this epic.
- Assignee – The person who is responsible for delivering this epic. The assignee is usually an engineering lead.
- Reporter – The person who owns the business ask for this epic. The reporter is usually a product owner.
- Sponsor – Some teams like to track an executive sponsor at the epic level. They can add a custom field for this value.
- Issues in epic – This section lists all of the user stories for the epic. Jira provides up-to-date information about each user stories contained within this epic.
- Description – The epic description contains a high-level business justification for this epic. I recommend providing a link to the epic report so that stakeholders can quickly get a status on progress for this epic.
- The agile section – Epics rarely live alone on an agile team. Click view on board to see this epic in context with other priorities the team is working on.
Looked at together, these four sections give a full description of the epic. You see the people involved, work required, business rationale, and how it fits in the context of other business priorities.
Communicating detailed status
Stakeholders often want to know when a particular epic will be complete. The epic report in Jira Agile gives a detailed view of progress on that particular epic. Providing a link in the epic’s description enables complete transparency on the team’s progress for that particular epic.
As a team, I would focus on the number of unestimated issues as they represent unknown scope in your project. Stakeholders in the project can track completed story points alongside total story points over time. Seeing total story points creep up over time? Stakeholders and the team alike will want to understand why – perhaps dreaded scope creep, or maybe the team is just making better estimates.
Make requirements come alive!
I wanted to toss in one extra tip for working with individual teams. Program managers often have difficulty keeping everyone abreast of status. Savvy program managers, just like savvy developers, look for ways to automate their job. Many agile teams use Confluence to manage requirements. With the new product requirements blueprint it’s easy to create templates that encourage best practices within your organization. Rather than duplicating requirements for an epic in Confluence and Jira, you can use the Jira issues gadget in Confluence to pull in all the user stories for an epic.
As the dev team completes user stories, everyone else can follow and see engineering in action. This tip requires Jira Agile 6.3 as it integrates agile concepts fully into Jira.
In review
Let’s review the hierarchy of work we saw in the beginning.
Each level can be tracked with Jira and Jira Agile.
- Individual epics – In scrum boards it’s easy to filter by epic in plan mode. You can also see the epic in Jira’s detail view by going to that issue directly.
- Team view – Each team should have a scrum or kanban board that corresponds to the work that team self organizes around with a product owner.
- Multi project view – In this lesson we used a kanban board to track epics across multiple teams. As the nested teams complete work, the project view stays up to date with the latest status.
- Portfolio View – Glad you asked, keep reading!
What’s next?
In this article we focused on tracking the epics across a number of teams in a small business unit. In the next article will focus on scaling that technique to track investments across a large organization.
Have any tips from the trenches in your organization? I’d love to hear what works for you!