Let’s Sprint on JIRA

Photo by Louise Viallesoubranne on Unsplash

JIRA is to Product & Project Managers what a bread-spread is to a bread. Most Product and Project professionals are well versed with what JIRA is and probably use it on an every day basis. Even though every member of the project team uses the board to document updates on their work, it is owned by product managers or projects managers in most cases.

In my experience, we often end up underestimating its potential and capabilities, with some of the opinion that it is an additional effort and can be counterproductive. I personally could not disagree with that statement more, provided we know how to leverage the tool right. I truly believe that every optimization and management tool when used right is a huge lift, and when used inefficiently can turn out to be cumbersome.

The purpose of JIRA

Needless to say, JIRA serves as the book of record for everything that needs to be done within a project. Many have the notion that it is supposed to be used primarily to capture the work done by the development team. And the truth is far from it. If used creatively, one can leverage JIRA to track every single item being performed within a project effort — from requirement gathering, configuration set ups, deployment efforts, action items within the umbrella of a feature, to so many more use cases.

Our goals are as follows:

1. To list down everything in one place for us to keep track of progress
2. Capture blockers or dependent actions/ tasks that need to be completed before we can say an activity has been completed
3. Quantify the time taken to complete each action item/ activity measured in story points

Examples of user stories capturing action items of various flavors:

1. User stories for gathering business requirements with subtasks for time spent on documentation (BRD)
2. User stories for development work broken down into subtasks for dependent steps such as access to environments (non-prod and prod), as well as configuration action items
3. User stories for technical analysis
4. User stories for Testing (this could also be a sub task under a story if the team has dedicated testers simultaneously performing testing activities)
5. User stories to track product demos to business stakeholders and feedback

How can we JIRA better?

Even though the JIRA board owner has the freedom to set the structure and protocol in ways more than one, it only helps to know the breadth of JIRA capabilities to determine our own unique way of doing things. Let’s discuss how we can do better.

1. Use Epics to categorize different buckets of functionalities for associated user stories to be mapped to

Note: JIRA provides a quick summary of how many stories are tagged to each Epic with a snapshot of details of how many stories are in Not Started, In Progress, Completed status under each Epic.

2. User labels to subcategorize these user stories to sub functionalities

For example:

• Document_section
• Comments_section
• Landing_page
• Dashboard_UI

Note: This can help further filter out or breakdown action items based on subcategories for reporting and tracking purposes.

3. Create subtasks within stories for tracking action items

For example:

Epic: Gathering Business Requirements for XYZ platform

User Story: Gather business requirements for Login Page for XYZ platform on the landing page

• Subtask 1: Receive a walkthrough of the current day scenario
• Subtask 2: Gather business requirements on the ideal state
• Subtask 3: Present a mockup/ wireframe demo to the stakeholders
• Subtask 4: Get stakeholder approval

Note: This can help capture all steps that need to be completed in order for us to be able to call the item complete. It also gives you the flexibility to assign a subtask individually to another team member even though the user story is assigned to a specific team member.

4. Leverage Comments Section

Leverage comments section to track discussions or additional updates that need to be captured.

5. Leverage and set protocol for different statuses of user stories and tasks

For example:

• Not Started: Work hasn’t begun
• In Progress: Currently being worked on
• Dev Complete: Development work has been completed
• Ready for Testing: Ready for testing personnel to pick up the user story/ task for testing
• Defect Fixes: When the dev team is working on resolving bugs found during testing
• Testing Complete: Testing activities have been concluded
• Ready for Deployment: Ready to be deployed onto higher environments
• Done: Completed

Note: These statuses, status names and status routings within JIRA can be configured for your board based on the team’s preference and protocol. A lack of clarity within the team on statuses can cause confusion, delays and missteps.

6. Leverage the ability to link user stories, tasks and defects

The ability to link defects to user stories can be super beneficial for testing as well as tracking purposes making it easy to identify why a user story is not progressing.

• It could be blocked by another another user story which is a pre-requisite
• It could also be blocked by a defect
• It could be blocked because of a task related to configuration set up

7. Ensure that Acceptance Criteria and user story descriptions are clearly and concisely defined

• Acceptance criteria is a guide for the development team for unit testing to prevent multiple cycles of testing that can be avoided
• Story descriptions need to be such that it clearly defines all the details needed, it should also be broken down to a level that can be completed within a sprint according to the measure of story pointing — also fares well when analyzing Burndown Charts

8. Tackle ‘In Progress’ stories at the end of a Sprint

• When a story is ‘In Progress’ at the time of closing sprint, you can create a new clone/ duplicate story for the next sprint so that efforts spent on the current sprint are captured at the right place.

9. Leverage Release Management

• Tags user stories and epics to a release to track which feature was deployed into Product at what point in time
• Follow release naming protocols for product releases and hot fixes that are intuitive and easy to comprehend

10. Create customized JIRA Dashboards with widgets that provide you ready-made summaries of the data most relevant to you

While there is a lot more that JIRA has to offer, I hope we continue to discover those tricks and tips as we continue to experiment and dig deeper.

Additional benefits of JIRA to Project Managers

As a Project Manager you often prepare status reports at various level of detail for various audiences. One has the freedom to slice and dice the JIRA report to derive and arrive at valuable insights quickly and more efficiently.

Some uses cases where following a good JIRA Management protocol comes in handy:

• For your stakeholders you might be preparing a status report capturing progress at the Epic level to demonstrate % of completion
• You can also quantify the amount of effort needed, as well as for resource planning to estimate and present project timelines based on Sprint Reports that capture velocity of the team per sprint
• You may also be leading Defect Management and might want to summarize defects logged per release categorized by Severity to discuss how the team can improve
• You may want to track team performance using Burndown Charts (one of the many reporting capabilities within JIRA)

The ways in which you slice and dice JIRA data are endless but the key thing to realize is that when JIRA is used right, you have the freedom to filter data at the level of granularity of your choice, with the filters you want. It is essentially like SQL — you don’t write a query but achieve the same results with a front end that is user friendly and more visual, making it easy to navigate through.

Hope we can help ourselves in making our 9–5 more optimized and smooth like butter!