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.
-
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
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
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
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
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
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.
For Check#6 One active sprint per board - https://community.atlassian.com/t5/Jira-Align-articles/Jira-Align-and-Jira-Integration-Best-Practices-and-FAQs-Teams/ba-p/1257975
Check #6: A single sprint should only be tied to one board.
Because one board represents one team, hence each sprint should be present only on the related team board, if a sprint is shared across multiple boards then it will lead to ambiguous sprint mapping on Align side which creates hard to debug sprint mapping problems.
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.
Was this helpful?
Thanks!
Tarun Sapra
4 comments