August 17, 2018

What Tools Do Business Analysts Really Need for Backlog Management?

Post by: Kurt Wondra

Kurt Wondra is high-energy, well-rounded IT consultant who started his career as a Software Engineer and quickly realized he had a knack for business analysis and project management (as his many clients can attest to).

Whether your current role is that of a Business Analyst (BA) or a Product Owner (or you do a blend of both) and you’re in an agile environment, then you’re doing some form of backlog management. Interestingly, there are many different flavors of backlog management.

We BAs have a certain way that we like to manage our backlog, and it’s probably different from one BA to another. That doesn’t mean any one way is right or wrong; it just means there’s a lot of variety. In that way, I see many parallels in managing a backlog to writing requirements. While no two BAs would draft the exact same verbiage in a requirements document, the differing ways of presenting that information would still get the spirit of the deliverables across effectively. Clearly there are multiple ways to reach the ultimate destination.

Enterprise-Level Backlog Management Tools

Many of us write requirements, and we write them in many ways. I’m willing to bet that if we sat 10 BAs down and gave them the same information and then asked them to write out a product backlog, we’d get 10 different results. It’s interesting that a lot of us have different ways of accomplishing the same goal.

That inconsistency typically leads to the implementation of enterprise-level tools for managing a backlog. A lot of us have used some of these larger tools before like VSTS, Rally, and JIRA. These big tools come with lots of functionality. For example, in many of these tools you can utilize functionalities like burn-up and burn-down charts – which are important for running in an agile fashion. There are also tools focused on release planning, iteration planning, portfolio management, budget spend, etc.

Pros of Enterprise-Level Backlog Tools

There are many pros to these kinds of tools, such as enterprise ownership – which can bring consistency across the organization in how the backlogs of various projects and/or products are managed. Instead of each BA utilizing their own disparate tool, the enterprise is employing one centralized platform.

Paid tools typically include many built-in features that can be useful from an IT perspective because IT leaders today are often asked to manage the whole IT portfolio. That can be hard when you’re trying to mash together data and inputs from completely distinct and different systems. Sometimes it’s handy to have one system serve as that enterprise–level tool that everyone within the organization uses.

Cons of Enterprise-Level Backlog Tools

The main con of these tools is that they take a long time to set up. Other cons are that they often involve someone on the networking side to partition a server for the application, they often require security and role-based authentication, and they’re often expensive to purchase.

It’s also worth noting that, even though these tools have a lot of great features, rarely are all their features used in harmony to their fullest potential. When you’re not using a tool to its fullest potential, you’re leaving some return on investment on the table.

Another thing I often see is that (even though multiple BAs are using one platform) there’s inconsistency across the teams, namely with how the BAs are utilizing the tool. That’s where it really becomes important for the BAs at your organization to have consistent standards of how they operate and how they write their backlog items and/or documentation.

I don’t want to say that your personal flavor must take a back seat to conforming to an organizational standard, but I’m saying there should be at least some level of consistency across the different teams. That’s what a BA Center of Practice or Center of Excellence aims to do, if you’ve ever heard of that concept.

As a consultant, I see these enterprise-level tools a lot, and I see how different clients utilize different tools. Some even utilize the same tools but in different ways. This impacts us Business Analysts because it creates some ramp-up time just to learn how a given company is using the tool. My job is to try to understand how the organization is utilizing that tool so that my team can fit into that ecosystem as smoothly and seamlessly as possible.

What Does the BABOK Tell Us About Managing a Backlog?

According to the BABOK, there are four key elements to managing a backlog:

  1. You need to add items to the backlog
  2. You need to prioritize them
  3. You need to estimate them
  4. You need to manage changes

That’s it. Sometimes we BAs need to take a step back and not “scope-creep ourselves” in our day-to-day work. We need to translate what the BABOK tells us into what I call the “let’s get stuff done level”. Let’s leave all those frills out of managing the backlog and instead turn our focus to how we get stuff done fast, how we can jumpstart an effort, and how we can get up off the ground as efficiently and effectively as possible.

Your Backlog Management Tool Only Needs Three Things

First, we need to be able to collaborate with our team. We need to be able to work very closely with our product owners that are setting the direction of the product. We need to be able to coordinate with different stakeholders that are affected by the work we’re performing. We need to work with our technical leads and our other developers. We need one spot of information for our QA analysts, so they know how they’re going to measure successful delivery.

Second, we need one central location to collaborate to create the product backlog items. Whether you want to call them PBIs, user stories, cards, or any other term you use, you need to be able to create items that make up the full product backlog. Moreover, you need to be able to refine, enhance, and further document each backlog item to get it into a “Ready State” for the team to consume.

Third, you must be able to plan and prioritize that work. Items may need to bump up the priority list. Maybe an item that was top priority last month has now fallen to the bottom of the list. You’ll need a way to manage the priority of all items in your product backlog from top to bottom.

That’s what we need to focus on as BAs when we talk about the “get stuff done level”.

What We Don’t Need at the “Get Stuff Done Level”

We don’t need the service desk managing licensing and permissions about granting people access into certain workspaces. We BAs also don’t need portfolio management, release management, or even time tracking capabilities. There are several other bells and whistles and other tools that aren’t what we need to truly jumpstart the effort we’re working on.

What’s Best for Your Team? It Depends.

There isn’t a one-size-fits-all tool, no silver bullet. Different tools work great in different situations. Keep your eyes open for useful tools that other BAs are utilizing. Then take that information back to your teams, experiment with them, and learn.

Just make sure your team knows what tool you’re using, why you’re using it, and the value that they’re going to get from it. When they see that, they’re going to think, “This BA is really interested in continuously learning and trying to come up with better ways for us to do things.” Subconsciously, every member of your team is going to start thinking in a related way and looking for their own ways to continuously improve the team at large. And that way of thinking can become an incredibly powerful force in the best of ways.

Subscribe to our Newsletter

Stay informed on the latest technology news and trends

Relevant Insights

Should You Disrupt Yourself to Accelerate Digital Transformation?

It has been interesting to watch Microsoft transition from a company that makes its money via licensing to one that...

Cybersecurity Myth Busted: Tools Are the Solution

When thinking about security, people often gravitate towards implementing various security tools, solutions, or products. If you bring up a...

Time to Reconsider MP-BGP EVPN for Your Datacenter Network?

VxLAN was defined in 2014 by RFC 7348 and has been used as a component in several SDN (software defined...