Scrum in practice: the role of the Business Analyst

While using Agile frameworks to develop digital products and services usually means that large organisations are better able to meet the rapidly changing needs of the business and its customers, it can also leave those in the traditional role of Business Analyst feeling a bit perplexed. Should they be learning a ton of new skills to become Product Owners? Or receding quietly into the background as new roles supersede them? How can the business analyst use their unique position to help Scrum teams deliver as much value for the business as possible?

Who is the Business Analyst?

The traditional role of the business analyst is to capture and document requirements and then to make sure that those requirements are delivered by the IT team. That sounds like a simple enough role but it’s actually pretty complex: it requires an in-depth understanding of the business and its customers, the ability to analyse and order the different viewpoints of stakeholders, and it means facilitating the negotiation between the stakeholders and the development team about what to build.

Isn’t that what a Product Owner does?

Not quite. As the role name implies, Product Owners are much more focused on an individual product, whereas a BA might be working across a whole raft of products. While the business analyst will help formulate the product vision, it’s the Product Owner that takes ownership for this vision and is accountable to the business for getting the product out of the door. The Product Owner makes the ultimate decisions about what to build and what not to build to ensure the creation of maximum value.

The two roles have obvious overlaps but they’re quite distinct in terms of responsibilities.

Should the BA be part of the Scrum team?

Often business analysts feel that their skills are undervalued by Agile development teams who are focused on building a single product. They’re expected to come up with requirements instantly and, when they can’t, are often criticised for being pointless. After all, couldn’t the Scrum team just ask the business directly?

Frequently the answer to that one is no. To whom would the developers direct their enquiry? How well would they facilitate the resultant conversations? How would they be able to combine the differing answers of various stakeholders into a set of requirements that creates value for the business? These are the unique skills of the business analyst.

For these reasons I think the Business Analyst has an important role to play in the Scrum team. In a sense, the BA keeps the Product Owner honest – ensuring that the needs of the business and the customer are served by the PO’s decision making. Their input into planning and backlog grooming exercises is vital in this respect.

Product Owner and Business Analyst working together

To get the most out of the Business Analyst and Product Owner relationship their roles and responsibilities should be kept distinct and well-defined. Scrum helps here as it has a clearly defined role for the PO as the owner of the product backlog.

The Business Analyst can assist the Product Owner by using their in-depth knowledge of the business in a number of ways:

• Gathering requirements by managing relationships with stakeholders and facilitating those conversations;
• Providing guidance on what to build when to release as much value as possible as early as possible;
• Helping the Scrum team to plan and improve their ways of working through retrospectives;
• Ensuring the work done by the team aligns with the wider business strategy.

The proxy Product Owner trap

Unfortunately, the Product Owner in many organisations is rarely dedicated solely to this single role. They often have marketing or product/project management duties vying for their time and so the temptation can be for them to divest some of their responsibilities to the Business Analyst.

This is a mistake. While the BA might have the skills and knowledge to make the decisions normally made by the Product Owner, if they’re not carrying the title then they won’t feel empowered to make those decisions. The original Product Owner will still end up making the ultimate calls but away from the Scrum team. What results is a longer decision making process fraught with miscommunication and misunderstandings. ScrumMasters should be on the lookout for this pitfall.

In conclusion, due to their unique skills and knowledge, the Business Analyst can be a hugely valuable addition to the Scrum team. But it’s important that, despite their similar remits, the role of Business Analyst is kept distinct from that of the Product Owner.