According to a recent study*, 71% of organizations in the U.S. use Agile methods for their software development projects, with Scrum being the leading agile development framework. However, more than 25 years since Scrum was first introduced, there are still tons of questions surrounding it, particularly regarding the role of the business analyst on a Scrum team.
Having been involved in Agile and Scrum projects for almost 15 years, I’ve always wondered why various organizations implement the role of the business analyst differently in their Scrum projects.
In this article, I will guide you through the elements of Scrum through the lens of a business analyst. If you’re new to Agile or Scrum, use this article as a start guide. If you’re an experienced BA - you’ll find some helpful tricks here.
Let's dive right in and explore Scrum for Business Analysts!
(*) Zippia. "16 Amazing Agile Statistics [2023]: What Companies Use Agile Methodology" Zippia.com. Nov. 27, 2022, https://www.zippia.com/advice/agile-statistics/
What is Scrum?
It is important to note that Scrum is a subset of the broader Agile family of methodologies and frameworks. Therefore, comparing Agile and Scrum would be incorrect, to the point that many software development teams use the terms "Agile" and "Scrum" interchangeably.
If you want to learn about Scrum but don't know where to start or whom to listen to, I want to ask you for a small favor. Please check out the Scrum Guide, which is the source of truth written by the Scrum fathers - Ken Schwaber & Jeff Sutherland. It's super short (14 pages!), easy to read, and contains self-explanatory information that really explains a lot of things.
Scrum is not a comprehensive software development methodology!
Instead, it's simply a framework that organizations may (and should!) adopt and implement according to the Scrum Guide. For example, the widely spread "3 amigos" meetings are not explicitly part of Scrum. But it's okay to have those meetings on a project if the team decides they need it and this meeting brings value.
Roles on a Scrum Team
According to the Scrum Guide: “The Scrum Team comprises three primary roles: the Scrum Master, the Product Owner, and the Developers. Within the Scrum Team, there are no sub-teams or hierarchies. It functions as a cohesive unit with a singular focus on the Product Goal.”
Now you may wonder - Hey, does it mean that there’s no room for a business analyst in Scrum?
Well, there certainly is!
The Role of a Business Analyst in Scrum
As mentioned above, Scrum is a flexible framework and it allows organizations to adapt it to their specific needs. Therefore if you need a business analyst on the team - go and add one!
Moreover, I have never even encountered an agile project without a BA!
In most cases, BAs are part of the Scrum team where they focus on maintaining a healthy product backlog, communicating and clarifying functional requirements across the development team, product owner, and end users. Of course, the responsibilities of business analysts can vary depending on the organization and the project; let's explore in more detail what business analysts usually do on a Scrum team.
Communication in Scrum
Business analysts always act as mediators and communicators, facilitating the exchange of information regarding business goals, functional requirements, user stories, and acceptance criteria. Agile projects may only be successful in an environment of inclusivity, transparency, and continuous communication, and BAs are an integral part of this culture of transparency and communication.
Daily Scrum for Business Analysts
Like other team members, business analysts participate in daily scrum meetings. They actively listen and offer assistance where needed. My advice to BAs is to proactively engage with the team and ask questions to ensure that requirements are all clear and the team has no impediments related to unclear requirements. If they do - make sure to reach out and offer help, by scheduling a separate meeting (don’t steal time on the daily standup!) to discuss the issue in detail and find ways to resolve it.
Product and Sprint Backlog
Traditionally, business analysts are responsible for maintaining product and sprint backlogs, including capturing epics, features, and user stories. Because user stories have become the standard for capturing requirements in many agile implementations (often replacing traditional use cases), team members and project leaders expect business analysts to produce well-defined stories.
To ensure that the user stories and other artifacts meet the team's expectations, It is crucial for a BA in Scrum to establish a rapport with the team, and early on clarify the team's expectations regarding acceptance criteria, level of detail, the inclusion of UI designs, data dictionaries, business rules, and so on. These expectations should be captured with a Definition of Ready and followed throughout the project.
Sprint Planning
Business analysts collaborate with Product Owners and the team to prepare for Sprint Planning. During Sprint Plannings, BAs often present user stories and are expected to answer any upcoming questions. To ensure a smoother planning process, I recommend sharing user stories with the team before the actual sprint planning session. Use backlog refinement meetings to present user stories to the team in advance, gather early feedback, and understand the level of detail required by the team.
Backlog Refinement
During the backlog refinement, business analysts present user stories (including those that are not yet ready!) to gather the team's and the PO's feedback and understand the team's expectations regarding the level of detail. Here are a few recommendations:
Sending an agenda in advance helps team members prepare specific questions for refinement. It is also a good idea to reach out to solution architects or technical leads beforehand to discuss any important or tricky questions prior to the refinement.
I also recommend encouraging the team to actually estimate user stories during backlog refinement, so that it happens before the sprint planning. Those estimates will be preliminary and later will be confirmed during the sprint planning session. This will highly speed up the planning session, but also ensures that the team is truly involved in refining the stories.
Also, please remember - this event is called Backlog Refinement, not grooming! I have a separate article on this topic - check it out here.
Sprint Reviews
Sprint reviews are much more than just a demo! During the spring review, the team and the product owner should review the progress toward achieving the sprint goal, engage in the conversation with the stakeholders and as needed adjust the product backlog. Yes, the demo is an integral part of the sprint reviews, and the BAs often conduct the actual demo part. During the sprint review, BAs should also seek feedback on the sprint results, collect any open questions, and follow up on them after the review.
User Acceptance Testing
During the final stages of the active project implementation, business analysts are involved in preparing for user acceptance testing. They are often asked to describe end-to-end user journeys that will be used to perform the acceptance testing, with a focus on the functionality that spans multiple functional areas and epics. Sometimes, user acceptance testing is integrated into the implementation phase, with e2e and UAT being performed on an epic-by-epic basis throughout the implementation phase.
Learn More
Interested in learning more? Download the Scrum Cheat Sheet - your all-in-one summary designed specifically for IT business analysts. As a bonus, it also includes a 10-minute video lecture on Scrum for BAs.
Conclusion
While effective communication is key to being successful on the Scrum team, BAs should always remember the importance of producing actual tangible deliverables - a healthy backlog, user stories, and other documents.
Communication alone is not sufficient for the team to achieve excellent results!
And, of course, any business analyst should be a role model for the five Scrum values:
Commitment
Focus
Openness
Respect,
and Courage
All this, along with delivering high-quality deliverables, will ensure you maintain a high visibility profile and be a valuable asset to your team and the organization.
I would love to hear your thoughts and the practices you apply as a business analyst in Scrum. Your feedback will be incredibly valuable for future articles. Please let me know!
Comments