Business Analysts and Scrum projects: A short case study
By courtney in Agile on January 26, 2012
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 Writing Great Agile User Stories workshop, 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 Scrum Team. There also isn’t a space carved out for a person to be responsible for requirements gathering and reporting.
The longer answer is that there’s still a lot of work in a Scrum project for a good BA to do. 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
- 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: she was our go-to person for all the tucked-away documentation and hard-to-find system descriptions.
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
Colart Miles has begun a promised series on the Clarus blog