Secret Life of an Agile BA

At the AgileDC conference yesterday, I had the opportunity to participate in a session called “Agile Paradoxes: Extensions or Contradictions?” by Awais Sheikh.

Awais’ thought-provoking presentation and the ensuing discussion made me think about a concept that evokes the same kind of back-and-forth dialogue:

(Agile) Business Analyst

Is the very concept of a BA a contradiction to Agile? Or is it an acknowledgement of the complexities of real-world, large-scale Agile projects?

In an ideal cross-functional, empowered team with wholly dedicated resources including a product owner, then the responsibilities of the BA role can be shared amongst the other team members and the goal is still being met.

But several of my projects haven’t quite resembled that best-case scenario.

I been a ScrumMaster for teams where business analysts (responsible for writing user stories and maintaining the backlog) were embedded in every team, along with a tester, a DBA and several developers.

I’ve experienced other teams where business analysts, usually based in a different department other than IT where the rest of the team was based, were sent through a few days training to become product owners and were responsible for creating and managing the backlog. As product owners, they spent a few hours daily in the team rooms, and the remaining at their desk in their respective business unit.

And then there are teams where the product owners, usually the clients, are responsible for prioritization and acceptance but do not actively maintain the backlog and develop user stories. They are often not co-located with the rest of the agile team but work with the teams while also doing their regular job. Instead business analysts act as proxy product owners and are responsible for gathering the “requirements” from the clients. They are sometimes part of the development teams, and in others, they are part of the “extended team” supporting one or more team.

I think any and all of these scenarios can work, but the devil is in the details as the saying goes.

The key element is that the level of delegation should match the level of responsibility. In other words, whoever is serving in the role of product owner (proxy or now) should be empowered to make the decisions on daily basis so that the scrum team can move forward confidently. The product owner can escalate as needed or to set priorities at the feature level.

Fundamentally, remember that the goal — a groomed, prioritized backlog where business value is ingrained — is what matters, not the role!

So now matter what your role is, if you own the backlog to any degree, then know that your work is the difference maker in the highest risk of an Agile project.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s