This appendix of patlets — pattern summaries — might help you find a pattern that addresses some particular problem or context you have in your Scrum team, or might help you find a pattern you vaguely recall having heard of. The patlets are simple problem / solution pairs that summarize the core of each pattern. We encourage you to go back and read the original pattern to pick up important subtleties not covered here.

Patterns in the Product Organization Pattern Language

§ 1  The Spirit of the Game  If team members believe they can “implement Scrum” by following its rules instead of acting on the deeper rationales behind them, then explicitly emphasize the spirit, not the rules of Scrum, as a foundation for the culture.

§ 2  The Mist  Great works start with a vague longing across some community. Therefore, an individual, or a collective mind of several individuals, conceives a vision of how to improve quality of life.

§ 3  Fertile Soil   Interaction qualities both reflect and define organization qualities. Therefore, demonstrate the values of Commitment, Focus, Openness, Respect and Courage in your day to day behaviors and interactions.

§ 4  Conway’s Law  How an organization partitions itself should aim to maximize its communication effectiveness. Therefore, structure the organization into Small Teams, each attuned to concerns that create the most value to the enterprise.

§ 5  Birds of a Feather  Empowered teams that self-organize tend to isolate themselves from the enterprise, but people best develop core competencies across boundaries of diverse work. Therefore, form an ad-hoc group for sharing expertise in each core competency.

§ 6  Involve the Managers  If development efforts are languishing for lack of coordination across products or because administrative tasks displace development efforts, then enlist a small management staff as “über ScrumMasters” who can initiate radical change, remove impediments, provide administration and coordinate from a “big picture” position.

§ 7  Scrum Team  Division of labor is inefficient at producing complex products. Therefore, form a team of people: Development Team, a Product Owner, and a ScrumMaster.

§ 8  Collocated Team  If the complexity of collaborative development demands high-fidelity communication, then locate the team together within talking distance.

§ 9  Small Teams  Having many people working on the same thing inflates communication overhead. Therefore, Use small teams of people working on serialized work rather than striving for false parallelism.

§ 10  Cross-Functional Team  Organizations often organize around areas of competence but it is too slow to coordinate across these boundaries. Therefore, the team as a whole should embody all the talent necessary to deliver product.

§ 11  Product Owner  You need a single, ordered Product Backlog. Therefore: Get a Product Owner with deep business experience and domain knowledge to create the backlog.

§ 12  Product Owner Team  For a large product, the Product Owner can get overwhelmed. Therefore, several people form a team to bridge the business concerns with development, led by the Chief Product Owner.

§ 13  Development Partnership  Arbitrary organizational or political boundaries obstruct communication between the vendor and the client. This leads to requirement hand-offs, distrust, and eventually failure. Therefore, break down the barriers with a mutual agreement to collaborate frequently.

§ 14  Development Team  Many hands make light work, therefore build a stable team to deliver successive increments of the Product Owner’s vision.

§ 15  Stable Teams  If you need predictability, then keep teams stable and avoid shuffling people around between teams.

§ 16  Autonomous Team  If policies and procedures applied across multiple contexts are dysfunctional, then the Scrum Team governs their work free from external control, and the Development Team manages its own work.

§ 17  Self-Organizing Teams  Specialized skills can't accomplish work without coordination. Therefore, the Development Team organizes itself to get its work done.

§ 18  Mitosis  A Scrum Team should grow in an incremental, piecemeal fashion; but eventually, the team just becomes too large to be efficient. Therefore, after it gradually grows to the point of inefficiency (about 7 people), split one large Development Team into two small ones.

§ 19  ScrumMaster  A self-organizing team cannot objectively see itself. Therefore, select one member to be the ScrumMaster, who helps the team improve their effectiveness.

§ 20  Oyatsu Jinja  Interruptions take focus away from product development. Therefore, create a snack shrine (Oyatsu Jinja) with snacks and drinks, where developers can entertain requests from the rest of the organization without interrupting their periods of flow.

§ 21  Small Red Phone  If the whole team is dependent on select key members, then issue a cellular hotline to the key members, only for critical use.

§ 22  Scrum (Master) Coach  If the ScrumMaster is limiting the team’s growth due to her own shortcomings then she should periodically seek opportunities for reflection with a coach.

§ 23  Fixed Work  Product Owner must account for all work to use team velocity for release planning, yet not all development work can be time-boxed. Therefore, leave the fixed work of standard, recurring Scrum events out of the Production Episode time budget.

§ 24  Sprint Planning  A Sprint aims to produce a potentially shippable product increment within a fixed time box. If the Scrum Team agrees on the Sprint Goal at the beginning of each Sprint, then they plan which PBIs to complete and how to do the work.

§ 25  Swarming  Working on too many things at once reduces velocity and the quality of work. Therefore, have the whole Development Team work together on one Product Backlog Item at a time.

§ 26  Kaizen Pulse  It’s difficult to absorb improvement lessons continuously without careful observation. Therefore, alternate between periods of controlled velocity with process improvement.

§ 27  Remove the Shade  If a hero in a team starts to overshadow other members, then remove the hero, so that the rest of the team can grow.

§ 28  Pop the Happy Bubble  If teams get complacent when things go well, then burst the team's bubble by making them confront their deficiencies.

§ 29  Daily Scrum  When delays and blockages happen in a Sprint, team dynamics require reshaping, but too much re-planning wastes time. Therefore, have a short meeting every day to replan the Sprint.

§ 30  ScrumMaster Incognito  At the Daily Scrum, the Development Team members report status to the ScrumMaster instead of interacting with each other. Therefore, the team addresses each other instead, with the Scrum Master taking on a silent role.

§ 31  Norms of Conduct  Members of a new Scrum Team bring different norms that could lead to misunderstanding and distrust. Therefore, Establish norms of conduct to facilitate accountability and allow positive conflict.

§ 32  Emergency Procedure  Inevitably, unanticipated problems arise and cause the Sprint Goal to slip out of reach, but waiting until the Sprint Review derails the whole Sprint. Therefore, Reevaluate the work plan mid-Sprint and escalate the solution with a pre-defined procedure.

§ 33  Illegitimus Non Interruptus  If various stakeholders and emergent requirements interrupt the team, crippling their progress, then explicitly allot time for interrupts and time box unplanned work to that budget.

§ 34  Scrum of Scrums  The Scrum Team working on a single product needs to split into multiple teams. Therefore, have representatives of each Development Team meet as a Scrum to coordinate inter-team dependencies and impediments.

§ 35  Sprint Review  Business stakeholders do not intervene during the Production Episode time box, but they need to stay in sync with product development. Therefore, hold a meeting for the Product Owner and other stakeholders to discuss what the Development Team has produced.

§ 36  Sprint Retrospective  Over time, without explicit attention, processes and discipline tend to decay. Therefore, hold a meeting at the end of each Sprint to reflect on the development process.

§ 37  MetaScrum  Scrum Teams are in place in an enterprise, but legacy management interferes by trying to exercise control over products. Therefore, Create a forum (Meta Scrum) for the whole enterprise to give management a say in Product Owners’ portfolio decisions.

§ 38  Product Pride  If team members need to know their work matters and to have a say in how it’s done, then create a climate that enables Autonomy, Mastery and Purpose.

Patterns in the Value Stream Pattern Language

§ 39  Vision  Overly specific constraints can turn contributors into subservient robots. Therefore, stakeholders and potential future coworkers rally to articulate and together to refine the Product Owner’s Vision.

§ 40  Impediment List  Impediments to progress surface all the time, but addressing them immediately may not be practical. Therefore, make them visible on a list.

§ 41  Value Stream  The development process and the path from conception to market are as important to product success as the product idea itself. Therefore, create an ecosystem to deliver ever-increasing value in an evolving product.

§ 42  Set-Based Design  If tackling a problem with many dimensions, then explore multiple potential solutions where each one probes different regions of each dimension, so the team develops a broad intuition of the problem that leads to the best feasible current option.

§ 43  Sprint Burndown Chart  Progress should be immediately visible to Development Team members. Therefore, publicly post a graph that plots estimated work remaining in the Sprint against the remaining time.

§ 44  Scrum Board  There's a danger that the Development Team will lose its focus on the Sprint Goal. Therefore, Create a Scrum Board that visualizes the Sprint Backlog and the current status of the work.

§ 45  Product Roadmap  When the vision is clear and the market is ready, the team needs concrete steps to achieve this marriage. But a list cannot express the uncertainty ahead. Therefore, the Product Owner should lay out alternative paths, making it visible. Only then, a Product Backlog can take shape.

§ 46  Sprint  The team needs to deliver Product Increments often enough to correct course based on frequent feedback from the end user. Therefore: Organize development around recurring, frequent, fixed-length time boxed intervals called Sprints.

§ 47  Organizational Sprint Pulse  The Scrum Team and the rest of the organization are out of step, causing waiting time or interruptions. Therefore, Synchronize the teams’ Sprints to the organization’s rhythm at least once a month.

§ 48  Release Plan  If the stakeholders need to know which product increments are coming out and when, then create an ordered list of deliverables and forecast dates from the Product Backlog.

§ 49  Release Range  Release dates inherently lack precision, but stakeholders tend to treat an estimated delivery date as a commitment. Therefore, make pessimistic and optimistic estimates for release dates based on Product Backlog Item estimates and a range of historic team velocities.

§ 50  ROI-Ordered Backlog  The Product Backlog needs some order to drive the order of delivery. Therefore, Order PBIs in a way that generates the largest long-term ROI.

§ 51  High Value First  Some PBIs are critical, while others are just nice to have. Therefore, deliver the highest value product increment first.

§ 52  Change for Free  Scrum team wants to respond to new client requirements while avoiding scope creep. Therefore, Offer clients the option of exchanging an emergent requirement for any existing PBI of equal (or lower) value to them, as long as the development cost of the new item is no more than the cost of the original.

§ 53  Money for Nothing  It's waste to spend time building a product increment that costs more than it’s worth. Therefore, stop work when the product’s development costs begin to exceed its expected value.

§ 54  Product Backlog  Even when everyone agrees to what product increments to deliver, the Development Team doesn’t know what they should deliver first. Therefore, create an ordered list of product increments arranged by their delivery date.

§ 55  Product Backlog Item  (PBI) The Product Backlog is composed of large, monolithic parts, that impose unnecessary risk. Therefore, create distinct specifications of changes and additions to the product, called Product Backlog Items.

§ 56  Information Radiator  Information flow is critical to the organization, but sharing through reports and meetings wastes effort, which often discourages communication. This results in sharing too little. Therefore, display information at a physical wall and keep it frequently updated.

§ 57  Pigs Estimate  Estimates of effort should be based on what is known, and not on wrong assumptions and wishful thinking. Therefore, Let the Development Team, who members are committed to working on the product, estimate the work.

§ 58  Small Items  When work items are too big, they become hard to understand and estimate. Therefore, Decompose large items into smaller items that Developers can easily understand and build.

§ 59  Granularity Gradient  Small Items are easiest to estimate, but breaking down larger work items is work in itself. Therefore, break down only the earliest Product Backlog Items into Small Items.

§ 60  Estimation Points  It is important to easily make estimates that are reliable enough to confidently forecast the amount of work that the team can complete in a Sprint. Therefore, use unit-less relative numbers for effort estimation.

§ 61  Fixed-Date PBI  Dependencies for the product often happen on their own time, and cannot be scheduled by the Development Team, but the team must account for how it shifts the schedule. Therefore, create a dependency PBI and position it in the Product Backlog to appear in the Sprint corresponding to the fixed date.

§ 62  Vacation PBI  Most corporate value systems honor vacations, but while they don’t create market value in the way that product increments do, the Product Owner should make their cost and value visible. Therefore, track the time and value of team members' absences as PBIs.

§ 63  Enabling Specification  If the Development Team is uncertain about the product vision and the development process, then the Product Owner should specify the PBI for the Development Team in enough detail to leave no question unanswered.

§ 64  Refined Product Backlog  Market volatility changes the relative value of PBIs. Therefore, the Scrum Team meets regularly to properly order, break down, and estimate the Product Backlog.

§ 65  Definition of Ready  Improperly defined PBIs lead to waste in development effort in a Sprint, causing it to fail. But a common understanding of PBIs lead to focus in the team. Therefore, create an objective “Ready” standard before placing a PBI in a Sprint, i.e. estimated, testable, small items, discussed, has customer value.

§ 66  Yesterday’s Weather  If courage challenges the team to set overoptimistic goals, then refer to the work done in the last Sprint to forecast the work for the upcoming Sprint.

§ 67  Running Average Velocity  The velocity should reflect the team’s current capacity, but it takes time to stabilize after a change. Therefore, use a running average of the most recent Sprints to estimate the velocity.

§ 68  Aggregate Velocity  Multiple Scrum Teams working towards a single release date should estimate when they will deliver, but it makes no sense to sum unit-less velocities from different teams. Therefore, estimate PBIs together so there is a single velocity range across teams.

§ 69  Specialized Velocities  If the product grows to multiple teams, then each team estimating and delivering the product increments for the whole product is waste.

§ 70  Updated Velocity  You want the velocity to reflect the team's current abilities, yet it takes time to monitor your improvements. Therefore, update the velocity only if the team sustains a new level for three Sprints in a row.

§ 71  Sprint Goal  A Sprint that consists only of tasks is not enough to relate the team’s effort to Greatest Value. Therefore, create a concise goal to unify the team's achievements throughout the Sprint.

§ 72  Sprint Backlog  The Development Team should understand the work needed for achieving the Sprint Goal. Therefore, create a work plan at the Sprint Planning Meeting for everything that the Development Team needs to do in that Sprint.

§ 73  Sprint Backlog Item  A PBI clarifies what to build but does not specify how to build it. Therefore, during Sprint Planning, break down PBIs into smaller work items for the development plan.

§ 74  Teams that Finish Early Accelerate Faster  Teams often take too much work into a Sprint and cannot finish it. Failure to attain the Sprint Goal prevents the team from improving. Therefore, take less work into a Sprint.

§ 75  Production Episode  The collective flow of the team demands fewer disruptions and a sense of urgency. Therefore, time-box all development efforts, with participation limited to the Development Team.

§ 76  Developer-Ordered Work Plan  The Scrum Team commits to a Sprint Goal, and there are multiple ways to achieve it. Therefore, let the developers decide the best ordering of the work in the Sprint Backlog to achieve the Sprint Goal.

§ 77  Follow the Moon  Every culture acts in cadence to natural events yet business cycles track the Gregorian calendar. Therefore, define Sprints with beginning and ending boundaries on the New Moon and the Full Moon.

§ 78  Visible Status  Without a frame of reference, you can unknowingly drift. Therefore, create a status overview that demands action when outside acceptable tolerance.

§ 79  Dependencies First  If dependencies remain halfway through the sprint, they may bring the rest of the Sprint to a halt. Therefore, make sure that all known dependencies are under control by mid-Sprint.

§ 80  Good Housekeeping  Where there’s a mess, you lose time and energy finding where and what to start on. Therefore, maintain a completely clean product and work environment continuously or at the end of each day.

§ 81  Whack the Mole  Defects arise while adding new functionality. Postponing work on them causes them to pile up, which further impedes development. Therefore, as soon as the team discovers defects, developers should drop what they are doing and mitigate them immediately

§ 82  Definition of Done  Mismatched understanding of 'done' in the team will produce varying quality in tasks. Done means that there's no more work left for that task. Therefore, the Development Team agrees on what Done means beforehand.

§ 83  Team Sprint  PBIs with smaller ROI never make it to a Sprint, even if the team cares deeply about them and they may contribute to long-term cost reduction. Therefore, on occasion, let the team choose which PBIs they want to include in the Sprint.

§ 84  Responsive Deployment  If some PBI development finishes in the middle of a Sprint, then Instead of waiting until the end of the Sprint, then the Product Owner releases PBIs as soon as they’re Done.

§ 85  Regular Product Increment  It's important to measure development progress by checking off completed work, but outcomes are more important than output. Therefore, mark progress every Sprint as a delivered Product Increment, and elicit feedback on how it matches end-user needs.

§ 86  Release Staging Layers  We would like to receive stakeholder feedback as frequently as possible, but it is too risky to deploy to the whole market at once. Therefore, partition the market into multiple release groups from beta testers to the whole market. Release every Sprint to the appropriate groups.

§ 87  Testable Improvements  If you are working on a complex product, measures of value may vary for both planned and unplanned reasons, and it may be difficult to tie an increase to a planned kaizen. Therefore, monitor both the actions that a team takes to realize a kaizen, and the corresponding change in value.

§ 88  One Step at a Time  If changing multiple things at once obscures which change led to an improvement, then make one process improvement at a time.

§ 89  Value Areas  If teams work across more and more customer domains and start to approach the boundaries of what they can master, then organize the teams around areas of customer value.

§ 90  Value Stream Fork  Product success needs a crisp market identity, but a growing product with divergent features dilutes the focus of a single Scrum Team. Therefore: Split a large product, and its Value Stream, into multiple Value Streams, each with its own Product Backlog and Product Owner.

§ 91  Happiness Metric  If a growing list of improvement activities dampens the team's passion for the work, then prioritize the impediment list in order of the team’s passion to solve it.

§ 92  Scrumming the Scrum  Scrum is more than just doing work; it’s also about improving the way we work. Therefore, resolve the most important impediment by putting one in the Product Backlog every Sprint.

§ 93  Greatest Value  The team works to contribute to overall value, but short-term thinking leads to improving just the small things. Therefore, let the Vision direct the team’s attention to the greater scope.

§ 94  Product Wake  Products can't last forever, and the company shouldn't tie up talent to feed a dead Value Stream. Therefore, at the end of a product’s life, give it a decent burial.

Patterns from the Organizational Patterns Book

The following patlets describe patterns from the Organizational Patterns book, [1] and the section number refers to the section number in that reference.

§ 95  Community of Trust  If you are building any human organization, then you must have a foundation of trust and respect for effective communication at levels deep enough to sustain growth. (Section 4.1.1.)

§ 96  Named Stable Bases  If you want to balance stability with progress, then have a hierarchy of named stable basis that people can work against. (Section 4.1.4.)

§ 97  Take No Small Slips  If you are getting behind schedule and you need additional time resources, then take one large planned slip instead of creating project instability and low team morale with small, unanticipated slips. (Section 4.1.9.)

§ 98  Completion Headroom  If work is progressing against a set of hard dates, then, make sure there is Completion Headroom between the completion dates of the largest task and the hard delivery date. (Section 4.1.10.)

§ 99  Recommitment Meeting  If the schedule can’t be met with simple adjustments to the work queue and starring, Then: assemble developers and interested managers to recommit to a new strategy based on doing the minimal amount of work to reach a satisfactory conclusion. (Section 4.1.12.)

§ 100  Informal Labor Plan  If development needs are fluid, Then: instead of master planning, let them negotiate among themselves to develop short-term plans. (Section 4.1.14.)

§ 101  Developer Controls Process  If you need to orchestrate the activities of a given location or feature, Then: put the Developer role in control of the succession of activities. (Section 4.1.17.)

§ 102  Work Flows Inward  If you want information to flow to the producing roles in an organization, then put the Developer at the center and see that information flows toward the center, not from the center.

§ 103  Programming Episodes  If you need to split up work across time, then do the work in discrete episodes that combine to create concrete deliverables. (Section 4.1.19.)

§ 104  Someone Always Makes Progress  If distractions constantly interrupt your team’s progress, then whatever happens, ensure someone keeps moving toward your primary goal. (Section 4.1.20.)

§ 105  Team per Task  If a big diversion hits your team, then let a subteam handle the diversion so the main team can keep going. (Section 4.1.21.)

§ 106  Sacrifice One Person  If a smaller diversion hits your team, then assign just one person to resolve it. (Section 4.1.22.)

§ 107  Day Care  If your experts are spending all of their time mentoring novices, then put one expert in charge of all the novices and let the other experts develop the system. (Section 4.1.23.)

§ 108  Interrupts Unjam Blocking  If you need to schedule urgent development activities according to some reasonable priority scheme, then use an interrupt scheme to keep individual problems from blocking the entire project. (Section 4.1.25.)

§ 109  Don’t Interrupt an Interrupt  If a new urgent need arises while you’re already in the middle of handling an interrupt to keep the project from getting stuck, then continue handling the current issue before moving on to the new one. (Section 4.1.26.)

§ 110  Size the Organization  If an organization is too large communications break down, and if it is too small, it can’t achieve its goals or easily overcome the difficulties of adding more people. Therefore: start projects with a critical mass of about 10 people. (Section 4.2.2.)

§ 111  Apprenticeship  If you have difficulty retaining expertise, then grow expertise internally from existing employees or even new hires. (Section 4.2.4.)

§ 112  Solo Virtuoso  If a project is intellectually small, then overstaffing it is a waste of time and money. Therefore, staff small projects with Solo Virtuosi. (Section 4.2.5.)

§ 113  Surrogate Customer  If you need answers from your customer, but no customer is available to answer your questions, then use scenarios to define the problem. (Section 4.2.7.)

§ 114  Firewall  If you want to keep your developers from being interrupted by extraneous influences and special interest groups, then impose a Firewall, such as a manager, to “keep the pests away”. (Section 4.2.9.)

§ 115  Gatekeeper  If you need to keep from being inbred, Then: use a Gatekeeper role to tie development to other projects, research, and the outside world. (Section 4.2.10.)

§ 116  Self-Selecting Team  If you appoint people to a team, the people don’t come together as a team. People who share similar outside interests make the best team members. Therefore, teams should be largely self-selecting, performing limited screening of candidates based on their track record and outside interests. (Section 4.2.11.)

§ 117  Unity of Purpose  If a team is beginning to work together, then make sure all members agree on the purpose of the team. (Section 4.2.12.)

§ 118  Team Pride  If a team needs to perform above and beyond the call of duty, then instill a well-grounded sense of elitism in its members. (Section 4.2.13.)

§ 119  Patron Role  If you need to insulate Developers so Developers Control the Process and support organizational inertia at a strategic level, then identify a Patron accessible to the project who can champion the cause of the project. (Section 4.2.15.)

§ 120  Matron Role  If your team needs ongoing care and feeding, then include a Matron Role on the team who will naturally take care of the team’s social needs. (Section 4.2.18.)

§ 121  Wise Fool  If critical issues do not get aired easily, then nurture a Wise Fool to say the things nobody else dares say. (Section 4.2.21.)

§ 122  Domain Expertise in Roles  If you need to staff all roles, it’s difficult to determine how to match people to roles in order to optimize communication. Therefore, match people to roles based on domain expertise, and emphasize that people play those roles in the organization. (Section 4.2.22.)

§ 123  Moderate Truck Number  If you can’t eliminate having a single point of failure in allocating expertise to roles, then spread that expertise around as far as possible, but not more so. (Section 4.2.24.)

§ 124  Compensate Success  If enterprises are to succeed, they must reward the behaviors that lead to success; however, these behaviors are varied, and success is difficult to measure. Therefore, establish a spectrum of reward mechanisms for both teams and individuals. (Section 4.2.25.)

§ 125  Failed Project Wake  If people have put their hearts and souls into a project, that subsequently is canceled, then celebrate the project’s demise and hold a “wake” for it. (Section 4.2.26.)

§ 126  Developing in Pairs  If you want to improve the effectiveness of individual developers, then have people develop in pairs. (Section 4.2.28.)

§ 127  Engage Quality Assurance  If Developers can’t be counted on to test beyond what they already anticipate going wrong, then engage QA as an important function. (Section 4.2.29.)

§ 128  Producer Roles  If your organization has too many roles, but does not know which to eliminate, then identify roles as Producers, Supporters, or Deadbeats and reduce the number of roles to 16 or fewer. (Section 5.1.3.)

§ 129  Organization Follows Market  If there is no clear organizational accountability to a market, then make some organization accountable for each market to ensure that the market’s needs will be met. (Section 5.1.9.)

§ 130  Face-to-Face Before Working Remotely  If a project is divided geographically, Then: begin the project by inviting everyone to a meeting at a single place. (Section 5.1.10.)

§ 131  Distribute Work Evenly  If you want to optimize team effectiveness and productivity, then alleviate overload on specific groups and individuals in your organization by Distributing Work Evenly. (Section 5.1.13.)

§ 132  The Water Cooler  If you need more communication between institutionalized organizations, then leave space for everyday human activities that can provide more complete and informal communication. (Section 5.1.20.)

Patterns from Fearless Change

This patlet describes a pattern from [2] by Linda Rising and Mary Lynn Manns.

§ 133  Do Food  If you want to draw people to an event in which they otherwise might hold only a neutral interest, then entice them with food and refreshments.

[1] James Coplien and Neil Harrison. Organizational Patterns of Agile Software Development. Pearson, 2005.

[2] Linda Rising and Mary Lynn Manns. Fearless Change. Addison-Wesley, 2004.