| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Pattern Name | Patlet | Author | Date | 1 | ||||||||||
2 | Value Stream Pattern Language | Value Stream | 2 | ||||||||||||
3 | Spirit of the Game | Rules create loopholes. Therefore: Use the rules as a guide, but be driven by The Spirit Of the Game in cases where the rules' applicability is ambiguos or contentious. | Jens Østergaard & Lachlan Heasman | 2012-05-08 | Value Stream | 3 | |||||||||
4 | Sprint Planning | Sprint Planning is the transition along the value stream between the Product Backlog and the Development Team's work plan | Neil Harrison | 2012-05-08 | Value Stream | 4 | |||||||||
5 | Daily Clean Code | Every night when you go to bed, the code should at least build cleanly and ideally should be shippable. | Neil Harrison | 5/1/2010 | Value Stream | 5 | |||||||||
6 | Small Items | Big items are hard to estimate; Therefore: Break down items so they are small enough to estimate with confidence | James O. Coplien | 2010-05-01 | Value Stream | 6 | |||||||||
7 | Whack the Mole | A separate bug-tracking system leaves an increasing bug inventory; Therefore: Fix bugs when they arise, relegating bugs that will require a large amount of work to the Product Backlog. Maybe needs clarification against Daily Clean Code. | James O. Coplien | 5/1/2010 | Value Stream | 7 | |||||||||
8 | Estimation Points | You need up-to-date estimates, yet it's much work to re-estimate everything as the velocity improves. Therefore: use unitless relative estimation against a baseline | James O. Coplien | 2010-05-01 | Value Stream | 8 | |||||||||
9 | Accountable Estimates | The Product Backlog must be estimated by the people who commit to the estimates. Therefore: have the Team develop cost estimates and the Product Owners develop Business Value estimates. | James O. Coplien | 12/22/2010 | Value Stream | 9 | |||||||||
10 | Pigs Estimate | Estimates should be grounded in reality rather than wishful thinking; Therefore: Let those who are going to do the work do the estimation | Gertrud Bjørnvig | 5/1/2010 | Value Stream | 10 | |||||||||
11 | Yesterday's Weather | People tend to set increasingly high goals for themselves to the point of not being able to achieve them; Therefore: Use the previous Sprint's velocity as the best indicator of the next Sprint's velocity | Joe Bergin | 5/1/2010 | Value Stream | 11 | |||||||||
12 | Updated Velocity | You want the velocity to reflect the team's current abilities, yet it takes time to know whether process improvements actually worked; Therefore: Update the velocity only if a new level is sustained for the past three sprints. | James O. Coplien | 5/1/2010 | Value Stream | 12 | |||||||||
13 | Teams that Finish Early Accelerate Faster | If you fail too many Sprints it's discouraging: failure comes from taking too many points into the Sprint. Therefore: use Yesterday's Weather to get about the right number of points; use Scrumming the Scrum to lubricate the acceleration; and realize the acceleration by taking on more work if you do finish early. | Jeff Sutherland | 7/10/2012 | Value Stream | 13 | |||||||||
14 | Kaizen Pulse also belong here? | 14 | |||||||||||||
15 | Regular Product Increment | In a complex environment, it is difficult to assess progress and meet business goals. Therefore: Develop a regular product increment both to keep on track and to meet market needs | Lachlan Heasman | 11/19/2011 | Value Stream | 15 | |||||||||
16 | Information Radiator | Kaizen is the core of Scrum, and improvement depends on transparency and visibility. Therefore: Create artifacts and roles that keep information visible to all stakeholders, and create ceremonies where information is exchanged and disseminated. | Swarm | Value Stream | 15 | ||||||||||
17 | Product Backlog | Everyone needs to agree to what should be delivered and when. Therefore: Create a visible Product Backlog of Product Backlog Items | James O. Coplien | 2010-05-01 | Value Stream | 16 | |||||||||
18 | Aggregate Velocity | Velocity is a property of a product backlog and not of a team; Therefore: have all Scrum teams for a single product backlog estimate together using a common baseline and range | James O. Coplien | 6/16/2012 | Value Stream | 17 | |||||||||
19 | Spike | Sometime you need (perhaps arbitrarily time-boxed) activities whereby the Development Team helps the Product Owner clarify requirements. Dropped — doesn't make sense in Scrum. | Ville & team | 5/1/2010 | Value Stream | 18 | |||||||||
20 | Set-Based Design | Sometimes it's hard to know which of several alternatives to pursue, yet the difference is crucial. Therefore: Pre-build each of several options as an exercise to mitigate risk. | Evan Leonard | 1/4/2017 | Value Stream | 19 | |||||||||
21 | Change for Free | Some PBIs are so context-free that they can easily be exchanged for others; Therefore: Allow the customer to add a PBI if the remove one of equal cost, thereby achieving higher value for the customer | James O. Coplien | 5/1/2010 | Value Stream | 19 | |||||||||
22 | Enabling Specification | Unexplored requirements cause unpleasant surprises; Therefore: The product owner should deliver enabling specifications that show that important questions have been raised and adressed | James O. Coplien | 5/1/2010 | Value Stream | 20 | |||||||||
23 | Estimation Range | Estimation isn't just about accuracy, but also about precision; Therefore: Handle estimates as ranges. I think that Release Range is a better pattern — this one looks too much like amplified guesswork. It's also kind of a microamangement thing and something more related to an old-style Project Management approach where individual items mattered more than delivering the Sprint | James O. Coplien | 5/1/2010 | Value Stream | 21 | |||||||||
24 | Granularity Gradient | Small items are easy to estimate, but it's a lot of work to break down big items into small items; Therefore: Break down just the items that you depend on in the near future | James O. Coplien | 5/1/2010 | Value Stream | 22 | |||||||||
25 | Refined Product Backlog | Alias for Definition of Ready | Neil Harrison | 1/6/2015 | Value Stream | 23 | |||||||||
26 | High Value First | PBIs have different values and costs; Therefore: To manage value in a rapidly changing environment, deliver the highest value PBIs first | James O. Coplien | 5/1/2010 | Value Stream | 24 | |||||||||
27 | Money for Nothing | You don't want to spend time building product that costs more than its long-term value; Therefore: Stop working when you have worked down the backlog to this point | James O. Coplien | 5/1/2010 | Value Stream | 25 | |||||||||
28 | Product Backlog Items | You want to organize work to optimize ROI; Therefore: Create PBIs to describe concrete product increments that increase value for stakeholders | James O. Coplien | 5/1/2010 | Value Stream | 26 | |||||||||
29 | Project Management | Scrum handles one product at a time, but you may have several revenue streams; Therefore: Handle several projects on a single product backlog | James O. Coplien | 5/1/2010 | Value Stream | 27 | |||||||||
30 | RechunkedPBIs | It's tedious to have too many fine-granularity PBIs deep in the Product Backlog; Therefore: Re-factor them back together into larger items | Ville Mäkinen | 2010-05-01 | Value Stream | 228 | |||||||||
31 | ROI | You need to order the items in the backlog; Therefore: order them such that you achieve the highest long-term ROI if delivered in the order of the Product Backlog | James O. Coplien | 2010-05-01 | Value Stream | 29 | |||||||||
32 | Specialized Velocities | It's hard to do Aggregate Velocity if you have too many teams; Therefore: Specialize teams (not individuals) and let each one estimate and build PBIs matched to their specialization | James O. Coplien | 2010-05-01 | Value Stream | 30 | |||||||||
33 | Running Average Velocities | You want the velocity to reflect the team’s current abilities, but it takes time to know whether process improvements actually worked. Therefore, set a running average of the most recent Sprints to calculate the velocity of the next Sprint. | Neil Harrison | 2012-05-06 | Value Stream | 31 | |||||||||
34 | Vacation PBI | If you are going to take time off from "real work," track the time and value of the Team Member's absence as a PBI on the Product Backlog. | James O. Coplien | 3/23/2013 | Value Stream | 32 | |||||||||
35 | Fixed-Date PBI | Some PBIs aren't scheduled by the PO, but reflect external dependencies or personal events such as vacation, or scheduled courses, conferences or vacations. | James O. Coplien | 3/23/2013 | Value Stream | 33 | |||||||||
36 | Definition of Ready | If work items are not precisely understood, development effort (and time) tend to balloon, which in turn cause the Sprint to fail. Therefore, deefine criteria which items must meet before they can be put on the Sprint backlog. | Neil Harrison | 1/6/2015 | Value Stream | 34 | |||||||||
37 | Down Time | You need both to support the long-term vision and give the whole team a sense of buy-in. Therefore: Fund periodic time for the team to innovate. (Superceded by Team Sprint and Set-Based Design) | James O. Coplien | 3/20/2011 | Value Stream | 35 | |||||||||
38 | Greatest Value | You want to reward good behavior at each level, yet you want the greatest value. Therefore: Let the vision drive to the value with the greatest scope. | Jeff Sutherland | 6/20/2011 | Value Stream | 36 | |||||||||
39 | Regular Product Increment | A backlog needs a vision, a view of the future that the team will help create | Lachlan Heasman | 4/16/2011 | Value Stream | 37 | |||||||||
40 | Sprint Pulse | Alias for Regular Product Increment. | Ville Reijonen | 2012-03-02 | Team | 38 | |||||||||
41 | Team Pulse | Alias for Regular Product Increment. | Ville Reijonen | 2012-03-02 | Team | 39 | |||||||||
42 | Daily Clean Code | Little housekeeping items don't make it as big schedule items; therefore: take care of them daily by insisting on continuous clean code. Maybe needs some clarification against Whack the Mole: "aiming" to have a result isn't a pattern, but a KPI. | Neil Harrison | 4/17/2012 | Value Stream | 40 | |||||||||
43 | Respsonsive Deployment | Working in rhythm is good, but so is smoothing out flow, and reducing the inventory of items ready to ship to the market. Therefore: Release products to the market as they become Done and are approved by the Product Owner in the middle of the Sprint. | Jim Coplien | Value Stream | 41 | ||||||||||
44 | Value Stream Fork | If a product gets too big, the Value Stream can't really work as intended (to provide feedback, team autonomy, and customer absorbtion of features).Therefore: when a product gets large, split it into multiple autonomous products that form an ecosystem. | Jim Coplien | Value Stream | 41 | ||||||||||
45 | Release Plan | The product owner can use the Product Backlog, together with teams' velocities, to make a release plan [Look at whether this is related to a Product Roadmap as part of the Value Stream pattern language. Maybe make it a little more explicitly Mike Cohn-ish. Maybe it's close, but it needs attention, particularly with respect to its relationship to a Roadmap] | Veli-Pekka Eloranta | 9/1/2017 | Value Stream | 44 | |||||||||
46 | Product Roadmap | A Product Backlog is a path, at any given time, through a roadmap whose business alternative decisions have been bound. Roadmaps are still a good idea and their relationship to the Product Backlog is instructive. | James O. Coplien | 2013-03-20 | Value Stream | 45 | |||||||||
47 | Release Range | Do not estimate releases as an absolute date, but as a range | Veli-Pekka Eloranta | 8/22/2011 | Value Stream | 46 | |||||||||
48 | Release Staging Layers | Release every Sprint, but don't release all Sprints to the full market. Create layers of release robustness to manage risk | James O. Coplien | 3/20/2013 | Value Stream | 47 | |||||||||
49 | Sprint | Both the time thing and the space thing (very very close to the Sprint backlog) | James O. Coplien | 2012-05-08 | Value Stream | 48 | |||||||||
50 | Emergency Procedure | Sometimes unexpected work arises during the Sprint, and there are regular rhythms in how to address them; Therefore: Define levels of escalation that resolve emergencies in the least disruptive form of escalation possible | Jeff Sutherland | 5/13/2012 | Value Stream | 49 | |||||||||
51 | Stop the LIne | Really really stop the line | Jens Østergaard and Neil Harrison | 3/28/2013 | Value Stream | 50 | |||||||||
52 | Daily Scrum | Because we have emergent requirements and uncertainty, the Development Team replans dailly to raise the chances of meeting their forecast. [This lives here because it's a ceremony to refine the value stream — it's Sprint Planning] | Neil Harrison, Lachlan Heasman, Jim Coplien | 2014-10-15 | Value Stream | 51 | |||||||||
53 | Daily Ritual | People skip or are late to Daily Scrums; Therefore: make it attendance part of the culture by establishing a ritual of the same time and actions every day. | Neil Harrison | 2013-03-09 | Team | 52 | |||||||||
54 | Pigs Talk | Team | 53 | ||||||||||||
55 | Incremental Replan | Even at the beginning of a Sprint, there are so many unknowns that it is impossible to create a perfect plan; Therefore: each day use the Daily Scrum to incrementally replan (dup of Daily Scrum itself? — probably not quite.) (I recommend folding this into Daily Scrum. We should audit whether we've done that — joc) | Neil Harrison | 2013-03-09 | Team | 54 | |||||||||
56 | Round-Robin Status | It is easy to focus what you are working on, and neglect the rest of the team; Therefore: Each person in turn gives status. | Neil Harrison | 2013-03-09 | Team | 55 | |||||||||
57 | Daily Open Kimono | The Product Owner needs to know what is going on, but status summaries often omit important details; Therefore: the Product Owner attends the Daily Scrum (alias for Pigs Talk) (破) | Neil Harrison | 2013-03-09 | Team | 56 | |||||||||
58 | Silent Product Owner | The Product Owner may try to manage the team during the Daily Scrum; Therefore: the Product Owner does not speak at the Daily Scrum. | Neil Harrison | 2013-03-09 | Team | 67 | |||||||||
59 | ScrumMaster Incognito | Problem : Team member look at SM during Daily Scrum Solution : SM goes away from the inner circle and become a chicken. Replaces pattern formerly named, "ScrumMaster turns into a chicken." | Jens Østergaard and Dina Friis | 2014-10-15 | Team | 68 | |||||||||
60 | Beatles at the Daily Scrum | Daily Scrum is a must in any Scrum implementation. To create an extra interest for the meeting add a little bit of fun. This can be done for | Jens Østergaard | 12/11/2011 | Team | 69 | |||||||||
61 | Substitute in Daily Scrum | Individual developers are sometimes absent from the Daily Scrum but it is important that the team know the status of their ongoing work. Therefore: Have another team member report on behalf of the absentee. | Ville Reijonen | 2012-03-02 | Team | 60 | |||||||||
62 | Sprint Retrospective | Neil Harrison and Mike Beedle | 2013-07-02 | Sprint | 61 | ||||||||||
63 | Sprint Backlog | The team needs a list to guide production work; Therefore: Make a Sprint Backlog that lists all work in a Sprint | Mike Beedle and Ademar Aguiar | 11/11/2010 | Value Stream | 62 | |||||||||
64 | Sprint Backlog Item | The above patterns talk about the ordering of the work plan, being free on an SBI level and chuncked at a PBI level. Within PBIs developers can create or delete tasks at will | Dina Friis & Jens Østergaard | 2013-03-28 | Value Stream | 63 | |||||||||
65 | Dependencies First | Dependencies suck. Therefore: Handle them in the first half of the Sprint and abort the Sprint if you can't. | James O. Coplien | 2012-06-16 | Value Stream | 64 | |||||||||
66 | Swarming: One-Piece Continuous Flow | Development Team has the final say over the ordering of Sprint backlog items. One-piece continuous flow should be split out of this. | Jeff Sutherland | 2013-03-13 | Value Stream | 65 | |||||||||
67 | Developer-Ordered Work Plan | People want direction, but task lists decrease self-organization; Therefore: Work from an unordered sprint backlog | James O. Coplien | 2010-05-01 | Value Stream | 66 | |||||||||
68 | First Things First | Pattern on working the top of the backlog (破) | Jeff Sutherland | 2013-03-13 | Value Stream | 67 | |||||||||
69 | Work the Top of the Backlog | Pattern on working the top of the backlog (破) | Jeff Sutherland | 2013-03-13 | Value Stream | 68 | |||||||||
70 | Burndown Chart | The obvious | Alan O'Callaghan | 2015-01-05 | Value Stream | 69 | |||||||||
71 | Track DONE | It's easy to misinterpret the burn-down chart overly optimistically with respect to business value; Therefore: Track business value progress separately and in additional to incremental task completion — REMOVED and factored into Sprint Burdown | James O. Coplien | 2010-05-01 | Value Stream | 70 | |||||||||
72 | Definition of Done | You cannot achieve quality if everyone has a different definition of quality. Therefore: the team defines criteria of all work to be completed on usual work items. | Ville Reijonen | 9/18/2015 | Value Stream | 71 | |||||||||
73 | Automated Code Checks | Definition of DONE does not mean "Ready to Ship" Solution : Work on automating checks of the code | Jens Østergaard | 5/1/2010 | Misc | 72 | |||||||||
74 | Definition of Done as Workflow | Team members must adhere to "Done" but also have to get their work done. Therefore: Integrate "Done" with the process, so the process tends to create results that adhere to the definition. | Ville Reijonen | 3/2/2012 | Team | 43 | |||||||||
75 | Value Areas | Too many people on one product dilutes focus, yet it's good to grow the business. Therefore: split the product when it grows to a certain point. | Cesário Ramos | 4/10/2016 | Value Stream | 71 | |||||||||
76 | Sprint Review | The dialog between the business and development is set aside during actual production but production and the business need to be kept in sync; therefore, provide the Product Owner and other stakeholders the opportunity to create feedback about what the Development Team has produced | Neil Harrison | 2013-05-03 | Value Stream | 73 | |||||||||
77 | Sprint Goal | A Sprint, by itself, is simply a time box for development that only coincidentally actually delivers something useful. Running development on coincidences is not a recipe for success; Therefore: Create a short statement of the value that the team intends to create during the Sprint. | Neil Harrison and Jeff Sutherland | 5/9/2012 | Value Stream | 74 | |||||||||
78 | Vision | A backlog needs a vision, a view of the future that the team will help create | Lachlan Heasman | 9/21/2011 | Value Stream | 75 | |||||||||
79 | Visible Status | Create status reports that show daily status (within the sprint) and larger project status, and post them where all development team members can see them.. | Neil Harrison | 6/14/2012 | Value Stream | 76 | |||||||||
80 | Fixed Work | Some work must be done on the team, but is difficult to estimate a closed work item. Therefore: Compartmentalize both recurring work and occasional spikes of work, particularly those that support the Product Owner process instead of directly building potentially shippable product | James O. Coplien | 2010-05-13 | Value Stream | 77 | |||||||||
81 | Domino Effect | One task can become "un-completed" if later work surfaces an emergent requirement; Therefore: Adjust all burn-down charts appropriately. [Can't remember why this pattern was interesting or special, and until we can remember that, we throw this out.] | James O. Coplien | 2010-05-01 | Value Stream | 78 | |||||||||
82 | Product Backlog Refinement Meeting | Replaced by "Refined Product Backlog" | James O. Coplien | 3/20/2011 | Value Stream | 79 | |||||||||
83 | Product Wake | All good things must come to an end | James O. Coplien | 2016-07-01 | Value Stream | 79 | |||||||||
84 | Work Flows Inward | Value Stream | Jim Coplien and Neil Harrison | 2004-06-06 | Value Stream | 80 | |||||||||
85 | Process Improvement | Process Improvement | 81 | ||||||||||||
86 | Sauna Sprint Review | People need motivation; therefore, celebrate success with an extended sauna and champagne Folded into Sprint Review. | Jukka Järvelä | 2010-05-11 | Process Improvement | 82 | |||||||||
87 | Fair Memory | People tend to focus on recent events, but the whole sprint is important. Therefore: Keep a log of sprint events | Dina Friis | 2010-05-01 | Process Improvement | 83 | |||||||||
88 | Sprint Retrospective | Neil Harrison and Mike Beedle | 2013-07-02 | Sprint | 84 | ||||||||||
89 | Scrumming the Scrum | Process improvement is a primary goal of Scrum; Therefore: Use Scrum itself to manage and give visibility to Kaizen initiatives | Jeff Sutherland | 2011-05-05 | Process Improvement | 85 | |||||||||
90 | Impediment List | Gabrielle Benefield | 2011-05-01 | Process Improvement | 86 | ||||||||||
91 | Historical Retrospective | Projects too often re-invent the wheel; Therefore: Start each new project with a retrospective over similar historic projects | James O. Coplien | 5/14/2011 | Process Improvement | 87 | |||||||||
92 | Learning Register | Aggregate retrospective results into a collection of foundational, long-term learnings (from PRINCE2) | James O. Coplien | 5/23/2011 | Process Improvement | 88 | |||||||||
93 | One Step at a Time | If you change multiple things at once, it's hard to know which one led to an improvement. Therefore: make one process improvement at a time | Neil B. Harrison | 6/29/2012 | Process Improvement | 89 | |||||||||
94 | Happiness Metric | Retrospectives are not effective; Therefore: focus on the improvement that will increase the team's happiness the most. | Neil B. Harrison and Jeff Sutherland | 3/8/2013 | Process Improvement | 90 | |||||||||
95 | Testable Improvements | You don't know if your improvement efforts are effective; Therefore: create self-improvement actions that can be measured whether they are being done or not. | Neil B. Harrison | 3/8/2013 | Process Improvement | 91 | |||||||||
96 | Create Knowledge | As the number of teams using Scrum grows they will face impediments and create valuable knowledge on solving them in their specific setting. Therefore: Form optimization teams consisting of people from the various Scrum Teams to capture the created knowledge so that the teams and organization can learn from it. Deprecated per mail from Cesário 23 March 2017 21:58. | Cesário Ramos | 2013-05-25 | Process Improvement | 92 | |||||||||
97 | Process Improvement | 93 | |||||||||||||
98 | Product Organization Pattern Language | Product Organization | 94 | ||||||||||||
99 | Community of Trust | Where it all begins. Link to Spirit of the Game | Jim Coplien and Neil Harrison | 2004-06-06 | Product Organization | 95 | |||||||||
100 | Conway's Law | Self-organisation is good but any group of human beings needs some basic, static organisation that reflects knowledge, change, and expediency. Therefore: Create an organisation whose primary structure localises the primary arenas of decision-making. | Jim Coplien | 2014-10-22 | Product Organization | 95 | |||||||||