Skip to main content

Shifting from Delivery-Mode to Product Management: Shifting the Focus of Your Sprint Review

August 5, 2024

When Scrum is used in project frameworks, it often devolves the Scrum Team's focus into ‘delivery mode’ as part of ‘build’ in the project’s design-build-run paradigm. This results in Scrum's events reflecting delivery activities — requirements and task-based milestones — as the release to 'business as usual' (BAU) and the transition to business stakeholders to realise the project's benefits have not yet occured. 

 

In a project lifecycle, value is typically released at the end of the project.

 

While not a criticism of project management, it reflects the reality of a project's purpose  —  deliver a set of requirements to business stakeholders on-time and on-budget using a contractual model (an approved and signed off set of requirements) over releasing value to customers in the shortest possible lead time so that the customer satisfaction gap narrows.

 

When executives evolve from a project organisation to a product organisation, the focus changes to a different set of phases: introducing the product, growing the product, maturing the product, and then (eventually) retiring the product. Scrum has a clear advantage here: 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.

 

In a product lifecycle, value is released early -- when the product is introduced to its customers.

 

With a new set of phases to move a product through, there are significant changes we should see in the conversations in Scrum’s events, particularly the Sprint Review.

The Nov 2020 release of the Scrum Guide reminds us that the Sprint Review is a working session, not your typical meeting, where attendees (the Scrum Team as well as stakeholders) inspect Increments of the product and get 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 the following:

Tactical Feedback Loops

  • 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?

Strategic Conversations

  • Have higher order business strategic goals or objectives change 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 preserve with our current direction?

Specialist 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.

 


What did you think about this post?