Business Analysts and Scrum projects: A short case study

By Courtney in Agile on January 26, 2012

Driftwood on the shore. Business analysts and Scrum Teams are from two different worlds. But they can work very well together.

This short case study on business analysts and Scrum looks at how BAs can contribute to Scrum projects and gives resources on Scrum for BAs.

In a recent post I discussed the question “Are user stories the same as use cases?“. This is a question that frequently comes up in our Agile training workshops, and it’s often asked by business analysts. I’ve also been in Agile/Scrum training courses with BAs, who at a certain point in the day start worrying about where the BA role fits in a Scrum project.

The quick answer is: there is no Business Analyst role in Scrum – just like there isn’t a DBA role or a SysAdmin role or a designer role. You’re either the Scrum Master, the Product Owner, or part of the Development Team. There also isn’t a space carved out for a person to be responsible for requirements gathering and reporting. Business Analysts and Scrum Teams are from different worlds, different frameworks.

The longer answer is that there’s still a lot of work in a Scrum project for a good BA to do. When Business Analysts and Scrum Teams come together both can benefit. As Roman Pichler puts it:

what’s left to do for business analysts in Scrum? I have seen business analysts working as team members as well as taking on the product owner role successfully. In both cases, though, the individuals experienced a change in their daily work. Business analysts working as a team member often support their peers in product backlog grooming activities. As the business analysis activities are now carried out collaboratively, the business analysts often have time to take on other responsibilities, for instance, working with the testers or the technical writer. As a business analyst working on the team, you should hence expect to pick up new skills, broaden your expertise, and be open to work in new areas.

One small case-study

I recently worked on a short (6-sprint) Scrum project that had a nearly full-time BA allocated as a resource to the team. (Don’t you love that kind of phrasing? “allocated as a resource”. Savour it.)

We were creating a mobile interface for a cut-down set of the functionality available through our client’s current website. Our team was made up of a mix of our client’s staff and Boost staff: a Product Owner, the BA, two developers and a tester from our client; a Scrum Master, designer and me doing the wireframes from Boost.

Here’s what our BA did:

Working with the product owner

Working with the team

Our BA attended all the planning meetings, retrospectives and stand-ups. Her work was managed just like the rest of the team’s: written as tasks and posted on the Scrum board. What she didn’t do was write requirements or use cases, or reports. There was huge value in having her on the team. Not least because she was our go-to person for all the tucked-away documentation and hard-to-find system descriptions. It was a good example of Business Analysts and Scrum Teams combining effectively.

Further reading

The Scrum Product Owner primer

  1. What is Scrum? — Scrum roles, rules and tools, along with how Scrum was developed, how it relates to Agile, how it works best — and why
  2. Six signs of a successful Scrum Team  — what you can do as a Product Owner to deliver maximum value and make a bigger impact
  3. Making multiple Product Owners work in Scrum: A case study — what you can do when the product is too big for one Product Owner
  4. Working with stakeholders in Scrum — how to set expectations, plan how you work together and get the support you need to succeed
  5. Product discovery for Scrum Product Owners — a step-by-step guide including developing your product vision, strategy and testing prototypes
  6. User stories in Scrum — a user story template, guide to good user stories, and tips on how to write them with your team
  7. How to succeed as a Scrum Product Owner — a summary of what Product Owners need to know to maximise their impact