Jira Heroes: How Dave Fey leveraged workflows to improve communication and transparency
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 Dave Fey, the manager of the Product Support department at Two Barrels, who shares how he leveraged workflows in Jira Software to improve communication and transparency across the organization.
Please introduce yourself! Tell us about where you work, your role, and the team you’re on.
Hello Community! My name is Dave Fey and I manage a Product Support department at Two Barrels. Two Barrels is a subsidiary of Registered Agents Inc. and services our parent company’s tech needs. We provide full stack capabilities for our Product teams and Ops groups including IT, Marketing and Design teams, through front-end and back-end software development teams.
My Product Support team are the organizational gurus who keep all of the product teams’s projects focused and moving forward. I build workflows and processes for Project and Operations teams at Two Barrels to follow various Agile (mostly Scrum and Kanban) concepts.
Outside of work, you can find me designing and building, well, almost anything we need or want at my house or for family and friends. I’ve started dabbling in 3D printing and am super-excited about all the possibilities this offers (including some custom car parts in the works).
Tell me about what your company was trying to achieve and how that informed the way you thought about configuring workflows in Jira Software.
Background
I was hired at Two Barrels to help identify and solve why teams had difficulty completing work and communicating with the business. I spent a lot of my initial time at the company reviewing the various systems each team used, how they worked day by day, the type of work they were doing, and how they communicated. All of this was in the hope of not only learning if the perception that teams couldn’t deliver or communicate was real, but to also identify how teams could work together more efficiently, deliver on time, and communicate in a consistent manner.
One thing that jumped out was that every team at the company was using different tools to manage their day to day work. Each of these tools promoted “unique” (fancy word for different) workflows and drove updates in a variety of ways. The word “different” stuck out on everything I saw. Every tool, different. Every workflow, different. Every status, different. Every possible way of communicating, different.
I could have begun implementing a solution from a number of different angles, but thought a full-blown ground up approach at building “one system to rule them all” would give us the best chance to change behavior and perception.
I found it interesting that only one team used Jira to track and manage their work, and even more interesting that this team was perceived to have the most difficulty completing work and communicating. I often heard the business mention that they didn’t understand Jira and didn’t see much value with the system. While I didn’t have a history of using Jira before joining the company, I’d worked with similar systems in the past and recognized the potential a system like Jira could provide in terms of process, standardization, and communication. If designed and implemented correctly, I felt Jira could help address some of the challenges my company was experiencing.
The challenge
Initial work on the overhaul project began with rolling out a two pronged approach.
Prong 1 was educating teams on Agile (Scrum and Kanban) methodologies so we could establish some commonality across teams, such as how to define, estimate, collaborate, etc. I needed everyone to start speaking the same language and understand the importance and benefits of working within these frameworks.
Prong 2 was working to leverage fewer systems to track and manage work across all departments, in order to drive consistency within our process and communication.
My Prong 1 approach involving education was straightforward but required putting together a few different training courses covering Agile and Scrum methodologies: what it was, how it was different from what they were doing today, and most importantly, how and where it would benefit them on a day-by-day or sprint-by-sprint basis. All teams that went through this training embraced the new concepts, which focused on using Scrum methodologies as guidelines rather than a strict approach to completing work, and were eager to get started.
My Prong 2 approach involved more behind-the-scenes work to get started. Jira was going to play a key role as the core application we leverage, since it checked all of the boxes for how we would address the current challenges. Transparency, check. Collaboration, check. Consistency, check. Communication, check.
Since we already had Jira in house, I didn’t have to get anyone to sign off on a new system. However, I did have to convince everyone that a simplified and consistent approach in how we built out the Jira boards, rules, etc., was critical so we could address the business challenges listed above.
Initial success
Once the training sessions were complete and the new Jira boards rolled out to everyone, we immediately saw success: visibility of what everyone was working on, through some simplified dashboards and custom reports.
Once we had a couple of sprints under our belt, we began to see how consistent processes, where we plan out just enough work to accomplish short-term goals, began to demonstrate we could in fact deliver what was promised.
What was being delivered was a different question that nobody was asking until we could communicate with everyone what our plans were and whether we were able to complete said plans.
Taking it further: mapping out a workflow with a team
I recently started working with a new team, let’s call them “Team A”. This team had been formed from a very different side of the business than Two Barrels but was running into similar issues that Two Barrels teams experienced: organization, transparency, and communication. They were using a couple of different systems to manage their day-to-day work and tracked it via some good old-fashioned sweat and tears (literally tears, from what they said).
After spending some time with this team and learning about their challenges, I suggested we look at the approach taken at Two Barrels. After a brief introduction and show-and-tell on what tools like Jira Software and Confluence can do for a department like theirs, they immediately wanted to learn more about Agile, Scrum, and Jira. I walked this team through the same training and Jira setup as the other Two Barrels teams and began having them walk me through a day in the life on their team.
Team A had an interesting challenge with how they approached projects. They had a difficult time managing projects consistently. Spreadsheets were all they had but they struggled with how to manage the project itself at a high level, as well as how they would break the work out and assign it to individuals. Given how they perceived projects and work itself, I knew that any Jira board configuration introduced to this team would have to be modified from what I was rolling out to other new teams.
I stressed the importance of building out project plans, to help define the work at a high level so everyone knew what problems they were trying to solve as well as calling out how they intended to solve the problems. I showed them how to plan out this type of work in Confluence by leveraging some custom templates and workflows, but we also needed to streamline the work itself in Jira as to how we built and assigned the stories.
Other Two Barrel teams were able to leverage simplified, streamlined workflows to start out but Team A projects had three specific phases of work with each requiring different instructions. There were standard or similar types of work Team A was responsible for that the initial Jira board configuration would support, but we needed some enhancements for the project work on Team A.
How did you customize the workflow for a team that had a different way of working than the rest of the organization? What were the results?
Recognizing that the initial Jira board configuration would satisfy the “standard” work for the team, ie: Bugs, Chores, Stories, the focus in this deep dive was on the enhancements we made to my initial configuration and how those changes helped Team A.
For any enhancements to work, we needed to understand 1) exactly what the project work looked like and how it was different from the standard stories, and 2) where we could optimize existing processes to save time and effort from their existing workflow.
Team A and myself sat down and walked through all details for each of their current projects at a high level: what they were tracking in spreadsheets and how they created work for individuals on the team. While there were many different spreadsheets (one for each project) things became more clear with each passing story. Projects were assigned to the team by the business. High level details about the goals were given, but the only information Team A could provide the business was when everything was completed for a given project.
I explained how we could still use spreadsheets to help track things per project but I showed Team A how creating an Epic in Jira could be used to help consolidate work to a project itself. We could capture requirements and any information helping the team define what “done” and “success” means in the Epic itself. But creating the Epic only helped us with high level project details. As we dug into the work itself within each project, we found that all work for every project they have ever done consisted of three similar types or groups of work and that there were always 52 areas within each group they needed to complete.
Organizing three groups and 52 “areas” began to take shape. We discussed creating new Issue Types: Phase 1, 2, 3 that could represent the three groups in story form. The new issue types would allow the team to better view and manage the project work while being able to differentiate from other “standard” types of work the team had on their board. Each Phase had the same set of basic rules to follow from project to project as well as the 52 “areas” within each phase, so we established unique details for each of the three phases and built those into the [Description] field.
In addition to pre-populating the [Description] field for each Phase we wanted to introduce a custom checklist for each phased story. I built a custom checklist for each phase and then saved it as a template, which would then allow me to set it as a default for the new issue types. Once I had three new checklist templates created, I set each as a default to their respective issue types. Automatically adding “Checklist Phase 1” as a default to a Phase 1 story (2 to 2, 3 to 3) eliminated the need for a user to manually select a checklist from a drop down list when creating stories for that phase. This seemingly simple step of auto-populating the [Description] field and linking a custom checklist to each new Phase provided consistency to story creation that had never existed on this team and eliminated user error when creating new stories.
Now we could manually create a story for each of the Phases but given we needed 52 of them, each with slight differences, we needed to leverage Jira automation to continue our consistency and efficiency goals. The first automation rule we built was for creating Phase 1 stories: we called it “Create Phase 1 stories”. The automation rule needed to run from a manual trigger which required the issue type to be an Epic, meaning we had to trigger the rule manually from the Epic itself. The manual trigger of the rule would need to build 52 stories as a specific [Issue Type], linked to a specific [Epic], placed in a specific [Sprint], containing a shared [Description], specific [Labels], and a unique [Summary]. After some debate, we decided to push all 52 newly created Phase 1 issues via the manual trigger into the backlog as opposed to the active sprint to allow the team to manage their work better through sprint planning. Now with a click of a button from within the project Epic itself, a user could automatically create 52 Phase 1 stories. This automation rule greatly improved our efficiency and provided a huge time savings for generating 52 Phase 1 stories.
Now that we could create 52 Phase 1 stories, how were we going to continue that in an automated fashion for Phase 2 and Phase 3 stories?
We needed new automation rules for Phase 2 and 3. The automation rule for creating Phase 2 stories (and eventually Phase 3 stories) was created differently than our Phase 1 automation rule. First, we didn’t want to flood the system with Phase 2 and Phase 3 stories that could sit in the backlog for a long time, because the larger the backlog the more difficult it is to manage. We created a “Phase 1 to Phase 2” automation rule based on when a Phase 1 story got moved to a “Done” status as opposed to manually creating like we did with creating Phase 1 stories. The rule was built off an Issue Transitioning to Done and equaling the “Phase 1” Issue Type. We added custom [Description] info and once again chose to push these stories into the backlog. We wanted to carry over the Phase 1 [Summary] but wanted to append some new text. Adjusting the [Summary] proved challenging but we did find a way to use the existing [Summary] and append the text we wanted: “{{triggerissue.summary}} new text” in case you were curious. After looking over the “Phase 1 to Phase 2” rule we realized that a “Phase 2 to Phase 3” rule could be created exactly the same way and provide exactly what we needed, on-demand story generation for Phase 2 and Phase 3 stories.
Testing the workflow and rules
We were now ready to turn all the rules on and test everything out. “Create Phase 1 stories” rule worked great, 52 new stories with all details needed were created and all linked to an Epic. We continued testing by closing out Phase 1 stories and waited patiently for Phase 2 stories to be created. Once Phase 2 stories automatically showed up in the backlog we quickly rushed them into the current sprint and transitioned them to Done, thus creating Phase 3 stories. The automation rules were working exactly as we intended. We saved a ton of time creating consistently built stories for each Phase and managed how and when we introduced each story onto the board. We were now ready to set up an Epic for our first real project and run everything for real.
Learning and adjusting after launch
As you can probably guess, once we set up the “real” Epic and created our first 52 stories, something new came up. Shortly into our first sprint we were ready to close out a Phase 1 story but realized we needed approval to fully complete the story. Approval came from outside the team and could take a long time. In addition to the need for an approval, it was also discussed that we should prevent a user from creating or really starting on any Phase 2 stories until we have been granted approval on Phase 1 work.
Given this new approval information, we held a Retrospective at the end of the sprint and discussed different ways to approach the challenges of committing to completing work in a sprint yet relying on approval from outside the team. Knowing the importance of making sprint commitments, we needed a better way to manage Phase 1 stories. We decided the best path forward was to recognize there were really two parts to Phase 1 stories: the work we can control and the work we need assistance with. So we decided that we could split Phase 1 into two parts: the first part of Phase 1 would be considered done when we completed the work assigned in the story itself and submitted it for approval, while the second part of Phase 1 was working with an approver to obtain approval.
Once we had agreement on splitting Phase 1 into “Phase 1” and “Phase 1B” work, we needed to modify a few things. We needed to create a new Issue Type (Phase 1B). The Phase 1B issue type needed to contain some custom text in the [Description] field but we also wanted to capture the approval discussion.
So, we created a new [Approval Notes] field where all notes related to the approval process would be captured, and we applied it to only this issue type. In addition to the approval notes, we wanted to prevent the creation of Phase 2 stories when we closed the new Phase 1B, so we created a new checkbox field [Approval] with only one option “Yes”. We decided that if and only if a value of “Yes” was selected the team felt confident to move forward to Phase 2 stories. Knowing that Jira keeps history with all changes, we could easily see who selected “Yes” if we ever needed to investigate false positive stories.
Now that we had 2 new fields (approval notes, approval) applied to Phase 1B stories we needed to rename the existing “Phase 1 to Phase 2” to “Phase 1 to Phase 1B” and modify the rule by changing the issue type we are creating to Phase 1B. Modifying an existing automation rule proved very easy so changing the rule name and modifying the issue type didn’t take any time at all.
In addition to the existing rule change, we needed to create a new “Phase 1B to Phase 2” automation rule. Once again, it was extremely easy to “copy” an existing rule and make a few changes: rule name to “Phase 1B to Phase 2”, added new text in the [Description] field and changed the issue type.
The only other item we needed to address was how to prevent someone from closing a Phase 1B story without approval. We added a transition rule to our Done status for only Phase 1B stories by adding a “Restrict transition” rule where the new [Approval] field had to contain the “Yes” value or we would NOT allow a user to mark the story as Done.
Once again we tested the new rules from closing out Phase 1 and automatically creating Phase 1B. We tried closing out Phase 1B stories but were prevented until we had the “Yes” value as designed. Once we had the “Yes” value in the [Approval] field we were able to close out Phase 1B stories, which automatically generated Phase 2 stories. Everything was working as designed, so back into our sprint cadence we went. Since we made this change relatively close to when we started, we only had a couple of Phase 1 stories that needed to be re-closed to generate Phase 1B stories but once we had that we were able to properly plan for our next sprint.
How it turned out
The addition and customization of Jira has provided many things to our business and Team A. We have addressed consistency and efficiency issues and begun to communicate in standard ways not thought possible before. We now have teams like Team A that spend more time planning for the upcoming work than they do creating the work itself. Communication has completely changed between the business and teams. Now that we all speak the same language (thanks, Agile) we communicate more often and with greater purpose. Sprint Goals have provided everyone with insight never before seen and follow engagement with people from outside the team.
Thinking back, what are some best practices you can share to help others as they think through their own workflows?
I have always found that no tool itself solves problems. You need to have a full understanding of what the business wants and needs, in addition to the ability to leverage tools (such as Jira) that allow for customization.
Jira has done a good job at giving us, the users, tools to customize boards and workflows as needed, which is perfect when you realize that all teams are different.
While the ability to introduce automated rules provides countless ways of eliminating repetitive chores and preventing silly mistakes, it also empowers us to re-think what workflows should look like as opposed to just doing things the way they have always been done. I won’t sit here and tell you to add field X or field Y to improve anything, nor will I tell you that automation always saves the day. I will say that if you find yourself doing the same thing over and over you really should start looking into automation.
In general, what is one pro-tip you could give to someone who’s a new Jira admin?
Define and test as many use cases as possible before deployment. Even little or simple changes can have a big impact on teams (good and bad).
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! Connect with me on Linkedin.
Thank you so much for sharing your incredibly insightful story, Dave!
Are you inspired by Dave’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