The Community Blog for Business Analysts

Ryan Thomas Hewitt
Ryan Thomas Hewitt

Replacing the Sprint Review Meeting with BMLs

Background

Like most Scrum teams, we held “Sprint Review Meeting” every two weeks. We would gather as a team to demo what was recently built & receive feedback. Although it was a great opportunity to showcase recent work, we identified a number of problems with “Sprint Review Meetings” for our mature product: 

1.     Stakeholder attendance was poor. Stakeholders saw the Sprint Review Meetings as a technical show & tell. The demos often didn’t work fully & business value wasn’t necessarily communicated.

2.     Because developers demoed the work, it put disproportionate pressure on the development team. We presented recent work & we often had problems with test environments/connections/mock data etc.

3.     More generally – the development team wanted regular updates from the product team. Our retros identified a need for the product team to provide regular updates about recent features; did a recently released feature meet our hypothesis? What did we learn? Will we iterate? How did it impact our quarterly OKRs?

4.     Sprint Review Meetings felt like a conveyor belt. We would demonstrate work, get feedback about quality, and then watch it leave the factory. But we wanted to learn how customers actually used the new product. We wanted external as well as internal feedback.

 

Build, Measure, Learn (BMLs) sessions

To address the above issues, we replaced Sprint Review Meetings with “Build, Measure, Learn” sessions. As advocates of the Build, Measure, Learn approach – we were keen to review recently released features with the team. We launched features every 2 weeks – so the natural cadence was to report on features at the end of the following Sprint.

We created “Build, Measure, Learn” sessions. The basic format is simple:

Frequency:

Every 2 weeks. At the end of the Sprint. Replaces the Sprint Review Meeting.

Attendees:

Team (Product, Devs, UX) & Stakeholders.

Duration:

1 hour.

Format:

The session is divided into two sections:

1. Build = demo from the development team about what was built during the Sprint. It’s a chance to get feedback from the Product Owner/Stakeholders.

2. Measure/Learn = product reporting back on stats/usage/insights of recently launched features. Typically on features & changes launched 2 & 4 weeks ago. This provides an external feedback loop.

The Measure/Learn section became as valuable as the demo section. It also provided practical breathing space for setting up/fixing demo’s – if we had problems we would start off with the Measure/Learn section ;-)

 

Build section

As with the Sprint Review meeting – this section was the development team demoing what was built during the Sprint.

This was an opportunity for product/stakeholders to provide feedback and ask any questions. Changes were noted by the BA and put on the product backlog.

It was also an opportunity to praise the team & celebrate success.

 

Measure/Learn section

In the Measure/Learn section the BA or Product Owner would cover the following areas: 

1.     General product performance: how we are performing against quarterly goals/OKRs

2.     For each recently released feature:

a.     Present the testable hypothesis

b.     Present the actuals. Key trends/unexpected findings/verbatim feedback from the audience about the feature

c.      Present key learnings/actions: Build a v2/pivot/stop at v1/kill the feature?

3.     Wider insights (optional):

a.     Present recent audience research/lab testing

b.     Present upcoming work that UX are exploring & get feedback on it

 

Summary

We found that BML sessions were a great replacement to Sprint Review Meetings. They ensured we kept the measurement & learning part of the lifecycle front and center in the team. The Measure/Learn section also ensured we reported back on business value regularly.

Main benefits:

1.     Learnings/insights about recently released features were shared with the team  - this kept us focused on our original hypotheses and business value. It enabled us to discuss the learnings based on external audience feedback.

2.     Encouraged a shared sense of ownership about the end of Sprint session and the performance of features

3.     Increased stakeholder attendance & stakeholder engagement as there was a focus on audience feedback and KPIs

4.     We were still able to demo the newly developed features & get Product Owner/Stakeholder feedback

This entry was published on Jul 21, 2016 / Ryan Thomas Hewitt. Posted in Project Management. Bookmark the Permalink or E-mail it to a friend.
Like this article:
  24 members liked this article

Related Articles

COMMENTS

Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN

 



Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.

 




Copyright 2006-2024 by Modern Analyst Media LLC