Part 1 – Prioritizing our work and determining its complexity in Jira
In our previous blog article, “HOW MUCH SHOULD I BUDGET FOR AGILE (AND OTHER FRAMEWORKS)?” we discussed the decision making process for making an investment into your organization’s Agile processes. Jira Software provides an excellent platform for developers to track their work items such as Epics and User Stories. Jira Service Management provides a Service Desk portal for external users to report a bug or suggest a feature.
This article will focus on which tools that can be used to support the initial planning process in Agile. Scum Masters, Product Owners, and others within an Agile Team see a list of work items in a backlog and ask the following questions:
- What work item is the most important and needs to be done first (Prioritization)?
- How difficult will each work item be to complete during the Sprint Duration (Complexity)?
Referring back to our Agile process, we can focus on the two main methodologies: Kanban and Scrum in looking at how the Team can plan its work.
Kanban
Agile Teams using Kanban Methodology are interested in constantly prioritizing work so that they can keep work moving and flowing. Important work items may need to be done as soon as possible or they can be de-prioritized and worked on later.
Selecting a Single Priority Level
Jira Software includes Priority Levels that can be used to signify importance. Additional priority levels can be added. But ultimately, simply selecting a dropdown like “Highest” limits how specific we can be. What does “Highest” mean? What work items should the team pull in next if several work items have the same Priority level?
Calculating a Priority Level
Jira Automation (available per Jira project in Jira Cloud Standard and Global/Multi-Project in Cloud Premium) can be used to create a Priority Matrix. You can choose other fields to set the Priority level by a combination of field values such as “Impact” and “Urgency”. For example, if a customer documenting a bug creates a ticket reporting the Impact as “Extensive / Widespread” and the Urgency as “Critical”, then the priority for the ticket is set to “Highest”.
Jexo Foxly Backlog Prioritization (available for Cloud as a Jira AddOn) has a comprehensive Priority Scoring system you can customize to assign a numerical value to make work items easier to sort.
You can display work in Priority Quadrants to determine which items are grouped into different priority levels.
Multiple inputs for Priority
One way to prioritize issues would be to know how a certain type of user might value a user story. Easy Agile Personas allows you to create multiple personas which can place a different priority on a user story. Rather than just the Requestor’s priority, any user can see how different Personas value a new feature. Viewing the Persona may also be helpful when developing the feature.
For KanBan methodology, once a developer is free to continue working, they will select a work item from the backlog. They can see the priority and will choose the next most important issue. While due dates are important, developers who work on Kanban style teams are trying to resolve issues as quickly as possible, For Bug-fixing focused teams, it can be important to resolve the most painful ones first.
Scrum
For Agile Teams using Scrum Methodology, teams need to have a backlog that is prioritized. This is done by a product owner working with a project manager and the customer. Using the same prioritization tools as previously mentioned, we now have a list of user stories that developers can select from a backlog to complete.
The developers will now know which work items are the most important to choose first. Rather than a developer continually pulling issues from the backlog onto their board, the Development Team will select several issues at once from the backlog to work on during their upcoming sprint period (usually 2 weeks).
Now, the developers have a job to do. They need to determine how many of these work items they can commit to developing on during the Sprint. It is important to commit only to what your Team believes it can finish during the sprint. This control gives stakeholders, customers, and the project manager confidence that work will be completed on time. To determine how many stories each individual on a team can commit to, we need to look at Team Sprint Capacity. Before we address Team Sprint Capacity, we are going to discuss Work Item Complexity.
There are many ways that an Agile Team can measure the complexity of a work item, but for the sake of this article, we are going to focus on Story Points.
Story Points are a numerical rating of how complex a work item is. An item is rated by a developer in the backlog from 1-8. For example a “1” rating might be a simple task with no research required, where an “8” might be a complex work item and with no current understanding for how to solve the issue. Research, trial, and error are likely necessary to complete the work item within the Sprint duration.
Setting Complexity with Story Points
Jira Software allows a user to put in the Story Points while in the backlog:
Calculating Complexity
One way to create multiple inputs for Story Points would be to use Jira Automation to calculate the number of Story Points based on other fields. For Example: If research is needed, testing is needed, and we are not sure of a solution, then the Story Point Estimate is automatically set to an “8”.
Planning Poker – Voting on Complexity or Priority
While some teams have individuals that tend to work on their own items based on their specific skill set, other teams may have multiple individuals with the same skills (poly-skilled) that could pick up the same issue to work on. Teams of this type might hold a Poker Planning Session. With Jexo Foxly Backlog Prioritization, we can invite several users to a Poker Planning session.
During Planning Poker, several Team members will give their own estimate for a Story. We might use the same variables such as “Research”, Testing”, and “Sure of Solution” as the previous example but instead of a Yes or No answer, each voter chooses a value between 1 and 8. The scale could consist of “1” being the least amount of effort up to “8” being the most difficultly. Similarly, a group of those responsible for setting work item Priority such one consisting of a stakeholder, customer, and product owner might each vote on their own priority level. A formula can also be used to determine how to score such as “Business Value” + “Customer Value” = “Priority Score”.
Setting the Story Points using the Priority score – Automation for Jira
It is also possible to use Jexo Foxly Backlog Prioritization in combination with Automation to set other fields. For example: If the Score for an issue is above 30, then Story Points will be set to 8.
Planning as a Team
In order to determine what your Team’s “Total Sprint Capacity” will be for the next Sprint during planning, we can look to the number of Story Points the Team has completed in the past. One place to look for this information will be the Jira Velocity Chart Report, displaying the total number of Story Points committed by the Team during the last Sprint and the total number of Story Points Completed by the Team in previous Sprints.
Coming up Next
So far, we have discussed how interested parties such as business stakeholders can prioritize issues in the backlog using Jira or with an AddOn that adds extra functionality. We have also illustrated how a developer can give a rating of complexity a work item (Ex. a User Story) that is to be developed. A Team can even vote on issues during a Poker Planning session to determine the Story Points or they can calculate them with Automation for Jira. In addition, a Team can can look to the Jira Velocity Chart to see how many Team Story Point they can expect to be able to complete in the future.
The next question in planning our work is: When will the items be completed?
Let’s break this down by what each interested party wants to know:
Customers – Most customers are concerned with when they are able to see the updates released to their Production Environment, regardless of when it will be worked on by the development team.
Project Managers – Most project managers have deadlines in the form of dates or milestones based on releases.
Stakeholders – Business Stakeholders want to know when the business will see value (confirmation that a new feature is released to the customer and the customer has accepted it).
We will discuss Release Management in our next blog article of our Agile series.
If you are interested taking your Team’s Agile Processes and Tools to the next level, contact Ascend Integrated.
Ascend Integrated is proudly partnered with Atlassian, Easy Agile, and Jexo mentioned in this article.