Anyone using Atlassian products to enable the Scaled Agile Framework (SAFe)?

Is anyone using Atlassian products (e.g. JIRA Agile, Confluence) to enable the Scaled Agile Framework ( I'm curious how people are managing metrics at the portfolio and program levels, how people are creating/integrating product roadmaps, how people are managing decomposition or traceability of at least three levels (epic, feature, story) of requirements, how people are doing metric rollups, complex kanban boards (e.g. split columns or rows).

What solutions have you come up with? What problems are you having?

8 answers

Hi Peter,

I'm not necessarily sold on adopting the SAFe model wholesale. Early days, and from what I learned at Agile 2013 people are still very much experiementing and tweaking. Our thinking around managing at scale continues to evolve - where we were a few months back is covered in this blog post and I added more context at Summit.

We have a Kanban board that captures all company gulls (Epics), quick filters allow us to filter by quarter, group, etc. Swimlanes for blocked (using the issue links and Script Runner) so we elevate issues for discussion early. The control chart is interesting although there is lots of varability in the cycle time. The CFD is more valuable at present as it shows us movmement on epics over the course of a quarter.

One thing the metrics have given us: an idea of where we can focus our energy to move teams and help them improve. For instance, sizing is not consistent across all teams. Rule of thumb I think of is 2 - 4 weeks to complete an Epic (and deliver a Key Result). Anything longer and it should be broken down. The teams estimate the tasks/stories/bugs within that Epic using story points, and are getting better at that too.

Since the conclusion of Q3 I've been pulling metrics for teams and groups. For the team level I'm starting to pull metrics using the Sprint Health gadget to give me a feel for their most recent progress, and I want to couple that with the velocity chart to get a sense for consistency and delivery. The teams themselves look at their Wallboards (I should write more on this). However, we've not got a suitable way to visualise this at a higher level, the rollup of a whole group.

To try and get those rollup metrics I am exploring Dataplane (I got a neat demo from David and Scott at Summit, looks very cool, awaiting install). I'm not sure Dataplane has everything we want, although I'm confident they'll give us more than what we've got already - so that is a win. Roll up metrics include the number of committed epics that are delivered vs not (cancelled, incomplete, not started), how many of the Top 5 were delivered (drop the lowest impact things in favour of the highest impact), and I'm sure we'll think of more as we start to see some initial metrics.

So, how do you approach this?

Nicholas Muldoon / @njm

Thanks for the detailed response, Nicholas. I'm not necessarily sold on whoesale SAFe, either, but I am interested in a multi-tier governance model and sometimes it's easier (lazier, too) to refer to SAFe.

We've been working with LeadingAgile coaches (said "hi" to you in their suite at Agile 2013 this year) for almost three years. Their base multi-tier model uses epics at the top level, features in the middle, and stories at the bottom. (That's just like SAFe which makes some sense since Mike Cottmeyer is listed as a contributor.)

I've been running Kanban boards for our features and epics with a variety of quick filters also. I find the epic control chart to be usless because of the variability (as you noted), but perhaps I just need to categorize the epics.

Our definition of a feature is that it has to be done within the scope of one release so the control chart for those has also been uninteresting because they all have the same cycle time (i.e. the same duration as the release).

However, I think it might be interesting to start looking at the cycle time of epics and features including the time before they get to the dev teams. I suspect we'll see some really long lead times in the business groups on some of them.

We also have the Structure plugin. Many of our people used that extensively until epic support became available in the scrum boards. Structure recently added support for rollup metrics (e.g. a parent issue can display the sum of story points in its tree) which might entice us to use it for certain things again.

My main frustration with JIRA Agile is it corners you into having no other issue type between epics and stories if you want to use the built-in grouping/filtering/rollup on the boards. Only epics have this functionality. The other two leading Agile PPM tools are more at least somewhat more flexible in this area.

Regarding metrics, I've been using the eazyBI plugin, but I'll take a look at Dataplane. It looks intriguing at a glance.

This is the first detailed account of a real JIRA SAFe implementation that I've come across in the public domain -

For disclosure - it uses a product made by the company I work for.


Wait a few more days for the content from 2013 to go live at, there was a great presentation on this topic from Damon Poole, Eliassen Group "The Enterprise Agility Model"

Thanks, Eddie. I've been checking every day. Anxiously waiting.

Ken Schwaber has some interesting comments about SAFe here.

Thanks for responding, Stuart. I saw Ken's post the day it was published. I find it completely non-constructive at best.

Maybe this article will be more constuctive for you. Don’t you Dare Play it SAFe

I wanted to include this in my comment response to Nicholas above, but comments are limited to 2,000 characters.

I'm nearing the end of redefining our enterprise flow based on input from our business management groups. It's actually looking like it will be four tiers: product plan (18-36 months), version (0-3 months), epic (2-6weeks), story (1-5 days). (I'm scared about presenting the four-tier model because it looks so heavy and non-agilitists will see a communication hierarchy in it instead of a governance model, but that's a different topic).

My current thought has the source of truth for product plans, versions, and epics being Confluence. Versions and epics will be linked to items in JIRA so the teams have transparency to the source of a story and so we can track flow metrics. I'll be starting to play with this approach this week.

Keep us posted on progress please Peter, sounds like a great start. Thanks

If anyone is interested in SAFe and other scaling agile stuff, here is a good overview at


You may want to implement this Workflow Post-Function that updates your Epic Status to follow Workflow Status: HowTo: Track Epics in the Control Chart, as this will make it so Epics can transition and keep their Epic Status field in line.

Interested if there are updates to this thread now that it is almost 1 year later. I have a similar thread on the Scaled Agile LinkedIn group, and would love to hear from Atlassian on the topic.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Mar 12, 2019 in Confluence

Confluence Admin Certification now $150 for Community Members

More and more people are building their careers with Atlassian, and we want you to be at the front of this wave! Important Dates Start the Certification Prep Course by 2 April 2019 Take your e...

1,545 views 4 13
Read article

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you