In our previous blogs, we covered what Agile business analysis is and how business analysts add value in an Agile environment. In this final blog, we talk about how to leverage Business Analysis skills in each of the five Scrum Events.
On this page:
Our third blog in our Agile Business Analysis series addresses the business analyst role in the various Scrum events. There are five listed Scrum events (previously known as “ceremonies”) listed in the Scrum Guide by Ken Schwaber and Jeff Sutherland: The Sprint, Sprint Planning, Daily Scrum, Sprint Reviews, and Sprint Retrospective. Scrum events do not just happen; they need to be facilitated to be effective. Although it is often the Scrum Master’s role to facilitate these events, the business analyst can also facilitate and play a role in the success of each event. The following lists a number of ways in which a business analyst can add value in each Scrum event.
We covered the business analysis activities in detail in the previous blog. To summarize, the business analyst’s role throughout the Sprint increment is as a member of the Development Team. The primary focus is refining and prioritizing the product backlog items and to identify which ones will be in the next Sprint. This is where the business analyst can support the Product Owner (PO) or if they are the PO’s proxy, they must be available and accessible during the Sprint to answer Team members’ questions and “inspect” the work so the Team can adapt.
The business analyst’s role in Sprint planning is to mentor, coach and support the PO in ensuring the product backlog items (PBIs) for a particular Sprint are “ready” (refined) as possible. The BA can help make sure each PBI meets the INVEST criteria (independent, negotiable, valuable, estimable, small, and testable), and includes robust acceptance criteria. They can also ensure that the relevant non-functional requirements and business rules have been identified and documented. In my experience, Development Teams often miss some non-functional requirements and business rules.
Business analysts may also help model the PBI and/or acceptance criteria if it helps the team understand what is needed. The Development Team designs, develops, and tests to the Acceptance Criteria so it is of paramount importance that nothing is left to assumption. They may coach/assist the PO (or act as their proxy) in presenting and discussing the PBIs, acceptance criteria, and the related models with the Development Team. The BA may also confirm an understanding of in-scope PBIs in support of (re)sizing efforts, identifying, and estimating tasks by the Development Team. A business analyst can also facilitate the Sprint Planning meeting.
The business analyst’s primary role in Daily Scrums is simple: As part of the Development Team, they must participate! They can be a role model for active engagement in the event and help elicit relevant information from Team members. They can also facilitate the Daily Scrums in lieu of the Scrum Master. If the BA is the PO or PO’s proxy, there is no need to attend the Daily Scrum unless they want to understand the status of the Sprint goal, obstacles the Team is facing, and/or be available for questions from the Team. In this case, they are an observer vs. a participant.
The business analyst can assist the Product Owner in preparing for the Sprint Review by identifying business stakeholders who may want to attend, as well as executing the logistics for the Review (e.g., invitations, physical or virtual room reservation/set-up, snacks, etc.). They may help determine which facilitation or presentation techniques to use and/or elicit and scribe feedback regarding demonstrated functionality. They also work with the Team after the Sprint Review to incorporate feedback into the Product Backlog and upcoming Sprint Planning meeting.
In a Sprint Retrospective, business analysts not only participate, but they should be a role model for active engagement. They may facilitate the event, plan the agenda, determine facilitation techniques to use for the Retrospective, obtain needed facilitation materials, and document the agreed “experiments” (things that will be done differently) to apply to the next Sprint.
What other things have you done as a business analyst to support the 5 Scrum events? Please share your ideas!
In these three blogs on Agile business analysis, we have explored what Agile business analysis is, the Agile mindset, the potential role a business analyst can play in an Agile environment and finally how the business analyst can add value in the 5 scrum events.
Wishing you all the best on applying your business analysis skills in an Agile environment.