Scrum Master vs Business Analyst

The Scrum Master role is unique and sometimes perplexing at first. As a change agent, the Scrum Master helps their team(s) understand Scrum and achieve greater agility and effectiveness. Yet, their style and approach makes analogies to traditional roles difficult.

Interestingly, according to iiba.org, the business analyst is sometimes called “an agent of change” as well. That site says that a business analyst has “the specialized knowledge to act as a guide and lead the business through unknown or unmapped territory, to get it to its desired destination.” These words could also well describe a Scrum Master. So how are they different?  Let’s get to more specifics about Scrum in order to better understand the differences between the Scrum Master and business analyst roles.

In most traditional organizations, a business analyst bridges the gap between the business and technical parts of the organization. They often take business requirements as an input and create technical requirements as an output. This was extremely helpful in organizations where developers are expected to follow detailed instructions with little to no input in how the work should be done.

A Product Owner (PO) owns the vision or goals for a product as well as the list of future work items – the Product Backlog.  They work with stakeholders (including the Developers) to continually adapt or refine this list – and to maximize the value of the team's deliveries.

On the other hand, Scrum Masters help developers, product owners and stakeholders understand Scrum, empiricism, and how to improve their effectiveness and interactions. They are a subtle type of leader, often referred to as a servant leader. You might say that a Scrum Master is more about process and approaches than requirements or specifications. They are often considered to be a coach, facilitator, and guide.

The classic business analyst role isn't an exact match for any of the Scrum roles. This is primarily because of the accountabilities associated with each role. The developers (all those who create the product) own “how” to solve problems. They are part of a self-managing team that hears the customer needs or wishes and then determines how to best meet those needs.

Some organizations try to insert a business analyst between the product owner (who owns “what”) and the developers (who own “how”). Unfortunately, this is usually a poor fit because it takes away the team’s ownership of how to solve problems. Experienced developers in Scrum expect to be challenged with difficult problems to solve not spoon-fed technical requirements.

This leaves us with a dilemma on how to best use the skills of the business analyst. One option might be to join the developers and be a more inclusive thought leader around technical approaches. This can work well but may require the business analyst to “get their hands dirty” and have some involvement in the actual production process.

Could a business analyst become a Scrum Master? Certainly – but some learning and re-skilling is required.

Related: Learn more about the most established and trusted Scrum Master Certification in the industry. 

Another Scrum role that may be a good fit for business analysts looking to move into a Scrum role is as the product owner. The business analyst skills in working with customers and stakeholders can be put to good use here – they would help create the product backlog including (usually) writing user stories. The trick to this transition is that the (former) business analyst should try to keep their guidance at a business level and not fall back into writing technical requirements.

Finally, what happened to all that important work that a BA did in traditional projects?  In Scrum, most of it ends up with the Developers.  The Agile Manifesto principles suggest that “the best requirements, architectures and designs emerge from self-organizing teams.”   In very large organizations, could a BA help with high level interpretation of business needs and work more cooperatively with top thinkers in the Scrum teams?  Perhaps - many of these decisions are unspecified in Scrum and are left up to organizations to decide based on their unique business needs.

The reality is, the world of work is all about change and adaptation now, isn’t it? A business analyst is more than welcome in Scrum but expect that changing the way you think about leadership in the organization will be required. Scrum is a framework that embraces continuous change and continuous learning – I hope you’ll join us!  

Related Collection 

Collection: Scrum Mastery: Building Blocks for Success

========================== 

About the Author

Steve Spearman is a founder of Full Spectrum Agile and a Certified Scrum Trainer (CST®).  Steve’s certifications include Certified LeSS Practitioner, PMI-ACP, PMP, Certified Scrum Professional (CSP-SM and CSP-PO), and Path to CSP Educator.