Scrum@Scale Case Study
Hardware:
Scrum@Scale in Smart Homes
CASE STUDY SNAPSHOT
Organization: Anonymous
Organization Size:Small
Industry: Information Technology and Security
Topics: Customer and Vendor Involvement, Delivery and Velocity, Managing Dependency
Date: 2018
Website: Paolo’s Website
Summary
Modern hardware product development often requires coordinating the design and development of mechanical, electrical, material and software components while also managing external dependencies from vendors and suppliers. In his case study, Paolo Sammicheli was able to help a European Smart Home device manufacturer increase their velocity by a factor of 9.16 over the course of a year by deploying Scrum@Scale.
Managing Dependencies
In Scrum@Scale dependencies around processes and releases are generally identified and addressed at the Scaled Daily Scrum, while dependencies that affect sequencing and prioritization of backlog items are resolved at the Metascrum level. In this company, each external supplier was also assigned an internal person acting as the product owner of the external vendor. That person would then provide insight into external prioritization and dependencies at the Metascrum level while also ensuring that the external vendor was always working on the highest priority items that were needed most immediately by the other internal teams.
Buffet Planning
In situations where many backlog items have a high level of cross-disciplinary functionality, having clearly refined stories that can be pulled by any of a set of cross-functional teams is essential in order to balance resources across teams and ensure that team or personnel specific dependencies do not decrease productivity. Paolo created a multi-team backlog refinement process called “buffet planning,” in which teams would come to backlog refinement and be presented with a buffet of backlog items that need refining. Each team would take stories from the buffet and refine them as they saw appropriate, marking the story with a green sticker when they deemed it “ready.” Once a story had enough green stickers it would go onto the joint product backlog from which each team would pull.
Results
As you can see in the downloadable slides above, the combined velocity of the teams increased from under 10 points in early sprints, to approximately 20 points by sprint 10 all the way up to 30-50 points by sprint 20.
More Case Studies
Improve Predictability and Performance: Using Aggregated Velocity Data in Scrum@Scale
Agile Education Case Study Improve Prioritization and Performance: Using Aggregated Velocity Data in Scrum@Scale This case study explores how aggregated velocity data was used to improve the performance, prioritization, and predictability of engineering teams in a...