6

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?

Improve this question
4
  • Do any of those last four bullets apply to a standup meeting?
    – Robert Harvey
    Apr 18, 2017 at 19:09
  • Not really, which is why I am confused. In Jeff's answer he states "The BA is responsible for clarifying the requirements for the team" which to me is an activity that occurs in almost every single standup, both for PBIs and for defect arbitration.
    – John Wu
    Apr 18, 2017 at 19:22
  • "Requirements clarification" is not one of the functions of a standup meeting.
    – Robert Harvey
    Apr 18, 2017 at 19:38
  • Rly? Devs are always bringing up things they are working on and asking questions about requirements (see barely good enough documentation).
    – John Wu
    Apr 18, 2017 at 19:40

6 Answers 6

Reset to default
14

There are three questions asked of every participant at a standup meeting. They are:

  1. What did I do yesterday that helped the development team meet the sprint goal?
  2. What will I do today to help the development team meet the sprint goal?
  3. 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.

Improve this answer
5
  • OK I think I've been doing it wrong. We have a very low defect rate, and 75% of them are due to ambiguous requirements, so we've just been knocking those over right there in the standup. I guess we should be having a separate bug scrub meeting with the BA and keeping that stuff out of the standup meetings. Thank you for your answer.
    – John Wu
    Apr 18, 2017 at 19:44
  • 5
    It's up to you. If your current process works well for your organization, then naturally you would continue to use it. You just can't call it "orthodox scrum," that's all.
    – Robert Harvey
    Apr 18, 2017 at 19:46
  • @JohnWu: It could also be that in your case that after the standup, where the developers coordinate the daily work, there is a seamless transition to a requirements clarification meeting.
    – Bart van Ingen Schenau
    Apr 19, 2017 at 16:43
  • 2
    @JohnWu please don't ever think you're "doing it wrong". There is no wrong, only what works for your team & context and what doesn't.
    – RubberDuck
    Apr 19, 2017 at 22:59
  • Scrum purists will argue that you shouldn't be holding that conversation at that time. At all. I would ask if you are keeping the stand up short (less than 15 minutes). If YES, and your team likes the way it runs, fine. If NO, then parking-lot those discussions. BTW, is the PO not attending the stand up? Why not?
    – Curtis Reed
    Apr 24, 2017 at 20:36
5

"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.

Improve this answer
6
  • When the PO has too many teams to support, as the author mentioned, the BA serves as a kind of "proxy-PO". If a dev member mentions they have a need to get clarification, it can be helpful to know that and resolve the issue quickly. It is preferable for the PO/BA to speak directly to the Dev team member rather than play telegraph via the scrum master.
    – Curtis Reed
    Apr 24, 2017 at 20:43
  • @CurtisReed, I am assuming the scrum master will include the appropriate dev team members in that discussion.
    – R Sahu
    Apr 24, 2017 at 20:46
  • So you prefer for the BA, who may have the answers they need, to be absent, until the scrum master schedules yet another meeting? Wouldn't it be more efficient to have the BA present, note the discussion topic, and answer the questions immediately after the stand up? Are we not looking for ways to make work more efficient, and eliminate waste such as waiting?
    – Curtis Reed
    Apr 24, 2017 at 21:09
  • @CurtisReed, one could argue that it's a waste of the BA's time to be at every standup when they are only needed occasionally.
    – R Sahu
    Apr 24, 2017 at 21:12
  • @R Sahu so how does your response apply to the PO? Should they only attend "when needed"? If the BA is working collaboratively to help the PO (who attends the daily stand up meetings), then the presence of the BA may not be necessary. But very often they are also answering questions about additional details required by the technical team to be able to complete stories. The team just needs to try one way or another and see what is working, and if the BA's presence speeds communication.
    – Curtis Reed
    Feb 19, 2018 at 17:20
2

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.

Improve this answer
1

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.

Improve this answer
0

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.

Improve this answer
0

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...

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.