A scrum pattern defines a specific problem an IT team development may encounter throughout the life-cycle of an application. Each pattern is created based on the Root cause analysis of project's failure or success:
- across multiple IT projects,
- ranging from small to large projects,
which guaranties the relevance of a pattern.
For instance, the Standish Group gathers a large amount of data on real-life IT failures since 1985 (with over 80,000 projects since 1994) and IBM has established the Top 7 factors of project failures
Also based on extended analysis, Project Management Institute, companies and individuals are regularly gathering to provide empirical solutions. This is the case of Jeff Sutherland, the co-creator of Scrum (development), who travels around the world to collect information whether on IT projects or on manufacturing industry. Then, he re-adjusts his viewpoint and propagates his knowledge through Summits, articles, training, workshops or free events.
Scrum patterns are useful to:
- help identify and define recurring problems within an IT product team,
- suggest solutions that were proven to work for other teams, and provide a larger view on the scope of the solutions,
- refer to related patterns an IT product team may face.
By formalizing a problem and providing a solution that has been tested across multiple organizations, a team could significantly increase/optimize its performance, self-esteem and moral, both individually, and as a team. Note: the Team is self-organized, with no micromanagement nor team leader, but rather a ScrumMaster serving as a Servant leadership with no people management responsibilities.
There are two types of Scrum patterns:
- the core ones that has been grouped into a Scrum Guide that is made available as Open Source, but still owned by their 2 co-creators (Ken Schwaber and Jeff Sutherland). Since this guide is meant to be small (16 pages as per today), to understand a specific pattern's usage and context, it is advised to rely on the literature maintained by the agile software development community,
- Additional patterns, maintained by the agile software development community. Their names may vary from one initiative to another, but the problem they address remains the same.
Patterns of IT project failures has been identified before the creation of Scrum. By formalizing empirical experiences into best practices to form the Scrum framework, this movement has been accelerated, particularly after October 2011 when Ken Schwaber and Jeff Sutherland released "The Scrum Guide, The Definitive Guide to Scrum: The Rules of the Game"  . It is a simplified version of the previous guides, so that only the core Scrum is present. Since this version, Scrum was made open source the community (but the owners remains Jess and Ken). As a result, additional advices, improvements and initiatives was launched, and various communities have further developed scrum patterns.
"Scrum pattern" refers to both Scrum (development) that is an agile software development and also to software design pattern. Similarly to Software design pattern, we could find Scrum anti-pattern, which gathers a list of all bad practices that guaranties either the failure of a projects or the generation of many frustrations.
When you want to move toward agility either on a new project or on an existing one, a scrum pattern helps identify and communicate the changes needed to the development team and the management. Ideally, the entire core Scrum should be implemented, then instead of picking-up randomly any Scrum artifact and implement it, the usage of Lean software development, specifically the Kaizen (i.e. in Japanese "philosophy of improvement"), one could quickly increase a team's velocity in a structured manner with low efforts but high Return on investment. With this one single improvement wisely identified would solve the majority of your problems. This is also known as the 20/80 ratio or Pareto principle largely used in manufacturing industry and statistics. In our case, 20% of the effort spent on the improvements would solve 80% of our problems, which could be enough to consider spending our remaining 80% of energy in building a valuable product for the customer.
Example of Scrum patterns and usage 
List of Scrum Patterns (non exhaustive) 
Here are list of free initiatives
- ScrumPLoP is a major actor that provides many references and explanation:
- unlocking-potential: http://unlocking-potential.de/scrum (Translated from German's organization: http://www.openpm.info)
Problem to solve: Multitasking that reduces productivity, introduces errors and frustrations 
Problem: Many studies, literature, articles and worldwide consulting firms, including recent ones from Louisiana State University psychology Professor Emily Elliott stresses the fact that multitasking of any kind reduces the productivity and/or increases rate of errors, thus generates unnecessary frustrations.
It has been estimated that $650 billion a year is wasted in US businesses due to multitasking.
Solution: ScrumPlop addresses this issue using the "first-things-first" Scrum pattern, when the context of the problem is summarized, and references and studies that justifies the solution are given.
- "The Standish Group".
- Joseph, Gulla. "Seven Reasons IT Projects Fail - Avoiding these pitfalls will help ensure success". IBM Systems Mag. Retrieved February 2012.
- "The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game". http://www.scrum.org. Retrieved October 2011.
- Elliott, Emily (18 September 2012). "Louisiana State University psychology professor". ITWorld. Louisiana State University. Retrieved 18 September 2012.
- Robert Rogers; Stephen Monsell (1995). "The costs of a predictable switch between simple cognitive tasks". Journal of Experimental Psychology. pp. 124, 207–231.
- Executive Control of Cognitive Processes in Task Switching. Human Perception and Performance. Journal of Experimental Psychology. 2001.
- "How Employers Can Make Us Stop Multitasking". Harvard Business Review. Retrieved May 17, 2012.
- "Multitasking Gets You There Later". infoQ. June 2010.
- Crenshaw, Dave (2008). The myth of multitasking : how doing it all gets nothing done (1st ed. ed.). San Francisco: Jossey-Bass. p. 144. ISBN 978-0470372258.
- RICHTEL, Matt (APRIL 20, 2011). The New York Times Blog http://bits.blogs.nytimes.com/2011/04/20/message-to-executives-stop-multitasking/
|url=missing title (help).
- Cherry, Kendra. "The Cognitive Costs of Multitasking". about.com : Cognitive Psychology.
- "Multitasking kills productivity and that's bad for new business".
- Derek Dean; Caroline Webb (January 2011). "Recovering from information overload". McKinsey Quarterly. McKinsey.
- RICHTEL, Matt (14). The New York Times http://www.nytimes.com/2008/06/14/technology/14email.html
|url=missing title (help). Retrieved June 14, 2008.
Further reading 
Soft skills to go beyond scrum patterns and further increase team's efficiency 
Scrum patterns, by design, are based on empirical facts and measures. To really understand what is behind the scene, soft skills have to be developed and a great help will come from the knowledge of complementary and powerful disciplines such as (and not limited to):
- Transactional analysis and a more easier one to understand, the PCM©, Process Communication Management© to understand people
- Neuro-linguistic programming (aka NLP), to help people change once they understood the problem thanks to Transactional analysis and/or PCM©
- Cognitive bias: Because everyone tend to distort the reality to a certain extent and unconsciously, this psychology tool represents a collection of known bias patterns that clearly provides a name to each bias (see List of biases in judgment and decision making).
Many of the scrum artifacts are empirical answers some bias, and when knowing the most important ones, it is easier to put in place artifacts such as the scrum ones to move toward the success of an IT project.
For instance "Timeboxing" is an answer to the optimism bias, that is one of the reason why the Mantra of agile software development and Lean software development is "Think big, act small, fail fast; learn rapidly" . However, some bias could be sometimes beneficial, because a bias is a very basic instinctive but wrong answer to complex situation, but could lead by chance to good outcome.
Other Scrum topics 
- "The Scrum Papers: Nut, Bolts, and Origins of an Agile Framework" (Jeff Sutherland, www.Scruminc.com, 2 Apr 2012): http://jeffsutherland.com/ScrumPapers.pdf
- "Story Points: Why are they better than hours?" (Jeff Sutherland, www.Scruminc.com, September 30, 2012) http://scrum.jeffsutherland.com/2010/04/story-points-why-are-they-better-than.html
- Agile Product Ownership in a Nutshell, by Henrik Kniberg : Henrik Kniberg blog - Agile product ownership in a nutshell