This page will help you craft and submit your scaling pattern. All submissions are published in the public library of patterns for anyone to view, and we encourage you to submit your patterns — no matter how small or large or successful. If you are not familiar with the Scrum at Scale framework take our free online course, download the Agile2014 slideset explore the infographic.
In short, the Scrum at Scale framework is an object-oriented model for scaling scrum across the business. The modular approach allows for the overall system to work together even if individual modules aren’t agile. This allows the framework to support many different contexts verses other more tightly coupled scaling systems.
What is a pattern?
A pattern is a practice or process that has been observed to address a specific set of challenges in a defined context. Patterns have emerged because scrum is prescriptive about the goals of each part of the framework but says very little about how to meet those goals. As such, over the years common practices have emerged to help teams meet those goals in the face of known impediments. Much like a play out of a sports team’s playbook, patterns help teams react to change and set the stage for success.
There are many well-documented patterns at the team level, and an authoritative library can be found ici. Our goal is to create a public library of scaling patterns so that the community can learn from itself.
What does a scaling pattern look like?
Below is an example pattern. The goal of a pattern is to describe the practice in just enough detail that anyone familiar with the framework and concepts will be able to implement it.
Module: Backlog Prioritization
Pattern name: Features, Components, Teams
Modèle :
Backlog prioritization is cascading and flows from a single product backlog down to multiple component backlogs, and finally into individual team backlogs.
The top-level product backlog is maintained and prioritized by a single Chief Product Owner. It captures, at the feature and epic level, the backlog for at least the next release. The product backlog is refined bi-weekly at a refinement meeting with all component product owners. Refinement sessions focus on readying two sprints of backlog. The Chief Product Owner also holds regular meta-scrum meetings with the stakeholders in the organizations to align on and make visible the prioritization of the backlog. All product feedback flows through the Chief Product Owner, who then reflects the feedback in the prioritization of the product backlog and communication in refinement meetings.
The top-level product backlog is categorized by product component (Which part of the product will this feature be added to?) to create component-level backlogs. Component backlogs are owned and prioritized by a single component product owner, who is often also a senior team-level product owner. Each component backlog is refined weekly by the product owners of the teams that work on the component. These refinement sessions focus on breaking down the features into sprint sized stories, and prioritizing these stories along with research and technical debt items identified by the teams for the team-level backlogs.
The component-level backlogs are then split by teams to create their sprint backlogs. These sprint backlogs contain at least enough work for the next two sprints on a rolling basis.
Contexte:
Key Drivers: Innovation, enhanced speed of delivery, enhanced customer experience
The organization is a market leader and looking to stay ahead of the competition. The company makes multiple products, though this pattern relates to one of those products, which is a legacy desktop product that is being adapted to a Software as a Service model. Releases happen once a year and have historically been disruptive for customers due to the large number of new features in each release.
Successes:
It provides a degree of centralized vision with the CPO as the main control point, while also responding to change and leveraging team-level knowledge/autonomy through a team of product owners. It has allowed the teams to manage dependencies and produce a more integrated product. This approach covers prioritization, decomposition and planning in one cadence of regular meetings.
Challenges:
This pattern requires overhead effort to maintain the refinement meeting and meta-scrum cadence, as well as discipline to follow-through on refinement and coordinate dependencies across components. The Chief Product Owner has a particularly heavy workload juggling meta-scrums, all product feedback, and weekly refinements with component and team product owners.
Industry: Software
Organization size: 7,000
Submit your Pattern
The form below will guide you through the submission process. Reference the example pattern above and keep in mind the goal is to provide enough detail so that anyone reading your pattern will be able to implement it. Remeber your pattern’s challenges and successes are equally important.
Upon submission your pattern will uploaded to the public pattern library. Your name and email are required so that we can follow up on submissions and help refine your pattern. You contact information submitted on this form will never be shared with the public and will only be use to contact you about scaling patterns.
French 
English 
Spanish