What to Share and What to Hide from Stakeholders During Sprint Review?
What to Share and What to Hide from Stakeholders During Sprint Review?
A decision making model that eliminates all confusion.
👋 Hello, I’m Vibhor, and welcome to the 🔒 subscriber-only edition 🔒 of my weekly Q&A Series powered by Winning Strategy. Every week, I answer one reader question and publish 2 posts about Agile Products, Role-Based Skills, and anything else that you need answered about your Career Growth. You can send me your questions here.
On to this week’s question!
Q: Hi Vibhor. Is it necessary to share Scrum metrics with stakeholders during the sprint review meeting? I believe it's important to share transparency with the stakeholders in any way, and for me, the best way is to share the metrics. However, I don't think it's mandatory to share them during the review meeting. What do you think about this?
Thank you for bringing this up.
Although the question you asked is about the "metrics," in this post, I will provide you with enough tools and tricks that you can use to determine what to share and what to withhold from stakeholders, whether it's:
metrics,
information,
data, or
difficult situations
I remember the first time I observed a Product Owner lead a Sprint Review.
He was new to the role and was eager to showcase every detail of his team’s progress.
“It’s good,” I thought, thinking that the more information shared, the more transparency there is and the better it is for the product’s health.
Naive? Yes.
Well…I was new to the game too.
You live, and you learn.
In that sprint review, the PO walked the stakeholders through the code, detailed technical challenges, and even the team’s internal debates.
By the end of the meeting, there was a lot of confusion.
The meeting stretched for 1 extra hour, and everyone was upset.
Lesson learned: Not all information is directly shareable, and more isn’t always better.
Over time, I realized that Sprint Reviews are all about striking the right balance. A balance between being transparent without confusing your audience.
Why is this important and…
Why does a Sprint Review matter so much?
Sprint Reviews are important because they are not just about showcasing what your team has accomplished. The outcomes of these meetings determine the future of the product and the career trajectory of your team within the company, including your own.
When done right, these meetings establish a connection between you, your team, and the decision-makers (the stakeholders).
This connection is based on trust, which can then be leveraged to achieve product success.
So, how do you do it right?
How do you strike that perfect balance between transparency and discretion?
It’s all about knowing your audience and tailoring your message to fit their needs.
As a team, your goal during Sprint Reviews is to provide stakeholders with a clear and honest assessment of the product's:
progress,
achievements, and
challenges
However, there may be certain details that are not necessary to share. Here's a “general” guide on what to share and what to withhold:
Information to share:
Sprint Goal and Objectives
Completed User Stories and Acceptance Criteria
Product Increment Demo
Key Performance Metrics (e.g, user engagement, conversion rates, customer satisfaction)
Note: Don’t show the team’s performance metrics, such as burndown charts, velocity, cycle time, etc, unless the goal is to showcase how fast the project is progressing.
User Feedback and Insights
Challenges, Obstacles, and Solutions
Positive Impacts and Achievements
Lessons Learned and Improvements
Upcoming Sprint Goals and Priorities
Alignment with Product Vision and Roadmap
Relevant Market Trends and Competitor Analysis
Stakeholder Collaboration and Dependencies
Resource Allocation and Capacity Planning
Risk Management and Mitigation Strategies
Information to withhold:
Internal Team Conflicts
Team Performance Issues
Sensitive Data (e.g., specific revenue figures, profit margins)
Unvalidated or Speculative Ideas and Plans
Confidential Customer Data
Personal Information about Team Members
Detailed Technical Implementation Details
Detailed Debugging or Error Logs
Specific Security Vulnerabilities or Weaknesses
Inefficient Code Snippets
Internal Communication or Correspondence
Negative or Unproductive Feedback about Stakeholders
Irrelevant or Tangential Information that Distracts from the Main Objective of the review
This is a good list that can help your team make informed decisions about what to share and what to withhold during Sprint reviews.
But!
This is NOT an exhaustive list.
In 18 years, I have seen numerous cases in which it becomes extremely difficult to decide whether to share the information with the stakeholders or not.
For example:
Suppose your team undergoes internal restructuring that, while important for the team's efficiency, does not directly affect the stakeholders or the project's outcomes.
Would you or would you not share this detail with your stakeholders?
It is not easy to tell!
You might guess an answer, but…
How can you be sure what’s the right thing to do?