Agile, Guides

Run & Report with Essential SAFe® in Jira Software [Guide] | Trundl

Run and Report with Essential SAFe in Jira Software
[ stepwise guide ]

Run & Report with Essential SAFe® in Jira Software

Achieving business agility with Essential SAFe®, powered by Jira Software’s run and report features

Trundl

June 30, 2021

Guide

Jira is a leading Atlassian tool for Agile project management, and SAFe® is one of the most popular methodologies to implement Agile at scale. But, how does a team leverage Jira Software’s capabilities to nail its SAFe® goals?

This a step-by-step guide on how to run and report successfully with Essential SAFe® in Jira software, and how it can help teams improve business outcomes by serving as a single source of truth.

Contents​

 

An overview of Essential SAFe®

The advent of Agile has revolutionized software development and project management by transforming teams into better organized, adaptable, and efficient versions of themselves.

In 2011, Dean Leffingwell and Drew Jemilo released SAFe® or Scaled Agile Framework with a view to help companies design better systems to cater to evolving customer needs. The need for rapid response to changing market conditions was high, and paved the way for new frameworks to help businesses improve solution delivery across their enterprises. Enter SAFe® – one of the top ‘Scaling Methods and Approaches,’ with nearly one-third of respondents in the 12th Annual State of Agile report saying that it is the method they “follow most closely.”

Core elements of Essential SAFe®

The Scaled Agile Framework® (SAFe®) is a knowledge base of proven, integrated principles and practices for Lean, Agile, and DevOps that help large organisations tackle the challenge of Agile at scale.

Out of the seven competencies of SAFe®, focus at the Essential level are on:

  • Team and Technical Agility
  • Agile Product Delivery
  • Lean-Agile Leadership

In Essential SAFe®, the organization works with a single Agile Release Train (ART), and a single development value stream. An ART is broken down to multiple teams, and comprises about 50-125 people in size. We will elaborate on this in the upcoming sections.

While there are four configurations of SAFe®— Essential SAFe®, Portfolio SAFe®, Large Solution SAFe® and Full SAFe® — Essential SAFe® is the primary configuration on which the others are built, and constitutes the key elements needed to realize most of the framework’s benefits.

Features of Essential SAFe®

  • As the name suggests, Essential SAFe® configuration includes only the bare minimum of SAFe® elements, such as Agile Release Trains (ART) — a group of teams that helps ensure steady alignment between the company’s goals and the needs of end users.
  • This lightweight but comprehensive version of SAFe® is designed to ensure sustainable success in the organization.
  • Under the new Essential level of SAFe®, Scaled Agile has incorporated Customer Centricity and Design Thinking as key themes. Organizing ARTs revolve around the value one’s customers receive rather than other established structures.

Connecting task management and issue tracking with related aspects of an Agile team through Jira ensures that strategic planning become better aligned and more dynamic. Find out more.

 

High level key components

Agile Release Train: An Agile Release Train (ART) is a cluster of Agile teams usually comprising 50 to 125 people with 3 to 10 members in each team.

Product Management: When a bunch of teams work together at a certain level, you have a Product Management Group that manages Product Backlogs well as the Features on that level. Features can be compared to Epics in Jira.

The Features are then divided into multiple Stories, which are in turn assigned to Teams. One of those teams would have their own Backlog with Stories, and work through the roles of Product Owner, Scrum, Master and Developers.

Program Increment: In SAFe®, it’s pivotal to synchronize the cadence while working on the above-mentioned Stories and Features. This purpose is served by Program Increment, which may be viewed as a large timebox comprising about five iterations (analogous to Sprints in Scrum). These two-week iterations (about five of them) make up a Program Increment. In this case, all the teams work in the same timebox in the same cadence.

PI Planning: SAFe® teams participate in a two-day event called Program Increment Planning which is helmed by the Release Train Engineer. Conventionally, the team congregates in a room where members would be in physical proximity of their colleagues.

However, the paradigm shift in work culture has now paved the way for a new format called Distributed PI Planning. This is accomplished with tools such as Zoom for video, Slack or teams for chat, Miro or Mural for digital whiteboarding, etc.

Teams also use Jira for managing the hierarchy of requirements.

Find out what is PI Planning, and why we do it

 

Prerequisite Configurations

  • Single Jira Project (ART)
  • ART Scrum Board
  • Team Scrum Boards
  • Sprints: Created, Dated and Named
  • Advanced Roadmaps Plan with all boards
  • FixVersion (Release) for PI
  • Automation for WSJF
    • Single Jira Project (ART)
      Let us consider a single Jira project for an ART. Create multiple projects if you’d prefer, but for this whitepaper we will consider a single one that houses all of the Features, Epics and Stories that the teams are working on.
    • ART Scrum Board
      An ART scrum board is essentially a Program Board, and has all of the Features that all the teams are working on, as well as a roll-up of all the associated Stories.
    • Team Scrum Boards
      In Jira, you could create a Field or use a Field like component, and  have the values for each one of your Teams. Next, those Team Boards would filter off those values to pull in only relevant Stories and Features, but all of that data would then roll-up based on a filter at the program level of the corresponding ART Board or Program Board.
    • Sprints: Created, Dated and Named
      Before all the planning commences, it is important to have your sprints created, dated and named. Ideally, one should have a naming convention suitable for use across your teams.
    • Advanced Roadmaps Plan
      Advanced Roadmaps Plan features all the Boards as input sources, and we will delve deeper into this in the stepwise demonstration section.
    • FixVersion (Release) for PI
      To serve the purpose of PI, we’d recommend the FixVersion (release) Field which gives us a timebox and allows the opportunity to show milestone dates on the Roadmap.
    • Automation for WSJF or Weighted Shortest Job First
      This is nothing but out-of-the-box automation for Jira configuration, without any Addons. (Elaboration in stepwise demo section)
 

Advanced Roadmaps

  • This image is a high level basic view of Advanced Roadmaps.

We start with a high level, ‘Basic View’ of Advanced Roadmaps, not grouped by anything, with dependency style of badges, and rolled updates.

  • Hierarchy: As seen in the image below, all hierarchies are listed on the left side. Please note, one of the advantages of using Advanced Roadmaps is that it offers the scope for enlisting unlimited hierarchies.

 

For this example, we have set our hierarchy to Epic to Story relationships ( for Essential SAFe®, but it offers the ability to be built upon. Below is the list of Features, which will show the top-10 for PI Planning off the Program Backlog.

For this demo, we are going to use only using the Epic to Story or Feature to Story relationships as we’re doing essential SAFe®. However, it can be built upon and scaled as per the team’s requirement.

  • Features: What you see below is our list of Features (LHS). In PI planning, one of the inputs is the top 10 Features of your Program Backlog, and hence our top 10 Features are visible the image. Note the toggle for our Feature to Story breakdown.

See the toggle for the Feature to Story breakdown.

  • Fields: Let us walk you through some of the Fields we have used for this demo. Add as many Fields as you want for your Roadmap, or include custom Fields as per preference.

Here you have your fields as part of your Roadmap, including custom Fields, to tell your Story.

Start pulling in Fields to tell your story, and ultimately, you’d want to at least be able to provide the minimum information that you would get in a Program Increment Board. Think of this as your traditional Board or the output of your PI planning.

A Traditional Program Increment Board  resembles a grid. While the Swimlanes would represent each one of your teams,  the horizontal columns will be each one of your Sprints or iterations. For this demo, we’re replacing those with the Advanced Roadmap solution in order to visualize it differently. All necessary data stay intact, regardless of the view.

  • Releases: As mentioned earlier, we are using FixVersion Field for releases for this demo.

The first field is Release (fixed version field) to timebox all features. The little arrows indicate configurations at the Story level rolling up to the Feature. On the right is the calculated release of the Program Increment.

Let us timebox all of our Features by Program Increment 1 or PI 1.

  • Note that on the right-hand side, we have our Release for Program Increment I, and it’s timeboxed and highlighted on our Roadmap.

Focusing on “Feature I”, you see it is hard-coded to PI 1.
We are now looking at WSJF (as a means to prioritize/sequence features).

Going into one of the Epics (Feature I). The User Business Value, Time Criticality, and Risk Reduction all add up to reveal the Cost of Delay. Taking the Cost of Delay, if you divide it by the Job Size, you get the WSJF or Weighted Shortest Job First ( If you use a loop-back transition in the Jira workflow off of this).

On the left-hand side, you will find arrows which indicate that configurations at the Story level are rolled up.

  • WSJF (Weighted Shortest Job First): Let us now focus on Feature I which we have hard-coded to PI 1. WSJF or Weighted Shortest Job First is a way of prioritizing or sequencing your features, and includes a bunch of different Fields (see image above). Once you get a grasp over the basic calculations involved, it is easy to work with.

User Business Value: The relative value to the customer or the business.

Time Criticality: This tells you how the business value decays over time, or if you have a fixed due date or deadline date for a particular Feature.

Risk Reduction: Think of this as risk reduction as well as opportunity enablement. This addresses your concerns on whether there are any risks or opportunities that could affect your work on a particular Feature.

Cost of Delay: The three above-mentioned Fields clubbed together constitute the Cost of Delay, which is the overall cost of delaying the delivery of that particular Feature. Divide it by Job Size ( the size or the duration of the Feature development), and you’ll get what is called Weighted Shortest Job First or WSJF.

Get more details

  • Calculating WSJF: In this stepwise guide, we’ve created a loop back transition in the Jira workflow. Let us start by adding some values, and proceed to calculate the WSJF.

Calculate your WSJF off  inputs.

As visible at the bottom, it’s going to automatically calculate the WSJF value through automation and show us that value in the issue itself.

Through automation, the value is created on the issue itself.

  • Next, if you refresh and return to the page, you will notice that it has pulled in the live data and enumerated the WSJF Field.

 

Back on your Roadmap (after calculating), the feature’s WSJF is now integrated, and it is a good way to prioritize/sequence Features.

This facilitates prioritizing and sequencing your Features.

  • Teams and Component Fields: Next, we will discuss Teams and Component Field together as we’re using the Component Field to create and filter the Team Boards

Look into the other Fields in the Roadmap. Notice that we have used the Team and Components fields to work together. This lets you filter by Team on your Board. Conversely, the Team Field conversely leverages the built-in functionalities around capacity and Sprints.

We need a Field which we can add to our filter to pull in the relevant data for that Team, and using the Component Field helps accomplish that. We will be using the Team Field because it is a built-in Field with Advanced Roadmaps, and allows users the ability to leverage a lot of the rich functionality around capacity and sprints.

Story Points: We have our roll-up of Story Points for each Feature based on the Story Point estimates entered on the Story level.

See rollup of Story points on each Feature based on the estimates at the Story level.

See rollup of Story points on each Feature based on the estimates at the Story level

See rollup of Story points on each Feature based on the estimates at the Story level

  • Here we are going to show you the view that we’d prefer using for Sprints. Note that the start date and due date is based on the Sprint dates. This section also allows you to add an assignee.
  • View Progress: Hover over ‘Progress’, and you will instantly get an overview of completed as well as remaining Points.

Progress Field lets you hover over and see the completed points and remaining points. This is effective for planning, and once ready to write this data into Jira, you can review the changes. Use this as a progress report of what is happening in your PI.

Use this view for your planning: Once you’re ready, simply visit this section, review the changes, and write it to Jira. This provides insights into what’s going on in your PI, and how it’s progressing along with the development of features.

  • Create Stories: Next, we’re going to create some Stories under Feature I.

Remember, this does not automatically create the Stories in Jira yet. Reviewing the changes is necessary before writing them to Jira. Let us create about five of them:

Let’s create Stories under “Feature I”.

Once created, you’ll notice a yellow/orange bar on the left, and all of the stories do not have issue keys. This is because the issues are not created yet. Rather, it populates a change log.

Notice the yellow bar down in the image above? This happens because issues are not created yet. Rather, it populates a change log.

  • Review Changes: This section is populating this change log with all of the changes that are being made in Advanced Roadmaps.

Once the Stories are created, “Review changes” in the upper-right.

Select the ones you need, and then write them to Jira. Remember, although it is pulling in live data from Jira, one still needs to manually push it to Jira.

The Change log lets you select anything you want to write to Jira. Since Advanced Roadmaps automatically pulls information from data, this lets you push these Story changes into the calculations once you have entered the right field data for each Story.

  • Updating Team Fields: Next, it is time to update your Team Field. We’re using Team A and Team C to work on these Features, and adding some Component Fields to our Teams for the same. This will be repeated for both sides, and you will see that it’s going to roll up.

Here we are adding the Teams associated with the new Stories. Next step is estimating each of these for each team.

This will be all part of the planning effort.

  • Estimate as a Team: Next, we’ll go to our Story Points and start estimating as Teams.

With Team assignments set on the new Stories, it is now time to estimate them. Start by opening your Story Points field column and entering each (the roll up should react instantly, as it does here for Feature I).

Note that this has rolled up to 21 Story Points.

  • Sprint Assignments: For Sprints within the PI, we will now start assigning the Stories to iterations. We know which teams are going to be working on them, and need to be able to check their capacity, or if there are any dependencies on individual Sprints.

Next is Sprint assignments within the PI. We know the teams working on these, but we do not know their capacity. Change your view to Sprint Capacity Management.

  • Spring Capacity: Go to ‘Views’ and change the Spring Capacity, where you will find a breakdown of your Teams. Note that you have each one of the five Sprints within that Program Increment.

Under here, we have a breakdown of each of the teams, and their capacity in each one of the Sprints. Each has a fill line to show how much is allocated for each Sprint.

Overallocation is shown with red. You can change the Sprint capacity in line, and find that it recalculates.

Indicator of overallocation: Notice the little fill line in the image above? It is an indicator of you how much available capacity you’ve allocated for a particular Sprint.

For Sprint 2, the figures show that 44-50 points are allocated, and its capacity is 88% full. However, it is possible to change this value Sprint by Sprint, depending on factors affecting productivity such as a colleague being on leave or similar factors. Make necessary edits while making your estimations.

Notice that it turns red in the event of overallocation. For 63, you are at 105% capacity. However, if you are confident that you’d be able to finish it, and want to alter the estimate, it’s going to turn green again.

  • Let us now move to Team A & Team C which we have chosen for assigning Feature I, and check the availability scenario. We’ll put these in Sprint 3:

Now we can open up the Features, and see the next Stories we just added and assign Sprints to them. In this example, it looks like there is bandwidth in Sprint 3, so we will add Sprint 3 to Story IA.

  • Let us repeat the same procedure for Team C, and assign them to Sprint 4. Since we have a dependency now between Story IB and Story IC, we can easily drag the line to the corresponding Story as shown below:

Once the Sprints are assigned, you can add Dependency Badges by dragging the link symbol to the right of the Sprint bar for the Story. You can drag the line to the corresponding Story to create that relationship. You can also manually enter it with search (issue key) if you click on the plus sign.

Click on the Badges to see your dependencies.

Dependencies Report

Everything is estimated, and ready to go. This sets the stage for exploring Dependency Reports to view all your dependencies collectively. Group it by Team, or even visualize your cross-team dependencies.

If you want to see the Dependencies, select  Dependencies report.

Alternatively, you can filter this by individual issues, release, etc as well. This tool allows you to customize the way you visualize your data.

  • Group by Release: For the purpose of PI Planning, it is convenient to have access to a visual that presents data that you would otherwise get from a Program Increment Board. To get that representation, choose grouping by release:

Group by Team, and you can more easily visualize dependencies. You can also filter by individual issues.

  • This is our PI 1 release (using the FixVersion Field). Here you can see all your data for a specific PI- such as Sprint data, Team assignments, and pretty much everything you’d see in that horizontal intersecting grid. Additionally, you also get to visualize the Story Point estimations, WSJF for your Features, start and due dates, assignees and progress.

Now you can see all of the data in the Program Increment Release (because we are using the
FixeVersion Field here) This includes Sprint data, Team assignments, Story point estimations,
WSJF for Features, Assignees, Progress, etc.

  • Review Change Log: For this demo, we have updated six or seven Fields for each one of the issues, and it is going to show you details pertaining to those changes. Select the ones you want and it will even show you the change in capacity for that individual Sprint modified by you.
  • All changes that you implemented in your planning will now be written to Jira. This is synonymous to your PI Planning Board which serves as ‘a single source of truth’, and contains all relevant information including who’s working on which Sprint, dependency status across teams, etc.

You can now review your changes (including the fields under the “what changed” column).
Save the selected changes, and it will process and be written to Jira.

 

Out-of-the-box Jira reports:

When you are working with Boards, you are configuring them at the Program level for the entire Agile Release Train, as well as configuring your Boards for individual Teams. This allows you to view and analyze reporting for all of the data collectively rolled-up for the Agile Release Train, as well as the data only for individual teams. This is of the following types:

Burndown Chart
This report pulls in every team’s bit of data, and also filters the data to reveal the burndown for a specific team.

Burnup Chart
You can see the Burnup chart for the entire Agile Release Train as well as specific teams for a particular Sprint.

Velocity Chart
This enables you to see your commitments and completion of Story Points over time as well as over Sprints for the entire Train. Like the Burnup and Burndown chart mentioned above, you can also see representations for specific teams.

Release Burndown
Since we are using FixVersion for Program Increments, this represents your release burndown for PI 1  for the entire agile release train across all the sprints in the PI, or explore Sprint-by-Sprint burndown for specific teams.

Epic Burndown
Remember we mentioned how Epics are Features? The Epic Burndown report comes handy when you want to see the Feature Burndown over Sprints, and the Burnout across all its contributors. This can be viewed for specific teams as well.

 
 

Conclusion

Shifting from conventional project management processes to an Agile methodology could be challenging. However, this transition could be made painless and simple for the team with the help of a well-configured task management system that comes with automatic workflows and built-in reporting capabilities.

A tool like Jira software enables teams to manage their SAFe® activities at every level from a single frame of reference. The flexibility of Jira software empowers teams by not only allowing them to visualize and dissect their work, but also alter the status of resource allocation, review cross-team dependencies and monitor overall progress.

From Agile Boards and Backlogs to Roadmaps and Addons- plan, visualize and track all your Agile software development projects with a single tool, and your SAFe® journey with Jira is sorted!

While SAFe® could be the stepping stone for your Agile transformation journey, beginners might find it overwhelming to navigate their way through the initial phase.

Consider reaching out to a SAFe®  Program Consultant (SPC) to improve your company’s software and systems development processes, and accomplish business goals faster.

Evan Golden, Director of Engineering at Trundl, is a certified Atlassian Master with over 12 years of combined experience helping IT, software, and business teams, automate their processes using the Atlassian stack. Additionally, Evan coaches teams on how to use the Atlassian tools to assist with team collaboration, transparency, and alignment when implementing different Agile methodologies and frameworks including Scrum, Kanban, and SAFe®, and when working with ITIL 4 practices and Enterprise Service Management.


Free Consultation

Know your expert:

EVAN GOLDEN is a certified Atlassian master and has over 12 years of combined experience helping IT, software, and business teams, automate their processes using the Atlassian stack. Additionally, Evan coaches teams on how to use the Atlassian tools to assist with team collaboration, transparency, and alignment when implementing different Agile methodologies and frameworks including Scrum, Kanban & SAFe®, and when working with ITIL 4 practices and Enterprise Service Management.

Get expert help with Essential SAFe® in Jira Software
Drop us a line, we will get back to you on Licenses, Deployment and Support