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