Is your agile team stuck in “delivery mode”? Is it just showcasing work at the end of every Sprint?
Project management’s “design-build-run” paradigm often forces an agile team to use its Sprint Review to demonstrate the delivery of requirements. When you shift gears to product management, a deliberate change in focus is needed for events such as the Sprint Review.
When executives evolve from a project to a product organisation, the focus changes to a different set of phases:
- Introduction of the product to early adopter customers to establish product-customer fit.
- Growth of the product’s customer base.
- Maturity of the product, where the focus shifts to optimising operations to free up strategic funding for new products.
- Deline of the product, retiring it, and moving your customers to new, more effective products.
Adaptive planning and review frameworks, like Scrum, have a clear advantage advantage in these cycles, especially where the time to release value can be as little as a few Sprints. It doesn’t have to wait until the closure of the project before value can be realised.
With a new set of phases to move a product through, there are significant changes needed in Scrum’s events, particularly the Sprint Review.
The November 2020 release of the Scrum Guide reminds us that the Sprint Review is a working session, not a typical meeting, where attendees (including the Scrum Team and stakeholders) inspect Increments of the product and receive feedback. In projects, this event often ends up being a demonstration of working software (often referred to as a ‘demo’ or ‘showcase’). In a product environment, the Sprint Review becomes an important opportunity to engage stakeholders in:
- More strategic conversations
- Tactical feedback
- Specialist feedback
Strategic conversations
The Sprint Review provides product executives an opportunity to see the traceability of strategic objectives and potentially releasable value.
Key questions include:
- Have higher-order business strategic goals or objectives changed that may now influence adjustments to the Product Goal?
- Has what we’ve learned about our product mean the Product Goal needs to change? What about product portfolio strategies or other products’ goals?
- Does the current product roadmap need to evolve to accommodate new information? Should we pause, pivot or persevere with our current direction?
Tactical feedback loops
For a Product Manager and their senior business stakeholders, the Sprint Review provides an opportunity to examine the product’s current environment relative to what can now be released:
- What do the Increments in this Sprint mean for our product? How do they impact the product? Now that we can see them, how do they get us closer to the Product Goal?
- Has the product’s environment changed?
- What do our current value measures say about our current objectives: key value measures such as customer sentiment, product usage index, and even product cost ratio?
- What does the current demand look like? Are customers asking for new features, are they being supported in a timely way, are they satisfied with the service we provide?
- What does demand look like for our Cloud platform? Has CPU usage or storage gone up for Cloud Workload teams?
- Do the providers of our Cloud platforms (e.g. AWS, Azure, Google) have new features that we can take advantage of?
- What is the current % usage of those features that our own people make use of? What engagement, marketing, and communications needs to happen to improve our investment in making those features available to more stakeholders?
- Do we need more budget to take advantage of emerging demand?
- What could we do in the upcoming Sprints vs what should we do?
Specialist and technical feedback loops
The Sprint Review provides technical stakeholders, such as the Enterprise Architect, the opportunity to understand the current alignment of the product with the enterprise’s technical goals and strategy, as well as the efficacy of technical guardrails in the Definition of Done. This includes:
- Is intentional design providing Developers with sufficient guidance?
- Is the decentralisation of design creating technical debt or unintended consequences?
- What do the team’s architectural decision records (ADRs) say about Developer’s design capability maturity? Is there an opportunity for growth?
Stakeholders can provide the Scrum Team with insights into the rest of the organisation, evolving needs, and even insights into customers that may be beyond the reach of the team. With the Scrum Master facilitating, this event ultimately provides the Product Owner with the opportunity to do a deep dive with stakeholders and for Developers to hear first-hand the results of recent past work and what might lie ahead for them.
Conclusions
In transitioning from a project-based to a product-centric organisation, the role of Scrum evolves significantly. The Sprint Review, traditionally focused on demonstrating completed work, must transform into a dynamic platform for strategic alignment and continuous improvement.
By broadening conversations in the Sprint Review to encompass tactical, strategic, and specialist perspectives, organisations can harness Scrum’s full potential. This shift enables teams to not only deliver incremental value but also to actively contribute to the product’s lifecycle, from introduction to retirement.
A well-facilitated Sprint Review, therefore, becomes a cornerstone for fostering collaboration, driving innovation, and ensuring that the product remains aligned with evolving business objectives. By embracing this expanded view of the Sprint Review, organisations can optimise their product development efforts and achieve greater success in today’s dynamic marketplace.needed
