For a mainframe organization that is beginning their “Agile transformation,” it is quite expected that JIRA will be the software of choice for managing software development projects.
Agile and JIRA go hand-in-hand, and rightly so, but it is important to take a step back and acknowledge that these are two very different topics. It is entirely possible for a team to be Agile without any expertise in JIRA. In fact, it is recommended that a team learn Agile concepts first, before diving into the tools.
Agile is the ‘mindset’, Scrum is the ‘practice’ that helps us be Agile, and JIRA is a software tool that is tailored to work best with existing Scrum/Kanban practices.
It is very likely that while a team will fully embrace Agile or Scrum values, it will struggle with JIRA. This struggle sometimes leads to an overall frustration with day-to-day tasks and unfortunately could result in a shunning of the Scrum practice altogether.
While slowly building familiarity with Jira, a Scrum team should always prioritize upholding the values of Scrum over all else. The “clerical” aspects of JIRA can be handled by the Scrum Master (SM) or the Product Owner (PO), leaving the team free to focus on customer deliverables.
While not comprehensive, a quick understanding of the five Scrum Values (Commitment, Courage, Focus, Openness, and Respect) and how they are reflected in JIRA could be as follows:
Scrum Value #1: Commitment
Upholding the team-approved Definition of Done (DoD) and creating an increment (sprint commitment/ sprint deliverable) that meets that DOD consistently.
JIRA Activity: Moving cards to “Done”
If the team is still new to the concept of breaking down work into sprint-able chunks, it is likely that JIRA cards will not meet the DOD at the end of a sprint. Teams should not feel pressured into closing cards merely to influence metrics such as “velocity.” True value delivered to users will trump fake velocity any day! “Carry over” the cards into the next sprint, and review with the team how any further detail/breakdown can be added to the card. Breaking down the solution/plan is sometimes not possible upfront because the path is not clear either due to increased complexity or because the “area” of code changes is new to the team’s existing skill set. In the retrospective you should discuss ways to produce better stories that can be delivered in a sprint.
Scrum Value #2: Courage
Understanding that fast paced changes are our reality and sometimes the only way to fulfill the requirements is via taking informed risks and delivering Minimum Viable Products (MVPs).
JIRA Activity: Creating epics to organize the iterations as the feature matures. Each epic has multiple stories with potential “links” to each other, denoting dependencies and blockers.
Teams should not feel pressured to deliver a large number of changes in an unreasonable duration simply because they exist as one epic, or because of how the stories were crafted. Instead teams should feel comfortable expecting a mature feature (beyond MVP) will take several iterations, with corresponding epics, to complete (MVP, Phase 1-Enhancements and so forth).
The SM or PO can work together to maintain the intricate web of story relationships or dependencies that sometimes span multiple teams. To a new user of JIRA, the abundance of customizable fields, labels…etc. can be quite daunting. JQL (Jira Query Language) can help but only if the team has had enough time to get familiarized with these tools.
Scrum Value #3: Focus
Various scrum ceremonies, especially the daily stand-up to collaborate on progress and share new information, helping the team to adapt at frequent intervals.
JIRA Activity: Reviewing the daily “burndown” chart, maintaining the “swim lanes” during a sprint, and the backlog throughout the project.
Focus on getting to the MVP and not throwing something together just to finish it by the end of the sprint. Focus on the goal, not the journey. The SM or PO should be able to assist with any “clerical” help in JIRA (changing card status, switching swim lanes, adding comments etc.) until the team members are familiar with the software. As long as a teammate shares what changes need to be made, anyone can help capture and reflect that information in JIRA.
Scrum Value #4: Openness
Openness to sharing progress with our stakeholders, as well as openness to feedback and collaboration.
JIRA Activity: Modifying stories, creating additional tasks/ sub-tasks as needed. Adjusting the backlog priorities accordingly.
Do not limit the sprint review to a formal presentation of fully working software, the team should share interim progress and adjust based on the feedback received. JIRA cards are not set in stone, we can make any changes to suit the team’s needs while maintaining honesty and transparency.
Scrum Value #5: Respect
The entire scrum team attends sprint refinement, planning, review, retrospective and other collaborative meetings. This promotes respect for each role, accountabilities, and diverse perspectives.
JIRA Activity: Update Jira based on the team’s current understanding of the ask. Ensure any team or team members impacted by a change are notified.
JIRA cards often need to be updated based on the results of meetings. It helps to note individuals that have provided input, especially in cross-team meetings. As long as the team is participating in the scrum events, the “clerical” side of things in JIRA can be handled by the SM or the PO.
Timely delivery of commitments is what matters in the end. While JIRA helps the process with transparency and clarity, teams should remain focused on the deliverable while slowly building familiarity and proficiency with this additional software.
