Program Board in Jira Align lighting up Red & Orange? Here are some tips.

[#1]

Empowering Agile Teams offers great benefits through independence.  However, orchestrating threaded efforts both within and across Teams to deliver Features has many risks to success.  There are timings of child Stories that support the Features and sometimes dependencies across groups that can become misaligned and impact expected outcomes.   

Jira Align has a key "barometer" called the Program Board that can flag planning issues automatically.  The Program Board is usually the most critical deliverable from planning events in frameworks like SAFe, but regardless of background there is usually common agreement that a plan for Features being delivered across time is valuable.  

I've seen clients that have been minimally trained as well as heavily immersed in learning the Program Board struggle with usage.  In the spectrum of "crawl-walk-run", this can definitely seem more like a walk-run type area due to the rich amount of content possible.  But there are ways to simplify where needed.

If your group is struggling with understanding or using the Program Board, consider the following ideas to help:

1. Avoid using Team level Objectives unless mandated.  This can be hidden in the Extra Config button on the upper right.  Although there can be benefits in some environments by linking Program Board Features to the Objectives and tracked across quarters with 1-10 value scores, the overhead is a lot for some groups to take on - at least initially.  (Plus higher level OKR's are pretty much eclipsing the widespread use of Team Objectives from my viewpoint.)

2. Make sure every committed Feature for the quarter is set to a target sprint.  Since less mature Teams may struggle to slot a Feature incrementally forward, at least set the target sprint as the last sprint in the quarter if nothing else.  This allows Jira Align to automatically flag misalignment situations and light up concerns via colors without being clouded by the issue that a target sprint has not even been set for the Feature.  (Exception being for some temporary time the Feature is still being negotiated as in/out for the commitment, so stay in the Unplanned Sprint column then.)

3. Review the Program Board post-quarterly planning at least weekly.  Often this could be the agenda for a scrum-of-scrum or PO sync type event.  However, as you get started to avoid feeling overwhelmed you can filter in the Tier 1 at the top on a single Agile Team at a time rather than the whole Program.  And if it is already the middle of the quarter, don't bog down the gathering by going back to the prior sprints.  Focus on the current sprint and look forward.  (As time allows outside of a group event you can decide if cleaning up the past is feasible given time constraints.)

4. Accept Features (aka Black check mark) in the target Sprint that is set for the Feature when all the work completes.  If there is more work still required such that the Feature cannot be accepted potentially shippable, then have the necessary communication with the business requester and update the target Sprint for the Feature.  In the example below, only 2 of the 5 Features are DONE in the Sprint.  Note: Taking a snapshot (e.g. print screen PDF) at the start of the quarter following initial planning makes sense to have a true program baseline that can be used when learning & retrospecting on the quarter.  

5. Dependencies are fairly critical for tracking delivery risks when not considered shared work across the Teams.  However, if your group is struggling to learn & use the board, this area can be tabled until after they are first functioning well with Features that are either single-team contributed or co-contributed across teams in the same Program.

To summarize, a successful program board for a recently completed sprint should have Feature (rectangles) represented with green shading (all Stories accepted) and black check mark (Feature accepted).   

If they really can't handle Program Board and there sensitivities such as political considerations, then consider instead starting with a "lite" version of managing the work via the Roadmap.  We'll discuss that option more in an upcoming post.

As always, your feedback is appreciated so please feel free to respond back!

[Bryan Smith]

This is great perspective Rob- effectively coordinating work through the program board is, for some, worth the price of admission for JA! Add to that sophisticated dependency mgt and there's tons of value.