In Scrum, are BAs invited to standups, and are they chickens or pigs?
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
I read with interest this answer from Jeff Sutherland, co-founder of Scrum:
Q: What's your view on the Business Analyst and how it relates to Scrum? Is there a place for the role or should the skill set of that position be spread across/owned by the team?
A: The Business Analyst is responsible for clarifying the requirements for the team so this effort belongs partly with the Product Owner and partly with the team. I usually assign a Business Analysis to work with the Product Owner until the backlog is ready and then work with the team to make sure it is implemented well.
And this article lists these roles for a BA:
Gathering requirements by managing relationships with stakeholders and facilitating those conversations;
Providing guidance on what to build when to release as much value as possible as early as possible;
Helping the Scrum team to plan and improve their ways of working through retrospectives;
Ensuring the work done by the team aligns with the wider business strategy.
Does this mean a Business Analyst in Scrum should be attending standup meetings, as a pig?
Solution
There are three questions asked of every participant at a standup meeting. They are:
- What did I do yesterday that helped the development team meet the sprint goal?
- What will I do today to help the development team meet the sprint goal?
- Do I see any impediment that prevents me or the development team from meeting the sprint goal?
Notice that "requirements clarification" is not part of the three questions.
The entire meeting should take no longer than 15 minutes. In that time frame, it is possible that question 3 may raise an issue with a requirement specification, but the resolution of that problem would take place outside of the standup meeting, with the BA present.
OTHER TIPS
"The BA is responsible for clarifying the requirements for the team"
It is the responsibility of the scrum master to seek clarification from the BA outside the daily standup meetings. It makes sense to include BA in the planning meetings of individual sprints but not in daily standup meetings.
I don't understand how the analogy to chickens and pigs applies to a BA in a scrum.
The chicken and the pig fable, along with the entire "chicken" and "pig" terminology, has been removed from the Scrum Guide.
The purpose of the Daily Scrum is for the Development Team to review and coordinate their activities. That is, the look at how they are doing towards completing the work in the Sprint Backlog and how they are doing toward achieving the Sprint Goals. One rule of the Daily Scrum is that only Development Team members participate and the Scrum Master ensures that attendees from outside the Development Team do not disrupt the event.
So, who is a Development Team member? The three Scrum roles are Product Owner, Scrum Master, and Development Team. The Development Team "consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint." Who this is depends on your organization. If your Business Analysts are doing work that is required to meet your team's Definition of Done, then they are part of the development team. However, if they aren't doing the work that goes into meeting the Definition of Done, then they aren't a member of the Development Team.
In the question, there are four roles for a Business Analyst listed:
- Gathering requirements by managing relationships with stakeholders and facilitating those conversations;
- Providing guidance on what to build when to release as much value as possible as early as possible;
This is part of the ongoing activity of refining the Product Backlog. This isn't tied to the Sprint, but the changing needs of the various stakeholders. This doesn't really have a place in Daily Scrum. Items should be added, removed, and reordered in the Product Backlog continuously, by the people who are empowered to make those decisions. That likely includes the Business Analysts.
- Helping the Scrum team to plan and improve their ways of working through retrospectives;
This isn't part of a Daily Scrum, but the Retrospectives. The Retrospective is open to the entire Scrum Team, which includes the Product Owner. If the Business Analysts are working closely with the Product Owner to support the team, it makes sense that they would also likely be present.
- Ensuring the work done by the team aligns with the wider business strategy.
This could potentially be useful at the Daily Scrum. As an observer, the Business Analysts can bring any possible delays in meeting the Sprint Goals and completing the Sprint Backlog out into planning for future work. In the event that the Sprint Goals are at risk, they can be available immediately following the Daily Scrum to coordinate with the team on how to prioritize the remaining work to add the most value to stakeholders. Although the Daily Scrum is timeboxed to 15 minutes, it's not uncommon to immediately move into more detailed discussions with the right people present following a Daily Scrum.
Per Scrum, BAs are not participants in the Daily Scrum unless they are also doing work toward achieving the Definition of Done. However, participation and attendance are different. You need to evaluate if having your BAs attend and then be available for discussions (as needed) after your Daily Scrum is worth their time.
As a BA who IS embedded in a scrum team and attends daily standups, I thought I'd try to offer a little insight from personal experience. Generally speaking, BAs are not a perfect fit for an agile scrum project. They (we) can still be very useful, particularly on a large project with many teams, where a Product Owner cannot be everywhere at once. BAs can function as subordinate "stand in" POs. In many cases, it is helpful to have someone close to the team who can answer questions about requirements and who has a good grasp on intended use of the app and customer business processes.
This does not really mean that having a BA embedded with a scrum team is ideal. It does help as far as facilitating communication with the team about requirements, and the BA can serve as a useful conduit to help facilitate more communication between the customer and the devs (who can be reluctant to reach out to the customer directly or may not know exactly who needs to be asked what in order to clarify something). Generally though, this is not enough of a good reason to be in the morning stand up meeting. The BA does not usually have useful updates for the team, and is not needed for answering questions in that format, especially since they should be available to devs anytime during the course of the day.
In our case, BAs are asked to write user stories for the teams, verify that the user stories are linked to agreed upon scope FLIs (functional line items), and check functionality of completed stories as a sort of "sign off" before they go into the formal testing process. I do see a lot of benefit from having BAs "embedded" in scrum teams, but in reality, the reason my project does this is primarily due to the fact that we have a government customer, which simultaneously wants us to be "agile" and hinders our ability to really practice agile software development. I consider my own position to be a result of a "scrummerfall" type of compromise, unfortunately.
I'd argue the BA should not be part of the scrum process at all. They are not a member of the scrum team. Instead, they are resource for the Product Owner, who is a member of the scrum team. The Product Owner is ultimately the one responsible for determining what goes in the backlog and in what order, as well as the acceptance criteria of those PBIs. The BA, then, helps the Product Owner make these decisions, but that doesn't mean they're now part of the scrum team.
I personally think the analogy (and use of) chickens and pigs is a helpful one. None of the teams I work with use it any longer.
Imo it was invented to focus standups. So here is the thing: a standup is there to facilitate delivery. Mainly to unblock the team. Remember, it's not a status update. It's a quick run-through to ensure the team can deliver.
For this reason we included the entire team in our standups, be the PO, BA, QA, Dev, UX...
However, we also know that we only speak when we have blockers or dependencies to highlight.
There is a lot of bureaucratic, misguided 'just follow the process' thinking around Scrum which often leads to teams getting less value because they follow the letter of the law. Be flexible, do what helps your team, not what some book says...
