Business analysis is often seen as a skill primarily for product owners, right?
Well, in an ideal world, we’d also enjoy consistent sunshine in England during the summer, and there would be world peace - but as we all know, reality is far from perfect.
Most things in the Agile space are aspirational; we're all dealing with a level of imperfection.
As a ScrumMaster, part of our role involves helping product owners enhance their skills, including business analysis. Moreover, it’s important to recognize that business analysis isn’t just for product owners. Every member of a Scrum team should possess this skill to some degree. Our roles are designed to be temporary, with a focus on enabling and teaching new ways of working. If our team lacks certain skills, including business analysis, it’s our responsibility to ensure these skills are developed before we move on. In other words, we aim to leave the team stronger and more capable in business analysis, among other areas, by the time our role comes to an end.
I've had a couple of Scrum Master/Business Analyst roles (yes, we know that role is not in the Scrum guide) - and here are the things I had to shift from doing BA work in a traditional way to an Agile way:
Remembering the headline of Scrum, which is to build something usable or working in a month: this translates into "how do we slice our work end to end, vertically to learn quickly about what we are building from the customer."
Going from working with a solid plan, believing any changes are problematic, to working with a starting plan which I expect will change. Yes, this is tricky because you need to be able to do the hard thing below...
Convincing the Product Owner or business head that we should generate a plan only as long as our nose. You see that roadmap? Anything several months into the future is a guess, a bet, but to pretend we can predict things perfectly is going to cause a lot of pain for everyone & we will very likely be resistant to change (this needs its own blog & actually you should start reading the work of Maarten Dalmijn).
Going from "I write all of the stories and I know best as a person capturing requirements" to "I can get a starting point going and can build the spine & evolve that story with the team."
Emphasis on the above point but with a twist, not just a "requirement gathering human" but a person with the skill to understand how to design experiments - both in how we capture the work as a hypothesis and in how we work as a team!
Yes, two different types of experiments: (1) For Product development (2) For team development.
Did I mention I am running a Data Skills for Scrum Masters workshop in March? ;p (struggling with what to measure? Still using crappy burn downs and astrology, sorry, story points? Let me know, I'll book you into the workshop).
Anyway, hang in there, keep going and speak soon!
Jem