Can you find the missing piece?
When it comes to agile teams that run under the Scrum flavor of agile, the team is typically composed of just three roles:
- A Development Team
- A Product Owner
- A Scrum Master
"Development team" is pretty opaque. When we add a little more detail, most agile teams still look like this:
- Developers
- QA analysts
- A Product Owner
- A Scrum Master
What role is missing from this example? It lacks a critical role.
If you guessed that these teams lack an agile business analyst, you guessed correctly!
Let's talk about an often-overlooked, misunderstood role that is hugely important to agile teams.
What Exactly Does an Agile BA Do?
Does your agile team have trouble understanding the requirements in stories they pick up? Are stories taking too long to get into a ready-state for the team to pick up? Do hidden requirements or gotchas tend to blindside the team mid-sprint?
If you answered yes to any of these questions, chances are your team needs a business analyst.
BAs are the team's engine when it comes to backlog management. A BA performs the following for an agile team:
- Meets with the Product Owner to understand the team's work.
- Breaks epics down into stories and defines acceptance criteria in each story.
- Provides the team with the context they need, i.e., what part of The Big Picture they're working on.
- Devotes time to the detailed analysis, conversations, and documentation that all user stories call for.
- Establishes the backlog as a source of truth from which the team can deliver.
Put another way, user stories don't write themselves! There are details, decisions, and dependencies, that are discussed during a team standup or in a hallway conversation - and it's the BA's job as the story writer to make sure these myriad pieces of information make it into the right user story.
The BA essentially feeds work to the team. They are the one person on the team who's dedicated to looking ahead at upcoming work and grooming requirements so that they're well-understood, documented, and ready to go. This is no small task.
Business Analyst vs. Product Owner
We described a BA's general capabilities above, but a business analyst may also:
- Initiate project discovery helping to define a project's scope, establish high level workflows, and produce an initial list of features to build.
- Facilitate workshops to flesh out user journeys, personas, and process flows.
- Act as a proxy PO for the team, where the BA answers questions or facilitates decisions on behalf of an absent PO.
"But wait!" you might say. This all sounds a lot like the work you'd expect the Product Owner assigned to a team to do. Let's talk briefly about how a Product Owner fits into an agile team:
Depending on your company and how the Product Management group at your company operates, a PO may very well do everything we've previously discussed.. In which case, you don't need a BA.
More commonly however, POs perform a whole other set of tasks, which can entail anything from market research, competitive analysis, product strategy, to simply going to meetings, collaborating, and rallying decisions to create and execute a product roadmap.
Having POs own a backlog and break it down into detailed, consumable chunks for a team is not inconsequential - and it sometimes turns into one hat too many for one person to wear.
That's why you may need a business analyst on agile teams - to dedicate one team member to partnering with a PO to manage requirements and get the team sprinting. In companies that are lean enough to combine all these functions into a single role, you have a hybrid PO/BA. But in other scenarios where the work demands two separate spheres of focus, you'll find separate BA and PO roles.
You Need A "Story Writer"
As I mentioned above, it's the BA's job as the story writer on an agile team to assemble requirements into coherent user stories. This key role provides several benefits to the team:
- The BA frees up a PO's bandwidth, so this person can focus on all the demands built into putting together product strategy and a product roadmap.
- For the team itself, the BA gathers requirements on behalf of the team, leaving developers and QAs free to execute software delivery.
- The BA provides continuous analysis and user story definition required to keep an agile team running smoothly. One discovery that all new agile teams eventually come to realize is that the story grooming process isn't just "One and Done" in getting to Day 1 of Sprint 1. Story grooming is a continuous process built into agile sprints.
When teams lack a BA role, they're missing that essential story writer. Imagine a balloon in a bucket of water: When you don't have a BA role, by necessity the story writer function gets pushed around. It always pops up somewhere else on the team.
With several teams I've coached where there was no BA on the team, developers and QAs end up spending valuable time grooming stories. For teams that are new to agile delivery, this is an especially painful gap - developers and QA analysts who are new to agile are also asked to manage backlogs, which is an art in itself. Asking these technical specialists to step outside their expertise and take on managing requirements too often results in pain, resistance, and slowdown for the team - exactly the opposite effect teams want to experience when they are just starting out with agile!
Somebody's got to take care of that balloon that's going to pop up. Shouldn't it be a BA with the right skills and the right capabilities?
