• ALL
  • CATEGORIES

Scrum in practice: the role of the Business Analyst

scrum-team-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.

Leave a reply

You can use these tags:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

  1. Dan says:

    Thanks for the post and I’ve been researching this topic for my organization. Should this section above (“Product Owner and Business Analyst working together”) be interpreted as the Business Analyst being a part of the Scrum “dev team” role?

    Thank you,
    Dan

  2. Vaibhav says:

    Agree completely.
    Besides, even if a Product Owner is dedicated to the product, he normally wont write user stories and acceptance criteria, so it is where BA comes into picture. BA will go to the lowest level of requirement such as getting details of field type and size, creating process flow diagram, doing sanity test.

    • Yasith Abeynayaka says:

      “getting details of field type and size” – i respectfully disagree to this point, isn’t agile is about

      Working software over comprehensive documentation
      Individuals and interactions over processes and tools

      I think it reflects one of the weaker settle-down by BAs in agile teams. I think BA role collaborates with PO (and other roles) to ensure the Product remains relevant to needs in a wider scope, not detail out what PO already decided

  3. Rambo says:

    Interesting read.
    I agree that the BA should be in a scrum squad and that they should be valued as a facilitators and a translators between the PO and development.

    I do think that there tends to be a retrofit of user stories by BA’s attempting to ‘be agile’ and that this often loses the actual ‘users story’.

    Its great to get the product owner to express themselves in terms of stories and to then refine these collaboratively.

  4. Cosmic Ray says:

    Hopefully the whole sorry Agile fad will go away in a couple of years once people realise that short-cuts and ‘minimum viable products’ only lead to poor quality deliverables and unhappy stakeholders. Then we can all get back to doing things properly and won’t have to annoy the poor customer any more by implementing a pointless release every time we’ve written a line of code.

    As for the BA, his/her role is to capture good quality requirements, model whatever needs to be modelled, and present this in the appropriate format for the appropriate IT or business audience to allow them to perform thier own roles. This always needs to happen no matter what daft methodology is attempted or whatever role name he/she is given.

    The term ‘Waterfall’ is just ‘fake-news’. People have been successfully delivering systems using the correct end-to-end lifecycle stages for over 50 years. Leave things like Agile to college kids and those that deliver websites for $10.

Sign up for the Manifesto newsletter and exclusive event invites