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.
RSS
[...] Business Analysts in Scrum « All Things Product Owner – Roman … [...]
[...] the original here: Business Analysts in Scrum « All Things Product Owner – Roman … Share and [...]
Hi Roman
Nice article. The Product Owner is often a very challenging role for people to fill well and depending on that person’s skill set and experience, they will need support from various people in what we often refer to as the Product Owner team. Business analysis is a key part of this product owner team and also, as you rightly mention, within the development team.
Just as the fact that there is no project manager role in Scrum doesn’t mean that projects don’t get managed; we may not have business analyst roles but we still need to do a lot of that work. The big difference as you pointed out well is that it will probably be done differently and possibly by more people than typical.
technical writer…
technical writer are important whether it costs money take care of or not. Supporting information is vital and so your post Business Analysts in Scrum ” All Things Product Owner – Roman … makes interesting reading. I hope many see it and take notice…