Using JIRA Does Not Make You Agile

How you use “Agile” support tools could sabotage your agility

How an organization uses “Agile” requirements management and team collaboration tools like JIRA is an indicator of how well that organization aligns its management of software systems development with Agile software development.  The least “Agile-mature” organizations attempt to manage Agile projects with traditional project management biases and expectations.  Such organizations often use Agile requirements management and collaboration tools to track and report:

  • Traditional project management metrics
  • “To-do” lists of unprioritized and unsized items written like traditional requirements or developer work tasks

All the while, organizational leaders and management assume they are “Agile” because they are using “Agile” tools.

The Place of Tools in Agile

Before expounding on these two general misuses of Agile requirements management and collaboration tools, let’s go over what the Agile Manifesto for Software Development says about tools.  Agile values, “Individuals and interactions over processes and tools.”  While Agile teams institute processes and use tools to manage their work, they value direct interaction between individuals more.  Under this construct, tools are enablers that facilitate communication between team members and project stakeholders.  They are not substitutes for direct communication. 

Agile prefers face-to-face communication over emails, phone calls, project tools, formal boards, documentation, etc.  This way of communicating increases agility by avoiding the use of intermediary channels, documentation, and reporting structures that often slow and distort communication.  It also prevents formalizing decisions too early, which unnecessarily narrows options and commits development teams to approaches that may prove wrong after having spent significant time, money, and resources implementing them.

However, not every interaction in and among Agile teams can be face-to-face.  Agile development teams with members who work remotely, and enterprises staffed entirely with remote teams, are common.  While Agile best practice is to collocate teams and team members, it is not always possible.  For example, the project team may be too large to depend solely on direct communication between members. 

Agile requirements artifacts are purposely lightweight. They work as reminders for future conversations that will flesh out details. However, even lightweight requirements become difficult to manage as they grow in number.  Requirements management and team collaboration tools help document and track requirements, manage work, and report progress.  They also help bridge distances and time zones between collaborators.

Project Metrics Tracking

The types of metrics relevant to traditional vs. Agile projects are different.  Traditional project management is concerned with managing the constraints of the Iron Triangle: Cost / Budget, Schedule, Scope, and Quality.

Iron Triangle
Figure 1: The Iron Triangle

Fixing the former three constraints leaves quality as the only variable, opening the door to sacrificing quality to adhere to the other constraints.  We can sum up the Iron Triangle with the adage, “I can get it to you cheap, fast, or good.  Pick any two.”  On the other hand, we manage Agile projects primarily by managing scope.  We fix schedule and budget while treating project scope as variable and not sacrificing quality.

Traditional Project Metrics

Keeping the first three constraints of the Iron Triangle fixed throughout a project requires adherence to detailed project plans.  Changes to those plans are highly frowned upon since even small changes can ripple across project plans in unexpected ways.  Thus, traditional project managers focus on managing people and tasks to keep projects on track with plans.  This leads to collecting metrics such as the ones shown in Table 1 below:

Table 1: Common Traditional Project Management Metrics

Agile Project Metrics

Agile projects hold schedule and budget fixed while treating scope as a variable. In essence, we have a span of time, a bucket of money, and the flexibility to build just enough of what is needed to satisfy customers.  When schedule or budget run out, we can stop development or pony up more money to build more.  We also have the flexibility to stop the project at any time should we decide that we delivered enough functionality or if the project is no longer viable.  Cancelling a failing or unnecessary project after spending $10 million is much better than doing so after spending $100 million.

Since Agile teams are self-organizing, they manage their own work.  They do not need management to allocate tasks, lead estimation activities, or coordinate between teams.  Also, in Agile, “Working software is the primary measure of progress.”  Therefore, metrics like percentage complete are unnecessary (and nonsensical) since we regularly evaluate complete and releasable business or mission functionality.  In Agile, a feature is either done or it isn’t and teams do not take credit for work on incomplete features.  What “complete” means to project teams and stakeholders makes up the “Definition of Done”.

“Agile metrics” help teams:

  • Manage current work
  • Plan future work
  • Communicate project status across teams and project stakeholders

Many Agile approaches / frameworks exist.  In the Table 2 below, I provide Scrum metrics and reports as examples.  I avoid discussing the details of tracking, reporting, and using these metrics and reports in this article.  Instead, I present these examples to drive home the point that what we measure, track, and report in Agile projects is different from that of traditional project management because the two approaches are fundamentally different.  

Table 2: Common Scrum Metrics and Reports

Quality Metrics

Measuring the quality of deliverables and acting on findings is crucial to all software development projects, Agile or not.  There aren’t Agile-specific measures of quality.  However, like traditional requirements, well-formed Agile requirements specify the outcomes and quality characteristics associated functionality must meet.  In Scrum, for example, quality criteria inform user story acceptance criteria.

Tracking Traditional Project Management Metrics via “Agile” Tools

Many organizations configure and use tools like JIRA to collect and report traditional project management metrics.  This practice demonstrates a fundamental misunderstanding of Agile and how it differs from traditional project management.  It is also indicative of organizations that adopt the terminology and mechanics of an Agile approach or framework without embracing its principles.  While tools can enable Agile practices, agility is not the result of using tools.

Using Product Backlogs as “To-Do” Lists

Tools like JIRA are primarily designed to support Scrum teams.  As such, they organize work through product backlogs.  A product backlog is a prioritized list of estimated or “sized” descriptions of business or mission capabilities needed by users or roles (human or automated) to accomplish specific outcomes.  Scrum teams typically write these requirements as user stories:

Figure 2: Typical User Story Format

We write user stories from the user’s perspective, not from the perspective of the system we are building or the tasks developers need to do.

Unfortunately, it is quite common to see user stories written as system components or deliverables or as developer tasks.  Many teams also neglect to size and prioritize product backlog items until sprint planning (and sometimes not at all).  Rather than managing a product backlog, such teams work from what is ostensibly a to-do list.  Doing so takes away the ability of Scrum teams to manage current work, plan future work, and clearly communicate project status.

Conclusion

Requirements management and team collaboration tools like JIRA are useful for documenting and tracking requirements, managing work, and reporting progress.  However, using such tools is not the same as being agile, especially when used to support traditional project management processes and reporting.  Understanding the differences between Agile approaches and traditional project management is key to ensuring we avoid contorting Agile to support Waterfall processes and expectations.



Comparing WBS vs. Product Backlog – Video

Two very different ways of managing project scope

This is the third and final video of a series that explains and compares the Work Breakdown Structure (WBS) and Scrum’s product backlog. In this video, Frank Velazquez compares and contrasts the two artifacts and how they support very different approaches to project scope management between traditional project management, or Waterfall, and Agile.  This understanding is crucial for viewers implementing Agile in organizations steeped in traditional project management.



Functional vs. Non-Functional Requirements – Infographic

An infographic to help your team understand the difference between functional and non-functional requirements (NFRs)



What is a Product Backlog? – Video

The Agile Cheetah Channel explains the Product Backlog

In this video, Frank Velazquez explains what a Product Backlog is and how it supports Agile value delivery.

In his video about the Work Breakdown Structure (WBS), Frank explained that the WBS is an artifact of traditional project management that allows planners to tie together project scope with schedule and budget.  The WBS supports strict adherence to the three constraints of the Iron Triangle.

Together both videos serve as background to an upcoming video that compares and contrasts the two artifacts and how they support very different approaches to project scope management between traditional project management, or Waterfall, and Agile.  This understanding is crucial for those of you implementing Agile in organizations steeped in traditional project management.