Scrum is a sizzling hot buzzword in the software development industry. The two software practitioners that are credited with inventing Scrum are Jeff Sutherland and Ken Schwaber. They presented the idea of Scrum at the OOPSLA Business Object Design in 1995, so Scrum is 21 years old at the time of publication.
The concepts of Scrum were derived from methods found in the manufacturing industry. Jeff Sutherland credited the paper that Takeuchi and Nonaka created called “The New New Product Development Game”  for being the inspiration of Scrum.
The concepts from the paper were customized to fit the software industry as there are concepts in manufacturing that are simply incompatible with software development. The good news is that Scrum has been in existence for over two decades and has had plenty of time to mature and become a well-oiled machine. Fast forward to the present and Scrum is now the most popular agile framework for managing software projects. In this article I’ll provide a high-level overview of the Scrum framework.
The Definition of Scrum
Scrum can be defined as a loose, light, framework for assisting teams with developing complex products. It’s important to remember that Scrum is a framework not a methodology. According to the Cambridge Dictionary, a framework is the ideas, information, and principles that form the structure of an organization or plan.  A methodology can be defined as a set off methods used in a particular area of study. 
Scrum is typically combined with software engineering methods like Extreme Programming (XP) as it doesn’t touch on the technical aspects of software development, but more on the soft skills. Scrum is nimble enough so that it can be applied outside the software industry. Some examples of industries in which Scrum was implemented are: finance , media , and insurance .
Scrum simplicity can ironically make it difficult to implement. I like the connection that Ken Schwaber made between Scrum and the game of chess. He stated this on his blog:
“I equate Scrum to the game of chess. You can read the official rulebook for chess. The moves, players, sequences, scoring, etc. are all specified. Learn them. Then you can play chess. Maybe your chess game isn’t so good, but you can study great games, strategies, and tactics, and practice to get better and better.” 
A lot of people know how to play chess, but very few become grandmasters. Mastering Scrum takes practice, dedication, and continual learning in order to become an expert.
The official source of Scrum, “The Scrum Guide” is a 17-page guide which succinctly explains the Scrum framework. However, its brevity could make new teams transitioning to Scrum feel unconfident about their endeavors. Let’s face it; if company XYZ has 300 developers working on multiple products, it’s a high probability that the Scrum Guide won’t explicitly answer all their concerns. Scrum is light-weight and intentionally doesn’t prescribe a heavy set of rules for teams to follow. Instead, it recommends that teams inspect and adapt their workflow to discover what works best based off empirical evidence.
Scrum Framework Diagram
Below is a large illustration of the entire Scrum framework:
As you can see, there are several components which Scrum is composed of. Scrum includes: team roles, artifacts, events, and rules.
There are three roles in a Scrum Team which are Product Owner, Scrum Master, and Development Team. The Product Owner is in charge with managing the product backlog, the Scrum Master is the facilitator, and the developers build the product.
There are three key artifacts in Scrum which are: Product Backlog, Sprint Backlog, and Increment. The product backlog is the ultimate to-do list and all product requests are inputted into this artifact. The Sprint Backlog is NOT the same as the product backlog––it’s a derivative of it and emerges during the Sprint Planning meeting. The Increment is the potentially shippable product which is produced at the end of each Sprint.
There are four key events in Scrum: Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. The Sprint Planning Meeting is when the team collaborates to figure out the workload they can handle for the upcoming Sprint, along with deciding who does what. The Daily Scrum is a recurring event during the Sprint in which the developers collaborate and take turns discussing The Three Questions.
The Sprint Review is when the Scrum Team and stakeholders meet to discuss the Increment. The Sprint Retrospective is when the Scrum Team reflects on the recent Sprint and determines ways on how they can improve their process. The Sprint is a wrapper for all of the events in Scrum. The next Sprint begins immediately at the conclusion of the Sprint Retrospective.
There are a couple of rules in Scrum that the Scrum Team should understand. They are: time-boxing, iterative/incremental development, self-organization, cross-functionality, empirical process control, and team sizes. Time-boxing is a classical management technique and is applied in a variety of ways in Scrum. One example is that it’s used to control the amount of time that the team invests during meetings. The Daily Scrum is allocated a maximum amount of fifteen minutes.
In Scrum, the product is built iteratively (looping), and incrementally (in baby steps). In other words, think of the expression “how to eat an elephant.”
It’s an unfathomable thought to try and eat the elephant in one setting, so the concept of eating it one bite at a time is a better alternative. On a side note, discussing elephants reminds me of one of my favorite childhood fictional characters which was “Babar the Elephant.” Discussing eating elephants even in this context seems strange so I’m hastily moving on.
Self-organization is a foreign concept to traditional managers, but denotes when developers are given the resources to get their job done. Since developers are the ones that posses the technical prowess, it’s not be a bad idea to let them decide how to execute. Scrum is a proponent of cross-functional teams. Instead of placing departments into silos, the walls are broken down and multidisciplinary teams work cohesively as a unit. According to the Scrum Guide, there are no titles for development team members. 
Therefore in theory, a pure Scrum team would have no distinction between a junior developer, tester, business analysis, and senior developer––they would all have the generic title of “developer.” The concept of cross-functional teams in Scrum reminds me of the concept of collective code ownership which was introduced in Extreme Programming (XP)––in this concept every developer is responsible for the health of the code.
Empirical process control is a fancy way of saying inspection and adaption. Scrum serves as a canvas for software developers to experiment with their art. The only true way that a team can determine what route to take is through taking action and analyzing the results. Predictive methods are fine to use but they are never error-proof.
Scrum is built for small teams. The recommended size for the Dev Team is 3-9 developers. There are many case studies that confirm that smaller team sizes will result in more efficient communication. Just imagine the zoo your office would become if you had to work in a room full of seventy developers!
There you go, that’s the general basics of Scrum. If you want a book that details every step of the entire framework in A-Z steps, then I would recommend my book Scrum Magic (no bias by the way, really ;)). It also includes four practice tests with solutions that you can reinforce your learning and gain more confidence in your knowledge of the Scrum framework. What’s your definition of Scrum?
Sources: “Takeuchi and Nonaka: The Roots of Scrum.” https://www.scruminc.com/takeuchi-and-nonaka-roots-of-scrum/
 Cambridge definition for framework: http://dictionary.cambridge.org/us/dictionary/english/framework
 Cambridge definition for methodology: http://dictionary.cambridge.org/us/dictionary/english/methodology
 “Organizational Transformation with Scrum: How a Venture Capital Group Gets Twice as Much Done with Half the Work.” http://ieeexplore.ieee.org/document/5428537/
 “Scrum Boosts Effectiveness at the BBC.” https://www.infoq.com/presentations/Scrum-bbc-newmedia
 “From Cradle to Sprint: Creating a Full-Lifecycle Request Pipeline at Nationwide Insurance.” http://ieeexplore.ieee.org/document/5261080
 “Scrum as a framework.” https://kenschwaber.wordpress.com/2010/09/08/scrum-as-a-framework
 The Scrum Guide: http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf ============================================================================ Want to learn how to use Python's most popular IDE Pycharm? In the free pdf guide "Getting the Hang of PyCharm" you'll learn all of the amazing features in PyCharm along with how to get started with data science. Subscribe to the Purcell Consult newsletter and get started A.S.A.P.