Business Analysts in Scrum
Business Analysts in Scrum
Join the DZone community and get the full member experience.Join For Free
[Latest Guide] Ship faster because you know more, not because you are rushing. Get actionable insights from 7 million commits and 85,000+ software engineers, to increase your team's velocity. Brought to you in partnership with GitPrime.
A new article on business analysis and agile based on interviews with a group of people including Ken Schwaber, Alistair Cockburn, Ellen Gottesdiener, and myself reminded me to share my thoughts on the role of business analysts in Scrum. But before we talk about the role, let’s first explore how business analysis activities are carried out in Scrum.
As I explained in my post “Demystifying the Product Owner Role,” the product owner takes care of the stratgeic product management aspects, such as creating the product vision and the product roadmap, but also the tactical ones, particularly grooming the product backlog. Since grooming includes decomposing and refining requirements — for instance, by capturing items as detailed user stories with acceptance criteria — it is fair to say that the product owner performs some business analysis activities. But product definition and business analysis are not restricted to one individual in Scrum: Grooming the product backlog is teamwork. Product owner, ScrumMaster and team collaborate on an ongoing basis to ensure that the product backlog contains the right items and that it is ready for the next sprint planning meeting. They jointly discover, decompose, and refine requirements. Stakeholders such as customers, users, management, service, sales and marketing are involved as appropriate, for instance, in the sprint review meeting when the product increment is demoed and discussed and when new requirements may be identified or existing ones removed from the product backlog.
Now 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.
Business analysts working as product owners also face change. Depending on the type of product and project, they may have to acquire new skills, such as envisioning new products, managing the product roadmap, and planning the release. However, if you work as a business analyst turned product owner on a large project where you collaborate with a feature team, you may find that the change is not quite that deep. Do make sure though that you are respected and appropriately empowered. And watch out that as a business analyst, you do not morph into a proxy product owner. Be either a team member or the product owner, but not a halfway house.
So Scrum is not bad news at all for business analysts, and the individuals still have a job to do. But just like other specialized roles, working on the team means engaging in a broad range of activities and becoming what’s sometimes called a generalist-specialist.
You can find out more about business analysis activities in my book Agile Product Management with Scrum and by attending one of my Certified Scrum Product Owner (CSPO) classes. The class allows you to practice some of the agile business analysis techniques, such as progressively decomposing and refining requirements, and to discuss your specific business analysis challenges.
Published at DZone with permission of Roman Pichler , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.