Scrum pattern

From Wikipedia, the free encyclopedia
Jump to: navigation, search

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, since 1985 the Standish Group [1] gathers a large amount of data on real-life IT failures (Standish Group is at the origin of the CHAOS report based on a database of 80000 real IT projects [1] and states that 76% of requirements change after a project has started) and provides an ability to profile current IT projects against those cases, within their offering of IT investment planning research and services.[1] Separately, IBM has established the top 7 factors of project failures.[2]

Also based on extended analysis, companies and individuals are regularly collecting fact and figures, such as the Project Management Institute, to provide empirical solutions gathered into good practices. 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, and regularly re-adjusts his viewpoint and propagates his knowledge through summits, articles, training, workshops or events.

Scrum patterns shares the goal of other patterns and/or Anti-pattern, which is 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 morale, 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 (more details on Scrum (development)).

There are two types of Scrum patterns:

  • The "official" one that has been reduced to its minimum and grouped into a Scrum Guide[3] 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".[3] 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 Jeff 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[edit]

List of Scrum Patterns (non exhaustive)[edit]

Here are list of some free initiatives

Problem to solve: Multitasking that reduces productivity, introduces errors and frustrations[edit]

Problem: Many studies,[4][5][6][7][8] literature,[9] articles[10][11][12] and worldwide consulting firms,[13] including recent ones from Louisiana State University psychology Professor Emily Elliott[4] 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[14] 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.


  1. ^ a b c "The Standish Group – About". Retrieved 2013-12-09. 
  2. ^ Joseph, Gulla (February 2012). "Seven Reasons IT Projects Fail – Avoiding these pitfalls will help ensure success". IBM Systems Magazine. Retrieved 2013-12-09. 
  3. ^ a b "The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game". Retrieved October 2011. 
  4. ^ a b Elliott, Emily (18 September 2012). "Louisiana State University psychology professor". ITWorld. Louisiana State University. Retrieved 18 September 2012. 
  5. ^ Robert Rogers; Stephen Monsell (1995). "The costs of a predictable switch between simple cognitive tasks". Journal of Experimental Psychology. pp. 124, 207–231. 
  6. ^ Rubinstein, Joshua S.; Meyer, David E.; Evans, Jeffrey E. (2001). Executive Control of Cognitive Processes in Task Switching. Human Perception and Performance. Journal of Experimental Psychology. 
  7. ^ "How Employers Can Make Us Stop Multitasking". Harvard Business Review. Retrieved May 17, 2012. 
  8. ^ "Multitasking Gets You There Later". infoQ. June 2010. 
  9. ^ 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. 
  10. ^ RICHTEL, Matt (April 20, 2011). "Message to Executives: Stop Multitasking". The New York Times Blog. 
  11. ^ Cherry, Kendra. "The Cognitive Costs of Multitasking". : Cognitive Psychology. 
  12. ^ "Multitasking kills productivity and that's bad for new business". 
  13. ^ Derek Dean; Caroline Webb (January 2011). "Recovering from information overload". McKinsey Quarterly. McKinsey. 
  14. ^ RICHTEL, Matt (14 June 2008). "Lost in E-Mail, Tech Firms Face Self-Made Beast". The New York Times. Retrieved June 14, 2008. 

Further reading[edit]

Soft skills to go beyond scrum patterns and further increase in team's efficiency[edit]

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):

Scrum artifacts are based on empirical answers to bias; by knowing the most important ones, this could prevent one to experience from himself trial and errors.

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".

When error in decision making could make your project fail[edit]

Over 70% of project fails (*) (**) (***), due to a numerous number of factors. The biases mentioned above contributes in taking a bad decisions; they are listed here: "List of biases in judgment and decision making".

(*) Why 70% of Government IT Projects Fail ?

(**) Dec 2008 Zdnet Study,

(***) University of Missouri-St. Louis

Other Scrum topics[edit]