The Agile Business Analyst: Seeing the Forest, The Trees, and the Grass…Mostly the Grass!

I’ve been coaching several agile teams in a singular organization of late. The organization is quite mature from an agile perspective. However, I’ve been somewhat troubled by some of their recent “behaviors” driven from the Product Owner and business-side ranks within their teams.

In essence, I want to share & explore those behaviors here, sort of to vet my thoughts regarding how healthy they are and to explore root causes.  Here are my observations-

First , there is a tendency to favor UI-centric work over Backend work within their application domain.  The conversation goes like this-

There needs to be “customer facing” work for us to deliver with every release. Our internal stakeholders need to be able to “see” our efforts in order to understand what we’re doing and determine that it has value. Being able to visualize the work, literally, makes that process all the easier.

Not just for internal stakeholders, but also as we explain to our real customers what we’ve just delivered on a release-by-release basis.  Clearly features you can see trump those that are less demonstrable, for example, performance improvements of our backend transaction processing or internal backend bug repairs.

The second challenge surfaces around the size and relationship of the Product Backlog items. There’s another tendency to group feature related product elements together. For example, if a team is responsible for the advertisement editing, marketing & promotion social media, and promotion tracking sub-systems in their marketing support product, then they would only focus on one of those sub-system areas at a time. This conversation goes like this-

We simply must continue to work on the advertisement editing sub-system until we get all the requisite features in place for our customers and the marketplace. Others point out–but what about the tracking component? We haven’t updated it within the last two years as we play catch-up on editing. It’s getting more and more brittle with technical debt and we simply are ignoring it? And the answer is, we need to focus one ‘one’ priority!

Subsequently, there is little to no multi-tasking across the sub-systems within the backlogs. Essentially the behavior would be that of a focused Feature Team. The argument here is, again, that having closely related work delivered together increases the “what’s in it for me” aspect with the customer and stakeholders, which makes a larger impact upon release. I’ll wrap both of these challenges up into the following problem statement:

Backlog items need to relate at a feature level AND amplify UI-facing functionality so that team work can be more easily demonstrated, explained & justified, and valued by the customer.

So, What’s My Issue?

I know what you’re thinking. That I’m making a big deal out of nothing and that this sounds like a very healthy way to prioritize your Backlog. You know what, I’m struggling with that too. But here are the concerns running around my head at the moment-

In the first part, I’m thinking that backlogs shouldn’t be driven simply by visible or singular feature areas. That being able to relate the items from a demonstrability perspective, while an important consideration, is not THE most important consideration. That priority should be driven by…well priority. Whether the story is visible or not shouldn’t be a primary consideration. Whether it’s easily explained or justified or not should not be a consideration either.

What should drive priority is the business and technical need to get that story into production relative to all of the other stories. For example, if I have a sprints’ worth of high impact and important work that is all backend focused, then I should simply get on with implementing it and not worry about how hard it will be to explain or justify the work.

To the second point, it’s roughly the same concern. Singular feature areas shouldn’t be driving the backlog. There is nothing to say that the team in my example above can’t work on aspects of all three sub-systems at the same time IF the business priority drives them in that way. Sure, you’ll get less impact per sub-system. So what?

Again, if the priority clearly drives us in a direction, let’s not let fear of effort dilution challenging explanations cause us to ignore or orphan sub-systems.

Is there a Granularity Problem?

What I’m thinking is that in both of these cases there’s a granularity problem at the organization level.  Organizations need to be able to see value coming from their Product Backlogs. Whether that value is at a forest level, tree level, grass level or even the dirt level. They need to be able to get excited about all four equally well and react accordingly when their teams’ deliver at each level.

In my example, these teams were struggling with delivering grass level results. Worrying that they wouldn’t be able to explain the value or that the customer wouldn’t “get it”, and they’ve lost sight of prioritized flow as a result.

Let’s say you’re working with a customer for a medical system and they’re clearly uninterested in the defect stream associated with their latest CT Scanner in development. Instead of bug repairs, they want to see a faster progression of features.

Well, everyone wants to see their products develop quickly. But in this case, these customers and their teams are wrongly focused.

You see, in the medical product domain, bugs matter-at least to the regulators and ultimately to the customers. So as a Product Owner you have a responsibility to prioritize those repairs at an appropriate level and guide them through towards completion and sprint review. In the sprint review, you have the responsibility to explain the value those defect repairs provided even if you don’t get a standing ovation for doing so.

That work is equally or more important with feature work and you have to work hard at explaining that value to your business stakeholders. Not only work at explaining it, but demanding an appropriate level of understanding and response from them.

You have the ultimate responsibility to provide a Well Balanced Backlog that is not influenced by what’s easy to explain or not. But instead, it’s influenced by driving high priority business value elements that are well-connected and balanced across all aspects of your application.  I’d consider this your prime directive as a product owner and it should serve as the central theme of your external communications.

Two Quick Techniques

I don’t want to end this post simply complaining or pointing out an issue without suggesting some way of improving things. In this case, I think there are two tools or techniques that are useful in helping teams to balance their backlogs-to prevent the skew we’ve been exploring in this post.

The first one is simply an extension of this posts’ theme – Forest, Trees, and Grass. Instead of looking at the world as a series of sprints that need to be executed, the Product Owner needs to illustrate to their business constituents and customers how things are being evolved, balanced and invested across both the fine-grained and course grained elements of their application.

Of greater importance is explaining how things connect in an overall strategy of evolution on a release-by-release level; perhaps by using the roadmap framework below. For example, if a release is focused on grass level elements, then clearly explain the WHY behind that decision. Please don’t avoid it because the communication may be difficult or hard. Or avoid it because it’s much harder to “split” the backlog in that way. Instead, have a story to tell and then connect it towards future releases.

   Release Roadmap

	Forest Elements	Tree Elements	Grass Elements	Dirt Elements
Release 1
Release 2
Release 3
Release n

And don’t get fooled into thinking that you need an excruciatingly detailed why. You don’t. You need enough details to explain your thinking or the under-the-covers drivers, but in the end this is your job. And your stakeholders need to trust your decision-making process and judgment.

The second technique is to establish clear goals for each of your elements within your organization. For example, bug fixing and minor feature evolution points are clearly a “Grass Element”. Establish release-over-release percentage targets for that sort of work within each of your teams. Track that work and report out on it at a team level and at the organizational level. Make it transparent. In retrospectives, consider whether you need to increase or decrease these levels and also how healthy your overall backlog balance is.

Wrapping Up

My hope is that teams stop crafting backlog work based on reception perception, but instead focus on balanced value and clear priority. As Agile BA’s, you can also partner with your Product Owners in avoiding these patterns.

Let me know if you’ve seen these patterns yourself and have any comments whether they’re a problem or not. As I said earlier, I’m still mulling all of this over and am open to it not being a problem 😉

Don’t forget to leave your comments below.