Business Analysts and Scrum projects: A short case study

By Nathan Donaldson

Tags: Agile

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. At a certain point in the day, they often 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. There was 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

• Research for writing user stories (usually by confirming how the current system works, and where there was and wasn’t flexibility to make changes)
• Meeting with other parts of the business to explain what we were doing and what we needed, and to find out what they were doing and how that might affect what we were making.

Working with the team

• Ferreting out system documentation
• Getting screenshots of the system that I (working outside their network) couldn’t access, and reviewing wireframes with me
• Helping write and QA’ing test cases
• Getting wording signed off by other parts of the business (always harder than you think it’s going to be)
• Getting approval from other parts of the business for use of a third-party plug-in.

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

• Agile transition – workshopping the roles — Helping people in traditional development roles understand Scrum
• The Experts’ Take on Business Analysis and Agile — A four-part article based on a roundtable discussion amongst a group of Agile experts (including Alistair Cockburn, Roman Pichler and Ken Schwaber) on business analysis and Agile.
• What is an Agile Business Analyst? — A BA’s perspective on Business Analysts and Scrum from Steve Blais

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