#JiraHeroes June '22 Spotlight: Kelly Arrey
At Atlassian, we take great pride in the software we ship, and even greater pride in the success our customers achieve when they use our products. #JiraHeroes is our new monthly spotlight series where we ask customers to share their success stories with Jira Software. We hope that customers will find inspiration on how to overcome their own challenges by hearing how our #JiraHeroes overcame theirs.
This month, we’re featuring @Kelly Arrey, an engineering operations manager at BlueCat, who shares how he leveraged Structure for Jira to better organize his team’s work, streamline the workflows of a growing organization, and create a culture of data-driven project planning.
Please introduce yourself! Tell us about where you work, your role, and the team you're on.
Hello Community! My name is Kelly Arrey, and I’m the Jira Software and Confluence-wrangler (among other things) at BlueCat. Our company develops and sells Enterprise Networking Solutions, including DDI, Network Automation, and Network Security. My role includes managing our Jira Software and Confluence instances for our development team (about 150 persons) and several other teams across the business.
What organizational challenges were you trying to solve with the implementation of the Structure for Jira plug-in?
As our development team grew over the past decade, it became increasingly challenging to manage the growing number of active Epics with only the basic Jira issue hierarchy (Epic, Story, Sub-task). This created a “can’t see the forest for the trees” problem. We needed a way to be able to zoom out to see the entire forest while keeping the ability to zoom in on specific trees as needed. We investigated several Jira plug-ins to help us address this, and found that Structure for Jira from ALM Works offered us a flexible way to organize our work into more manageable chunks.
One of our senior technical managers was first introduced to Structure in early 2012. Over the next couple of years, our team learned more about the plug-in and Structure seemed to be more flexible and fit our use case better than the alternatives available to us at the time. Our Engineering Director immediately saw the value of being able to build a work breakdown structure which supported quick zoom in/zoom out, all within the Jira app. We began our Structure implementation in early 2015.
How did you configure Jira Software to meet the unique needs of your organization?
1. We created additional levels of hierarchy that allowed us to better organize our work.
We developed custom issue types we call “Features” and “Goals” and a custom issue link type we call “contains <-> belongs to”. This allowed us to create two levels of issues “above” Epic and accurately model how we were doing development as well as how we coordinated dependencies across multiple teams.
Product Management creates Feature tickets, then Development breaks each Feature down into Goals. Goals are broken down into Epics, and then Epics are broken down into Spikes, Stories, and Sub-tasks. Each issue is linked accordingly via the issue links. For example, a Feature “contains” several Goals, and each Goal “belongs to” a Feature. Similarly, each Goal contains several Epics, and each Epic belongs to a Goal.
2. We used automation to streamline the workflow of our growing team.
Once these tickets are created and linked together, the Structure app comes into play. In the early days of Structure, building a “tree” of Features, Goals, Epics, Stories and so on, and keeping it up to date, was a bit fiddly and labour-intensive, but ALM Works has steadily improved the tool to the point where we can now construct a Structure tree with the following:
-
A one-line JQL “inserter”, which pulls in Features for a specific Release (and often from a specific Project), and
-
3 “extender” generators:
-
A contains <-> belongs to links extender, which pulls in the Goals and Epics,
-
An Epic Links extender, which pulls in the Stories, Spikes, etc., and
-
A Sub-tasks extender, which pulls in, not surprisingly, any sub-tasks.
-
(The entire process takes longer to describe than it takes to implement!)The resulting tree will update itself automatically as new Features are created, and other issues are created and linked to issues already in the tree. There are additional controls for grouping, sorting, and filtering, which we use to group Features into A-List features and B-List features. Structure also supports drag and drop to re-rank or restructure the tree as needed, and provides columns for 𝚺 Original Estimates, 𝚺 Remaining Estimates and 𝚺 Time Spent, all of which provide roll-ups from the bottom to the top of the Structure tree.
3. We leveraged data in our project planning.
Structure gives us a real-time readout on how much work is remaining on each Feature in progress, which allows us to spot trends and adjust the plan as needed. Development managers and team leads can quickly and easily zoom in from the Feature level down to the specific Story and Sub-task level to see anomalies, and start to ask questions to understand the situation. And conversely, developers can always look up the tree from their current story to see the larger context/bigger picture of the Epic, Goal, and Feature that their story is contributing to. All of this allowed us to communicate project status, scope, and tradeoffs to the rest of the business more clearly and accurately, and made it easier for other teams across the organization to plan their work.
What are some best practices you could share to help other admins who are looking to extend capabilities via apps?
-
Choose a hierarchy model carefully, and apply it consistently. If you decide on Feature → Goal → Epic → Story, don’t break the model by linking Stories to Features, for example. It will make the generators for building the tree much more complicated and will also complicate any filtering and reporting you may want to do down the road. Jira and Structure are supremely flexible, but a “free-for-all” approach can give you headaches later.
-
Name your Issue Link Type so that the description of the “inward” link is alphabetically before the description of the “outward” link. For example, when looking at a Goal, the single “belongs to” link is shown above the many “contains” links.
-
Implement a No Double Counting (NDC) Rule for Estimates. Our approach to estimating is to record a rough estimate at the Feature level. Then, as the Feature is broken down into Goals and each Goal is estimated, subtract the child estimate value from the parent’s remaining estimate, and so on down the tree. This will ensure that the 𝚺 Remaining Estimates rollup column in the Structure always shows a realistic assessment of the outstanding work.
In general, what is one pro-tip you could give to someone who’s a new Jira admin?
Structure for Jira from ALM Works has become invaluable to our team by enabling us to “see the forest for the trees”. My pro tip for new Jira admins is to set up a sandbox project (we call ours “JSB”) (if you’re on Jira Software Premium, a sandbox instance is even better) and try stuff out! The Atlassian Support team and the Atlassian Community are very helpful resources, but there’s no substitute for rolling up your sleeves and getting your hands dirty 🙂
Thank you for taking the time to read my story! Let me know in the comments below if you did something similar at your company or if you have tips and tricks of your own to share! Ping me on LinkedIn!
Thank you so much for sharing your insights, Kelly! ❤️
Are you inspired by Kelly's story? Do you have a story of your own that you’d like to share? Check out our call for submissions, and let us know you’re interested in the comments below! 🙌🏼
Was this helpful?
Thanks!
Rachel Tang
4 comments