Scaling Agile with Jira
During my Summit talk, I discussed three enterprise challenges when scaling Agile; process and documentation culture, underestimation of planning effort, and managing a complicated infrastructure. There certainly is a lot to say on all three topics!
In this blog post, I would like to dive a bit deeper into the planning effort when scaling agile and how to track progress by using Atlassian JIRA.
As one of the few official Atlassian Enterprise Experts, we are often asked to help set up JIRA for Enterprise customers. The initial request is almost always to help them get started with JIRA Agile in order to support their Scrum teams. But Scrum only covers the development teams, not the rest of the organization. Almost always, one or more of the following questions pop up:
- How do I plan work across multiple teams?
- As a project manager/product manager/business manager, I want to track overall progress. How can I do that?
- Before the Scrum teams can start working I need to do some analysis up front. How can I track and plan that?
Although every situation is different and every implementation is different, all of the questions above can be addressed by using the Scaled Agile Framework (SAFe) as the guideline for our advise.
The SAFe framework discusses three levels of planning: portfolio level, program level, and team level. Each level has its own items for tracking: needs on portfolio level, epics on program level and stories on team level. The SAFe framework has many elements that are very important but in this post I want to focus on just the three levels of planning and tracking and how to visualize them in JIRA. The image on the right serves as a visualization for the context of this talk.
The portfolio level is the highest level of planning and tracking. This is implemented in JIRA with a single project. This project is configured with an issue type scheme that contains two issue types: business need and architectural need. Optionally you can add the type investment theme to reflect investments based on your corporate strategy.
Also create an issue link type named Implementation that configures a relationship between two issue types called implements and is implemented by.
On the portfolio level, portfolio items are managed according to a portfolio management process or project portfolio management process. This process should be reflected in a workflow that is assigned to the portfolio issue types and the portfolio project. You can visualize this workflow with a kanban board which is ideal to track progress of the portfolio items.
While the items on the portfolio level are put on a global roadmap that is planned for the coming year, analysis on the portfolio will result in epics that are placed on the projects, in the program level.
Epics typically belong to a system or a business service. Therefore the JIRA projects on the program level should follow this enterprise architecture of systems or services. I explicitly say JIRA project here to refer to the JIRA term of storing issues together in one container (another blogpost explains why the term project in JIRA is not so useful anymore.)
A JIRA project on the program level can contain epics, stories, tasks (e.g. refactor task or design task), and sub-tasks.
On the team level, the scrum teams plan their sprints with stories, tasks, and other work items. The easiest way to do that is with a JIRA Agile scrum board. The items on the sprint backlog are not limited to user stories only. Therefore estimation should not be limited to user stories either. By default JIRA Agile is configured with the Story Points field bound to only stories. This must be changed.
All the agile teams should have their own scrum board. Although it is possible to have one scrum board for multiple teams, this is not advisable. When having one board for multiple teams and thus having multiple active sprints, the sprint velocity is also shared and compared against other teams. Comparing teams is like comparing apples and oranges.
Scrum teams do not necessarily have their own JIRA project but use a specific issue filter to show all the items on the backlog from the different program level JIRA projects.
Of course, each level follows its own process. But each level has an interaction with the next level, as can be seen in the image on the left. Teams in one level are not “stand alone,” but part of the bigger picture and part of the entire process.
With the above setup of JIRA in larger organizations, it is possible to have full traceability from code to business needs on the portfolio level and back. Stories are linked to changes in the source code while they also link to an epic. Epics then implement a business need. But implementing agile at scale requires a complete package of tools. So to complete the package of JIRA and JIRA Agile, I would add Confluence (Atlassian’s enterprise wiki) and Stash (Enterprise Git repository manager) combined with a set of add-ons (see this post for an overview).
By completing the package, traceability can now be extended towards documentation and source code. All issue types (needs, epics, stories) can be linked to a Confluence page for documentation. Stories are linked to the source code through Git. With the new Confluence 5.4 it is now also possible to link Confluence pages directly to sprints, to document retrospectives, and to demo sessions.
So step by step, the Atlassian stack keeps improving the agile way of working. For organizations big or small!
This article was originally posted on the Avisi Blog. We’ll continue to check in with Sander and others for more ideas on scaling agile in the enterprise. You can also check out our website for more tips about doing agile right.