What Agile Tools Should We Use to Plan Our Work?

What Agile Tools Should We Use to Plan Our Work?

by | Aug 26, 2021 | Agile

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.

How much should I Budget for Agile (and other frameworks)?

How much should I Budget for Agile (and other frameworks)?

by | Aug 9, 2021 | Agile

Agile Processes

When an organization starts out its processes are loosely defined. Why complicate things? When there are few parties involved, communication can remain informal. It’s usually easy to get in touch with each other. Transparency is preferred because of the close relationships held with the people involved. In many cases this is often an advantage. There are few bottlenecks from endless rounds of approvals needed, and things can be done on the fly without the need to document everything. This allows workflows to be executed quickly. However, as a company expands to bring on more complex customers, hires more people, creates more teams, and hires individuals to manage those teams; things can quickly become much more complicated. Expectations can be increased unevenly across teams.

In many cases, individual teams are allowed to manage their own development process in their own silo. Sometimes different teams can adopt their own development tools as well. This can often happen in a situation where a new team is acquired through a merger and the newly acquired team already has its own processes and tools in place. The leader of the organization might see this growing chaos and feel the need to create order. Decision makers look up the Agile Manifesto and see: “Individuals and interactions over processes and tools.” Does this mean that we are “Agile” if everyone is allowed to do whatever works for them?

One of the common misunderstandings of the Agile Manifesto is that “Agile” means “Do whatever works for you.” But if we take a closer look at the phrase “While there is value to the items on the right, we value the items on the left more.” – we can come to a similar conclusion: While it is true that we value individuals and interactions more than we value processes and tools, that does not mean that processes and tools have NO value. In fact, poorly defined processes and the wrong tools can lead to individuals having more frustrating interactions with other individuals – their teammates, vendors, and in the worst event even customers.

The way to show that management values the time of their employees is to make the process for the worker more efficient. If Team A has Jira but Team B has Trello and their work has dependencies on each other, not using a common tool can adversely affect communication and thus interactions between the individuals on those teams. 

Often when problems crop up and organizations look for efficiencies, what tools each team can use for development becomes a decision that is based on cost efficiency rather than team efficiency. Many times, when deliverables become delayed and communication breaks down, the first instinct is to bring in a new tool that all the teams can use. While this can help account for some disfunction an organization may face, in many cases the software development processes that are used by disparate teams become the cause of more problems.

Even if the CIO has taken the lead to bring multiple teams on the same development platform, they haven’t accounted for the process that must be followed now that everyone shares a common platform. While there is value in bringing in a new development platform like Jira Software – this is only one half of the necessary solution. It’s important to give users training on how to use any new platform. This is a necessary consideration so that teams can use the new platform effectively. It’s also necessary to train your teams on using a common development process framework (with some allowable customization between teams). While this all sounds great, as a CIO we think to ourselves: We are already spending some budget on the new tool – implementing the new software development platform – Jira Software. How much should be budgeted for processes?

Questions to Ask When Budgeting

Who in the organization owns the software development process?

How much customization of the software development process is actually needed by different teams?

Is it due to product differences or differences in delivery expectations?

Is there a way to measure our success and efficiency across different development teams?

Do we have any experience with the Agile framework development methodologies like Scrum and Kanban?

Have we put oversight roles in place to make use of these methodologies successfully?

Do we have an individual with the right expertise (and time they can devote to it) who is able to lead an effort to standardize our processes and measuring results across teams?

Does our current company culture accept change easily?

How entrenched are old habits?

Implementing Agile Methodologies

  • Empower Team Leads (or Scrum Masters) to form a Center of Excellence and own the organization’s Agile training: For this to be effective, you need very dedicated resources with the right expertise to lead the initiative. Often, it can be hard for these individuals to find enough time to work on the effort to go Agile. The Atlassian Agile Coach offers information and tips that your organization can implement.
  • Budget Agile Training into your training department’s program: If your organization has training classes, this can be a way to ensure that your associates at least have a day of classroom time devoted to learning Agile. While this can be a good start for those without Agile experience, it’s important to learn continuously. Ascend Integrated offers the Jira Essentials with an Agile Mindset class which both teaches how to use Jira and how to use the Agile Framework with Jira. For more information about Agile classroom learning contact Ascend Integrated.
  • Structured Agile Transformation: This would be a top down organization-wide initiative that places importance, time, and a monetary budget on developing the Agile Framework. This works best with hiring a third party agile expert with experience with multiple organizations and situations that can get measurable results without the need for an internal individual to have to devote time and effort. With a third party leading an Agile Transformation, they can also have the authority and ability to motivate others. Ascend Integrated can lead the way at your organization with Agile Coaching and Process Consulting.
  • Scaled Agile for Enterprise (SAFe) Implementation: This is the most comprehensive methodology. Plan for a minimum of at least a half year (two quarters). For companies with 125 individuals or more, this can be a way to manage both individual teams and teams of teams. An outside third party leads the implementation and helps develop the organization’s individuals who will be owning the agile process in the future. Ascend Integrated is a Scaled Agile for Enterprise Bronze Partner and can enable a SAFe transformation with using the Jira Software suite or other tools at your organization.

For more information to help determine what the best path to Agility would be for your organization, contact Ascend Integrated. Ascend Integrated is a Atlassian Partner.