Author: Robert Galen

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.

I’ve often thought that roles in waterfall processes are somewhat “safe”. There is a rhyme and a reason to waterfall projects with each discipline stepping up to the plate at a different time. They do their work, get it reviewed or achieve a milestone, and then move onto another project or focused effort. Usually the project managers and architects are up first. They envision the project from a planning and a structure perspective, and then leave their artifacts behind for others to execute.

Next up are the BA’s. It’s usually an intense time early on in the projects-gathering stakeholders and eliciting requirements. There’s a whole lot of listening, writing, reviewing, editing and reviewing some more. It’s a lot of hard work to get everything right, but then there’s the final review and customer sign-off-and your work is essentially done.

The development team is up next to implement the functionality. Usually they are incredibly optimistic in the beginning and over commit to work and delivery dates. But that’s what the business wants to see-unbounded aggressiveness. However, reality soon shines it’s light on the team, as does 90% done syndrome, and things take quite a bit longer than expected. The customers become impatient and begin to loose their confidence.

But then something magical happens the developers reach a point of closure and then…pass the code over to QA for testing. Whoo Hoo!

Need I say more? QA will normally test in a defect-rich environment and work oppressive overtime. Every bug that is found is somehow QA’s “fault” for making the project longer. But there comes a day, when the business accepts the resulting code quality proposition, and proudly presents the applications to the customer for UAT.

And what a day it is. You’ve all been there. The customer fires up the application in anticipation. But quickly they’re mumbling to themselves and scratching their chins in consternation. Then you hear that dreaded cry-this isn’t what I expected!

What if something goes wrong?

As a traditional BA you have the stage for a short time. Your job is “safe” in that you rarely stick around for the end of a project. Your efforts are typically front-loaded and intense. There’s also positive energy in the beginning-as all projects start out as naïve, “can do” efforts. Your work is often finished quickly and you usually change your focus towards a new effort. You convince yourself that this is the essence of things and quite natural in the workflow.

A flip-side example of this is the testers. They’re often quite idle in the beginning stages of projects. Yes, they’re “preparing” for testing-but the focus and intensity is quite low. They’re depending on the early phases to do a complete job so that they can immerse in testing at the end.

We all know that this phased approach to delivery doesn’t work that well, but it does create “safe zones” for each of the teams’ functional groups. It means that traditional BA’s can do their job and then “hide” from the reality of success. If the project is successful in the eyes of the customer, then it was the requirements that drove the success. If not, then there was someone else to blame. Either the customer was wrong-in that they didn’t know what they truly wanted or needed. Or those pesky developers simply didn’t fully understand the requirements. Or the testers simply didn’t work hard enough to get things done on time. You get the point-functions and people can “hide” in this model and pass the buck. Not always true, but sad when it happens.

Is it “Safe” being an Agile BA?

The agile BA has no intense periods of activity, nor safe idle periods. They have to always be “on” within the team. They’re incrementally defining requirements, helping them get implemented, perhaps doing a little testing, and continuously collaborating with the customer to elicit valuable feedback.

There’s no “quiet time” while they go off and write a long series of use cases for an application. No, long periods totally focused on requirement writing. And no, they have to share their results with their teams continuously. It’s this change that is quite difficult for many traditional BA’s who are making the transition to agile teams. Some say it might even be an exciting transition.

I’ve often spoken of agile projects as having a nature of “controlled chaos” in that you don’t know exactly where you are going day-to-day. You’re on the edge much of the time, figuring out your path as you go. Never knowing what’s directly around the next corner. It’s this capacity to go with the flow, as you sort through technical hurdles and customer needs and expectations, that is inherent to agile.

And what if you’re serving in the role of Product Owner?

Another common transition for agile BA’s is adopting the role of product owner within a team. The decision is usually driven by the notion that product owners write most of the user stories in their product backlogs, so who better than a BA to assumes that role. However, the PO role is even more chaotic and driven than the agile BA. And yet, it’s another role that increases your exposure and ability to drive your teams towards even more success.

In this role you adopt more visible traits, making your priority-based decisions transparent across the organization. You’ll be defining the “now & later” states for the project while defining a stream of features that will incrementally define the product. It’s a just-in-time view that loads high-value features first and constantly engages the customer in progress.

In fact, you’re role will also focus on acceptance criteria, so work will be reviewed and accepted within each iteration. This role is a powerful extension for most BA’s in that it extends into product management, project management, and leadership activities. Nonetheless, it’s a wonderful extension for the agile BA.

Wrapping Up

If you’re a traditional BA who likes it slow and steady. Who likes to work for periods, undeterred and uninterrupted on requirements. If you would prefer to become detached from your project after your job is essentially done. If you like throwing requirements over the wall for implementation, then becoming an agile BA might not be for you. It may be too much for you…or too “chaotic”. So stay in your safety zone and happily fulfill your traditional project responsibilities. It’s ok!

However, if you like being in the thick of things in setting the functional direction for a project. If you like collaborating with customers and stakeholders during the entire software lifecycle.  If you’ve come to understand that software projects are tricky beasts full of uncertainty that resists planning outcomes. If you enjoy being the “glue” that continuously connects the customer to the team. Then perhaps you have what it takes to become an Agile BA. Trust me though, wear a helmet and be ready for a bumpy ride. Also be ready for success as well…and enjoy the ride!

Don’t forget to leave your comments below.