Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

JET checks and their implications

Jet is a free Marketplace app for examining and optimising boards in Jira; it'll help you determine if a team's current practices would support their ability to provide cross-team visibility into the progress of work and how that work ties into larger company objectives. Running a Jet analysis will help your agile teams and programs prepare for scaled agile by highlighting the areas that need remediation to provide consistent reporting across teams while helping to drive outcomes across your organization.

The intention of this writeup is to provide you with insights about the implications of each of the JET checks.

Jet's seven checks

Jet’s seven prioritised health checks will evaluate the quality of your data. The more health checks that pass, the smoother your integration to scaled agility in Jira Align will be.

For Check#1 Not having stories linked to epics will not break the connector, but they will just appear as Orphans in Align. Thus, it’s strongly recommended to have stories linked to Epics, even if the stories are related to non-planned tasks or something that needs a urgent fix etc, in that case you can have a placeholder Epics for all sorts unplanned work so that we can understand its impact on the capacity in the longer run.

When work isn’t contributing to strategic work, such as BAU work, we still gain value from aggregating it at higher levels of scale. Having an understanding of strategic versus keeping the lights on can be an extremely valuable insight.


Check #1: Stories should be linked to epics.

Stories with parent epics provide an accurate representation of how your work rolls up into your strategic themes.

Action

Make sure you've linked an epic in your story.

Following are the Implications with screenshots if the stories are not linked to Epics.

  • Stories missing the alignment with Portfolio Epics and Strategic themes, i.e. teams are producing “outputs” in terms of finished stories but there is no alignment with “Outcomes”

  • In the following screenshot, you can see how by clicking on the “Why” button on the story work-item a PO/SM can see how that story is contributing towards the overall strategy of the organisation and this info can also be sent into Jira from Jira Align and made available on a custom field in Jira so that the devs working on the story can see the relevant parent features, portfolio Epic and the Strategic Theme.

image-20200621-132547.png
  • Also, Orphan stories don’t contribute towards the progress of any Program feature and Portfolio Epic i.e. the burn-down charts thus, having many Orphan stories will lead to poor predictability in the longer run. This is important even if stories are created for BAU(Business As usual) maintenance work, it’s important to tie them with a long running BAU Portfolio Epics so that we can keep an track of how much effort is being spent

  • In the work tree view, you can drill-down and see the effort spent from the Portfolio epics down to the child story

    image-20200621-134904.png



For Check#2 , not having the following check will not break the connector, but its important to have stories estimated so we can measure all the work that’s being delivered

Check #2: Stories should have estimated story points.

Stories that have story points provide an accurate representation of your progress.

Action

Add estimates to your story points fields in your stories.

Following are the Implications with screenshots if the stories are without estimates

  • Stable teams and Estimate stories give way to stable Velocity which leads to predictability which helps us in building the rights stuff and making the right demand vs capacity considerations.

  • There are multiple views which help you in the demand vs capacity decisions and that are driven by the Estimated vs Actual points

image-20201112-174342.png

Here in the above screenshot program load is based on the loaded story points for that program

We can also see for each team what’s the velocity vs whats' the current load

image-20201112-174418.pngAnd in the following screenshot you can compare in real-time the load on the team vs the average velocity across multiple sprints

image-20201112-174437.png

 

Also, in the Program feature (Jira Epics) backlog you can see the progress of the features by story point progress as Jira Align rolls-up the points estimated at story level

image-20201112-174455.png

If you are using Strategic drivers across portfolio epics then based on the story points you can also see the actuals i.e. Points accepted across portfolio epics

image-20201112-174508.png

Please note, for the stories on the Jira board, they should be linked to Parent epics and estimated when they move into a Sprint on the Scrum board, but if they are part of unassigned backlog and since not part of any active Sprint or future sprint then they can remain on the board un-estimated as they are currently not mapped to the sprint as estimation happens during Sprint planning or tentatively during backlog refinement.


Check#3 can be skipped altogether if you are not using fixVersion actively to track your releases.

FixVersions isn’t the most scalable approach for releasing across programs because fixVersion is per project in Jira and thus there is an administrative overhead or some plugin required to maintain it across the projects. So if you are not using FixVersions then you can ignore this check altogether. Also, Jira Align support Release vehicles which can be used to maintain releases across programs.

Check #3: Epics should have an assigned fix version.

Epics should have fix versions to dictate what release the epics will be shipped on. Releases are tied to a project in Jira.

Action

Assign a fix version in the "Version" item under a project's settings


For Check#4 We can share the board with multiple projects, i.e. the team board can have issues from multiple projects. But in the filter share there has to be the parent project. As explained here as well - https://community.atlassian.com/t5/Jira-Align-articles/Sync-a-Jira-Board-with-Multiple-Team-Level-Projects-in-its/ba-p/1273974

Though having multiple projects present in the filter of the Team Jira board just makes the integration a bit more complex. If the teams are following separation of concern in Jira, when it comes to work items then the integration is smooth. Teams having their own board and project and a dedicated project for Epics.

But one important thing to understand here is, multiple teams can’t share a single board, this is something which isn’t supported. As each Team needs to have its own dedicated board and it could be that the board is fetching issues from one or more JIra projects.


Check #4: There should only be one project assigned to a Jira board.

Multiple projects linked to a single board can make it difficult to measure team-level progress. That board can represent multiple teams and have sprints with overlapping dates.

Action

Ensure only one project is tied to a board by navigating to Board Settings, selecting Edit Filter Shares, and removing all but one project. You may also fail this check if there are no projects tied to your board.


For Check #5 Custom fields should be optional, because when you create a Feature in Align, it might not get recreated in Jira as an Epic if the Epic screen in Jira has mandatory custom fields. Because in Align we keep the custom fields to a minimum as all the scaling attributes like products, programs, increments, strategy, themes etc are provided out of the box.

 Check #5: Mark custom fields as optional, not required.

Custom field configuration can affect your ability to integrate with Jira Align, a Scaled Agile tool in the Atlassian suite. If you are only syncing from Jira to Jira Align and you leave any fields as required, they will not be synced. If bi-directionally syncing between Jira Align and Jira, your issue type will fail to sync.

Action

Please mark any fields other than Description, Reporter, Priority, and Summary from your issue types custom fields as optional.

 

Check #6: A single sprint should only be tied to one board.

Because one board represents one team, if you have a sprint on multiple boards, it can make be difficult to measure team-level progress.

Action

Similar to health check #4, follow the instructions to make sure you only have one project on one board.

If your team is structured in a way that you can't edit Filter Shares, instead select Edit Filter Query and ensure only a single team's sprints are tied to a board.

 

For Check#7 this generally never happens unless you have parallel sprints enabled or have multiple sprints active on the same Team board.

Check #7: Sprints on a board should not have overlapping dates.

Sprints represent a (usually 2-week) planning and execution time slot for a single team. Only one sprint should be active at a time.

Action

Make sure the start and end dates for your sprints don't overlap.

 

Jira Boards and Scaled Agile

Boards live under projects

If you're familiar with Jira, you're probably used to putting all of your issues (stories, features, epics, and more) into a project. You'll notice under your project view that you have one, or maybe even a few boards, that act like dashboards to represent the issues in that project.

In Jira, a team can have many boards, but when it comes to integration with Align then Align supports only a single board per Team. Thus, we need to integrate that team board in Align which is the system of record for all team activities like for a Scrum Team, it should be the board where you start, stop and work on sprints.

One Board = One Team

For teams that plan their work in sprints using Scrum, you'll likely have a sprint board. All work that gets planned there would belong to a single Scrum team. We wouldn't have multiple teams working on the same single sprint! This is why we use boards to represent teams in Scaled Agile.

This also applies to Kanban

Even though you can have Kanban teams that don't use 2-week sprints, it is assumed that all work on a board belongs to a single team. Just remember that a Jira board (and all of its issues) equals a single Scaled Agile team (and all of the issues it is working on).

An optimized board is a Scaled Agile board

When your team boards are optimized for Scaled Agile (work is estimated through story points, stories are linked to parent epics, etc.), all work can then roll up through an organization. This will allow your organization to track progress to quickly adapt to market changes and that's what ultimately creates an Agile enterprise.

1 comment

Mark Cruth Atlassian Team Nov 18, 2020

Fantastic piece @Tarun Sapra ! A must have for every org using Jira Align and Jira!

Like Tarun Sapra likes this

Comment

Log in or Sign up to comment
TAGS
Community showcase
Published in Jira Align

Best Practices in Jira Align

Hello Jira Align customers! In order to better serve you on your journey with Jira Align, the Community team has worked with the Jira Align team to curate the content in this collection to better s...

637 views 1 11
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you