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…
[...] owner mistakes Desirable characteristics of a product owner Product owner = product manager? Business analysts in Scrum This entry is filed under roles with the following tags: budget, grooming, product backlog, [...]
Hello,
After reading your post, as well as a few articles on the web (see references below), I came to the conlcusion that:
1. During a Sprint, BAs work on analyzing requirements for the Sprint(s) to follow. They do however actively support the Scrum team in case of (business related) questions/misunderstandings, etc. in the current Sprint.
2. Thus, BAs are not part of the core Scrum team, but rather part of the project team as a whole. This is because they are not working on the same context/goal within a Sprint. They are doing analysis for future Sprint(s), while the Scrum team works on items that have already been analyzed earlier (if not fully, at least at a great extent).
3. BAs work in analyzing requirements for future Sprint(s) is facilitated by the so called “backlog grooming cycles” that take place in parallel to the “Sprint cycles”.
Can you please share with me your thoughts on the above points?
Thank you in advance,
Ioannis
References:
[1] Is the Business Analyst a Product Owner or Tester on Agile Projects?
http://www.batimes.com/elizabeth-larson/is-the-business-analyst-a-product-owner-or-tester-on-agile-projects.html
Extract:
So how can BA do all the things BAs do so well without preventing the team from delivering an increment in short time frames, such as 2-4 weeks?
By ensuring requirements are defined completely and correctly before each sprint begins.
The BA can work with the product owner and other business and technical SMEs (Subject Matter Experts) as the delivery team completes each sprint.
However, the BA is working on requirements for the upcoming sprint, rather than the current sprint.
[2] Requirement analysis and Design flow in Scrum
http://www.scrumalliance.org/articles/149
Extract:
In conclusion, you can see the value of requirement understanding and design in the following Scrum activities (major ones in bold).
Requirement: backlog grooming (several rounds) -> Sprint Planning part 1 -> Sprint Planning part 2 -> Sprint -> done -> sprint review
Design: backlog grooming -> spike item (when necessary) -> Sprint Planning part 2 -> Sprint -> done
[3] Business Analysis in Scrum
(see “The Agile Extension to the BABOK Guide”, IIBA, November 2011; paragraph 2.1.4 on pages 17-18)
Extract:
Scrum does not address business analysis activities in detail and many of these activities occur as implicit steps in the scrum framework.
The building and maintenance of the product backlog is a significant business analysis activity that falls explicitly outside the scope of the scrum framework (although other methodologies have addressed this). The backlog is built through a combination of enterprise analysis work (identifying gaps and new capabilities required to accomplish organizational goals, and defining their value to the organization) and solution assessment and validation (identifying ways in which the existing solution can be enhanced to better deliver business value).
Within a sprint, business analysis activities focus on defining the requirements for the backlog items being worked on and the acceptance criteria for those items. This method is frequently referred to as just‐in‐time requirements gathering; developing only what is required for the current sprint and only done to the level of detail required to enable the team to build the product and acceptance criteria. In traditional methods, requirements documentation is frequently used as the documentation for the solution. In Scrum, as in most other agile methods, documentation is created after the product is built to capture the team’s knowledge, not define an expected or desired outcome. Most frequently the backlog documentation created during each sprint serves as sufficient documentation for the project.
Dear Ioannis,
Business analysis activities still take place in Scrum. But there is a significant change in how requirements are identified and described: It is now a team effort, and no longer the job of a specialist. The development team should reserve 5-10% of the time available in a sprint to work on the product backlog together with the product owner, for instance, in a product backlog grooming workshop.
As a consequence, the job of a business analyst in Scrum changes: The individual either plays the product owner role or becomes a team member. In both cases, the BA takes on new responsibilities. As a team member, the individual is likely to help with testing and documentation or with architecture and development work – depending on his or her skills.
[...] 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 [...]