Demystifying a Business Analyst in Scrum
Have you ever wondered where Business Analysts fit into the Scrum framework? You're not alone. It's a common question, but the good news is that the answer is simpler than you might think. Let's break it down in a way that clears the fog and highlights the easily graspable nature of Scrum accountabilities, especially with a Business Analyst skillset.
Heads Up on Copycats
It's important to recognise that the Scrum framework, originally designed by Ken Schwaber and Jeff Sutherland, has been used and altered in other methodologies, such as SAFe, PMI, and ScrumStudy. My intention is not to criticise them but to make you aware that their understanding of a Product Owner is different from Ken and Jeff’s. You will likely encounter many conflicting views about Product Owners. My focus here is on the original, unaltered Scrum framework, as defined by Ken and Jeff.
Scrum Accountabilities
Scrum defines three accountabilities: the Product Owner, the Scrum Master, and the Developers. These are not roles or job titles; they are more about who holds specific accountabilities.
Here's a quick clarification – 'Developers' in Scrum isn’t limited to programmers; it refers to anyone who contributes to developing the product or turning ideas into valuable solutions. The “Developers” in a team should be cross-functional, meaning all the skills needed to deliver the product should exist within the team. After all, how can one deliver a product if no one in the team possesses the necessary skill?
The Product Owner
The Product Owner plays a critical role in the framework. This accountability extends beyond typical backlog management and requirement definition. It's more about product management, encompassing a systems-thinking view of the entire product, including strategy, market, sales, research and development, customer management and support, logistics, and product finances.
Typically, this is a senior organisational role, given the breadth of responsibility and decision-making involved. The organization should view this person as “the owner of the product,”. Scrum insists that its primary accountability is to maximize value. This “value” means the Product Manager should have a strong sense of the costs, profit and loss, ROI, and overall value of the product and be able to make decisions around them. Their work encompasses the entire product lifecycle, not just development.
The skills and scope of a Product Manager and a BA are very different, but there is also a dependency between the two, as discussed below.
Business Analysts: The Easy Fit in Scrum
Now, onto our stars: the Business Analysts (BAs). Whether classic Business Analysts or Business System Analysts, they play a crucial role in bridging the business and technical worlds, understanding the needs, and turning them into solutions.
In Scrum, we want the Product Owner to focus more on the product strategy and business value and not get bogged down in the solution. The solution, development, deployment, and quality are the accountability of the “developers”. This effectively places BAs within the development accountability as they apply essential skills to devise solutions.
This setup means that BAs are integral to the team, bringing their unique professional skills. The beauty of Scrum is in its collaborative nature – it doesn’t isolate BAs with solutions responsibilities but rather involves them in a team that values diverse perspectives. BAs should leverage everyone in the team to come up with the solution but use their skills to check the business outcomes and needs are met.
Product Owner Relationship with Business Analyst
A good working relationship should be established between a product manager (as product owner) and a BA (as ‘developer’), as both bring different but critical insights. It is a symbiotic relationship.
The Product Owner brings the company needs, strategy, and expected outcomes. They highlight the urgency, needs, and pains of the business, working with many parties both internally and externally. They have a vested interest in the solution as it makes or breaks their product.
The Business Analyst works closely with other “developer” skills and understands the nuts and bolts more deeply. Their skill lies in bridging the business need with the solution need and helping the Product Owner understand that. They, along with their team, may come up with solutions that change the direction of the strategy; this is where the product owner learns. BAs great in translating “geek speak” into “business speak” and vice versa. They are skilled at finding gaps and weaknesses in both strategy and solution.
The amount of overlap depends on the work experiences of the individuals, and this may vary.
Impact on innovation
When you start separating the strategy (product owner) from the solution (developers including BA), a powerful dynamic is introduced: innovation. Should a product owner start defining the solution, it anchors the idea and turns the team into an order-taking team. Their innovation and creativity are stifled as all they need to do is execute on it.
Learn from Steve Jobs, a leader with strong intent and vision. But he hired exceptionally talented people to turn those visionary ideas into solutions. His famous quote applies:
“It doesn't make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do” – Steve Jobs
This is where BAs play a vital part, working in their team to ensure everyone understands the business problem, the laws (if applicable), and many other facts. But then, with their team, they brainstorm creative and innovative solutions. BAs should be mindful not to anchor solutions but to leverage the entire team; but as a team, their ideas for solutions should be considered.
Product Owners and the Art of Delegation
In Scrum, Product Owners are allowed to delegate to manage their broad scope of responsibilities efficiently. This delegation doesn’t diminish their role but allows them to concentrate on maximising the product's overall value. The bigger the product, the move away from maximising mere cents but maximising big decisions. The rest are delegated to the developers.
A common anti-pattern in big products is to delegate a sub-domain to an “Area Product Owner” or “Technical Product Owner”. They often put a BA in this position. The BA becomes disempowered and cannot make core value decisions. This is not the way (kind of)!
Technically, it's great that the solutioning is given to the developers, which is the right behaviour we want to see. However, it creates an artificial hierarchy in the team between the BA/PO and other developers. The harsh reality is this BA/PO is limited to solution decisions only, and very rarely do they have authority on product strategy, finances, and product value. Should this TPO then do the work, in effect, it anchors solutions to that BA, which we don’t want as it should be a team decision. This then makes the TPO a vanity position or a dysfunctional one. They should delegate to the entire team, not just a BA. The BA should not be the “TPO”, but a valuable developer. Just a self-managing team of professionals, all bringing in different and valuable skills. This is the way!
A Final Word: Simplifying the Complex
Put your product management in a position to take the Product Owner accountability. Embed the Business Analysts in Scrum Teams as a ‘developer’ accountability, thus bringing their analytical prowess to enhance product development. There's nothing wrong with the PO delegating things to the developers, but remember, they remain accountable even if they delegate.
Finally, support your Scrum Master by having some heart-to-heart retrospection on reducing pressure points and turning the average into great. This is easy, and doing this will have a significant positive impact that is essential to success. It will require transparency, inspection, and adaptation with a healthy dose of courage, commitment, focus, openness, and respect.
Now go and focus on delivering your awesome product!