The Scrum Business Analyst

I have heard more than once “There is no BA in Scrum.” Imagine how your BA’s feel when a transformation starts!  At best, they are uncertain what their role ought to be. At worst, it is made clear by everyone else in the process that the BA is no longer needed or wanted.

The irony, for an agile coach viewing this as an outsider, is that numerous individuals throughout the value stream who are also struggling to cope with the shifting sands of transformation, frequently report that mistakes, lack of prioritization, failure to clear dependencies, and miscommunication are due to “being too busy.”

Obviously, just from this “too busy” problem, there are two important things the BA ought to do as an active member of a Scrum Team in a scaled environment:

1. Act in a WIP-clearing capacity to the extent their t-shaped skills allow.  To whatever extent they do not have T-shaped skills, the moment they are not clear on how to utilize their time is the perfect opportunity to develop these skills.
2.  Capture the very broad “reminders of a conversation” about a story that, in a large enterprise, occur across a larger number of individuals, over a longer time period, and in more geographically distributed locations than “core scrum” implies.

Roles and Accountability

Now we can draw the line between the Product Owner and the Business Analyst.

The Product Owner is accountable for decomposing an Epic or expressing a single enhancement as User Stories.  The Product Owner creates a Story card in JIRA for this initial Story list that includes a JIRA Summary and the User Story in classic format:

As a {user persona} I want {action} so that {expected value to the user}.

This is an expression of “Commanders Intent” and represents why the story is being developed and who cares whether or not it is developed.  Thus, the User Story is an expression of product strategy, and represents trade-off choices and prioritization.  The decision to expend finite on and expiring resources – time, energy, money, and talent – on one product change versus another is the most critical accountability of the Product Owner.

Although the what and how is negotiable, the intention of the Product Owner serves as a litmus test for all subsequent decisions.  The what and how are the realm of operational effectiveness rather than strategy.  It includes the framework of economic decision making and the processes, practices, and tools that streamline communication and align strategic direction of a distributed control system.

The Business Analyst uses the Description to succinctly express the what and how that has already been determined so that no context is lost in subsequent decisions.  The what and how remain negotiable to the extent these better serve the “Commanders Intent” of the User Story.

In an analog Scrum board, there is typically an agreement on “front of the card” and “back of the card” content that serves as the “reminder of a conversation” for the team.  In a scaled environment relying on a digital board like JIRA, the Summary and Description fields serve a similar purpose.  As the number of individuals contributing to the value stream increase, the need to detail the conversations that have already occurred increases as well.

In the process of detailing each Story Description, it will often be apparent – due to test data or testing scenario coverage – that a Story ought to be split into two or more stories.  The Business Analyst completes this activity and is accountable for communicating the split to the Product Owner.

 Stories may also be further split during Backlog Refinement or Sprint Planning based on additional insights from the team. Attendees should collaboratively decide who will capture this decomposition within the tool, but the Product Owner is accountable for prioritization decisions (if the split impacts this).  

Purpose of the Story Description

So, to meaningfully define the role of the Business Analyst, we need an understanding of what value is created if one individual “owns” capturing the elements of a Story Description as the number of these predetermined elements continue to grow. To the extent at scale that the team is unable to economically interact with every other value add activity in the value stream, the purpose of the Description is a succinct expression all value-add activities and decisions that have influenced the User Story prior to development. While we want to express these in the fewest words possible, and work toward distributed control of decisions, we do not want previous insights “hidden” unnecessarily from the Scrum Team.

Several important activities have likely occurred prior to our Sprint:

1. Business decisions fundamental to the economics of our interaction with the customer.
2. Funding based on an overarching strategic initiative.
3. Customer research and analysis of product metrics.
4. User Persona definition and Empathy Mapping.
5. UX Proofs of Concept and/or A/B Testing.
6. Stakeholder meetings.
7. Success Metrics defined.
8. Technical dependencies fulfilled (such as a new or updated web service API).
9. User Story decomposition.
10. Other Stories already developed related to the feature.

Thus, many details needed “downstream” should be easily expressed in advance of the Sprint:

1. Why are we building this story?
2. Who is the User?
3. How is this User unique in our Product (i.e. relate persona to an account type)?
4. What Test Data will need to be requested to test the story?
5. What steps does the User follow to obtain the value of the story?
6. What will the User see when they finish the story?