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 in Scrum 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 is 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.
Agile product management has been en vogue for quite some time. But a clear definition of the term is lacking. Different people associate different meanings with it – from simply using the product backlog to extending Scrum by employing complex new frameworks. I view agile product management as fundamentally different from traditional approaches. To better understand the differences, let’s see how agile and old-school product management compare. The following table – taken from my book Agile Product Management with Scrum – summarizes five key changes.
| Old School | New School |
| Several roles, such as product marketer, product manager, and project manager, share the responsibility for bringing the product to life. | One person—the product owner—is in charge of the product and leads the project. |
| Product managers are detached from the development teams, separated by process, department, and facility boundaries. | The product owner is a member of the Scrum team and works closely with the ScrumMaster and team on an ongoing basis. |
| Extensive market research, product planning, and business analysis are carried out up front. | Minimum up-front work is expended to create a vision that describes what the product will roughly look like and do. |
| Up-front product discovery and definition: requirements are detailed and frozen early on. | Product discovery is an ongoing process; requirements emerge. There is no definition phase and no market or product requirements specification. The product backlog evolves based on customer and user feedback. |
| Customer feedback is received late, in market testing and after product launch. | Early and frequent releases together with sprint review meetings generate valuable customer and user feedback that helps create a product customers love. |
Agile methods embrace an age-old truth: They see change as the only constant. If flux and unpredictability are dominant forces, then our ability to accurately forecast markets and predict customer behavior is limited. Instead of employing a primarily analytical approach with big upfront market research and business analysis and detailed, frozen requirements, agile product management follows an empirical approach: Gathering customer and user feedback on prototypes and early product increments facilitates inspecting the work results and adapting the product accordingly. The product evolves based on customer and user feedback. This not only saves time and money but it increases the likelihood of developing a great product.
RSS