We have a problem in agile business analysis where many of us BAs don’t understand the role that we are expected to play on an agile team. This especially is found among those of us who are getting started in agile, but it can persist. I’ve spoken with BAs who have worked on agile teams for years and are still struggling with it.

Now this is a big problem:

1. It affects you, the work you do, the quality of the work you do, your morale, and your career
2. It affects your team and the quality of the product they develop, test, and implement
3. It affects your company, which is entirely dependent on the quality of the products and services it offers to its customers, and how valuable your customers consider them
4. And it affects your customers, who are not getting what they could be getting, if you had your role situation figured out

There is a solution.

It has three steps. Why? Because all my solutions have three steps.

Here goes.

Step 1: Figure out what your team needs

In the area of business analysis, that is.

What does your team need in order for the product to be developed, tested, and implemented? Keeping in mind, of course, that all of that happens in the course of a single iteration/sprint.

If the team needs to know all this so quickly, then you as a Business Analyst are going to play a key role in figuring all this stuff out. It’s not, by the way, necessarily the job of a BA to do all the analysis work on an agile team. That’s a common misperception. No, instead, you need to make sure that, one way or another, all the analysis work gets done.

Step 2: Figure out what your Product Owner needs

This step is a little bit trickier, because it depends on your own PO (or customer, in some flavors of agile).

POs have a wide range of backgrounds.

Some of them are former BAs. Maybe you yourself are going to the PO; if so, fantastic, you’ll be better equipped than many.

But others come from a background with little to no analysis work involved, and they are going to have considerable needs in this area. A lot of POs come out of marketing. Product Marketing Managers, for example, tend to be very analytical, but they usually won’t have the business analysis knowledge necessary to develop the product. They won’t necessarily have the skills or know-how to sequence steps in a workflow… Or to set up a process that will be critical to making your product successful.

Instead, it will be your job to make that PO successful by making sure they are equipped to do their jobs. To make them successful. In most cases, this will require sitting down with your product owner to understand their strengths, their weak areas, what kind of work they need to be coached in doing at the beginning, and what work you will just be doing yourself. Someone will have to come up with the list of Product Backlog items. Someone will have to develop user stories and acceptance criteria. And the list goes on: personas, story maps, etc.

So… figuring out what your PO needs is a big part of this solution.

Step 3: Define your own role

One of the beauties of Agile is that teams are intended to be self-organizing. There is no boss telling you what to do. There is only a list of work items, committed to by the team, and we ourselves choose what to do (and how best to do it).

After doing the first two steps, we have input from the PO and team, and we know what their needs are… now it’s time to design our own roles.

You will want to determine to what extent you are working with the team versus working with the product owner. Will you be serve as a team member, in other words, or more of an assistant PO? You will probably want to directly ask the Product Owner… Product Owner, what tasks do you need me to do to catalyze your success? Same deal with the team. What do you need from me and the product owner to be able to do the work?

Now, here is the deal. A lot of this will just naturally happen as you and your team get used to working with each other. If you can’t get your role hammered out today, don’t stress. Instead, set a goal of having a decent idea of what your role is by end of the next sprint. And refine that role as you learn more about what is needed from you.

And as you feel more and more comfort in your role, you’ll witness a pretty strong uptick in the quality of your product.

Subscribe