What are the Scrum Framework fundamentals?
Daniel J. Power
Editor, DSSResources.com
Scrum is an agile framework and structured set of ideas that is intended to help teams collaborate on complex tasks. Agile is both a way of thinking and a set of principles that guide decision making. Scrum.org materials state "Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum itself is a simple framework for effective team collaboration on complex products."
Scrum has gained increasing popularity over the years due to its simplicity, and its capability to incorporate various overarching practices in other Agile models. Much has been written about Scrum and this discussion abstracts and interprets three primary sources -- the Schwaber and Sutherland (2017) "Scrum Guide", Rubin's (2013) "Essential Scrum", and Nicolaas's (2018) "Scrum for Teams". The summary also builds upon web materials including videos at scrum.org and mountaingoatsoftware.com.
Ken Schwaber and Jeff Sutherland (2017) assert that "Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices." This is an abstract, overview, and simplification of Scrum. The path to agility requires active learning and participating in project teams that use Scrum. This discussion attempts to complement and summarize the official Scrum framework, cf., Schwaber and Sutherland (2017).
Scrum is presented as a lightweight, easy to understand framework and process. Lightweight means Scrum that has only a few rules and practices and they are easy to follow. The more one studies Scrum and learns about the framework, the more complexity that is encountered. Actually mastering Scrum is a challenging, ongoing quest. Scrum is a framework for guiding a process, it is not a methodology or a step-by-step recipe. The Scrum framework identifies what needs to be done and the Scrum team must figure out how to do it. Scrum must be interpreted and modified to fit a specific situation and set of circumstances. Finally, all Scrum elements or parts are needed to create an effective process and to deliver a valued result. The three pillars of Scrum that uphold every implementation of empirical process control are 1) Transparency, 2) Inspection, and 3) Adaptation. The pillars of emphasize transparency of the significant aspects of the process, an inspection of progress to goals, and adaptation and adjustment as needed to minimize problems.
The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules. Each component within the framework serves a specific purpose and "is essential to Scrum’s success and usage". The rules of Scrum bind together the roles, events, and artifacts, governing the relationships and interaction between them. The essence of Scrum is a small team of people. The individual team is highly flexible and adaptive.
The five Scrum values of commitment, courage, focus, openness, and respect must be understood and "lived" by the Scrum Team. These 5 principles and values create a code of behavior for a team member that must be understood and followed. Examining the definitions for these values helps internalize the values. By pursuing these values, the three Scrum pillars of transparency, inspection, and adaptation gain meaning and can help build trust for everyone. Scrum team members learn and explore these values as they work with the Scrum events, roles, and artifacts. Schwaber and Sutherland (2017) claim "Successful use of Scrum depends on people becoming more proficient in living these five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have the courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people."
The fundamentals include: 1) Scrum roles and responsibilities; 2) writing requirements and user stories; 3) creating and managing the Product or Project Backlog of work; 4) estimating effort and prioritizing backlog items; 5) planning and executing a short duration Sprint; 6) sprint reviews and retrospectives; and 7) the “Definition of Done” and why it is important to know when a project is "Done".
Scrum Team roles include a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Scrum teams are described as self-organizing because members choose how best to accomplish tasks and create value. Teams consist of people from different areas of an organization who have diverse skills that are needed for a specific, complex project. The Product Owner is a single person who is responsible for managing the Product or Project Backlog, the list of features, changes, tasks or other activities that when completed achieve specific outcomes. The Development Team is the professionals who do the work and deliver "a potentially releasable increment of 'Done' product at the end of each Sprint". The Scrum Master is a servant-leader for the Scrum Team who helps everyone understand Scrum theory, practices, rules, and values. Self-organization is the management principle that teams autonomously organize their work. Self-organization happens within boundaries and against given goals. Teams choose how best to accomplish their work, rather than being directed by others outside the team.
Daily Scrum Meeting is a fifteen-minute time-boxed meeting held early in each workday where each development team member answers three questions: 1) "What have you done since the last Scrum meeting? (i.e. yesterday)", 2) "What will you do before the next Scrum meeting? (i.e. today)", and 3) "What prevents you from performing your work as efficiently as possible?" The Scrum Master must ensure participant discussions do not go too far outside these constraints. The Scrum literature recommends that this meeting take place first thing in the morning, as soon as all team members arrive. Another way to express the questions is to ask: 1) What tasks have you worked on since we last talked? 2) What tasks are you planning to work on next? 3) Is anything getting in the way of finishing the work as expected?
Product Backlog (or "backlog") is the list of requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements. While there are multiple inputs to the product backlog, it is the sole responsibility of the product owner to prioritize the product backlog. The Product Backlog is an ordered list of the work to be done in order to create, maintain and sustain a product. During a Sprint planning meeting, backlog items are moved from the product backlog into a sprint, based on the product owner's priorities. In Scrum, a product backlog item ("PBI", "backlog item", or "item") is a unit of work small enough to be completed by a team in one Sprint iteration. Backlog items are decomposed into one or more tasks. In Scrum, a single person (Product Owner) must have final authority representing the customer's interest in backlog prioritization and requirements questions. This person must be available to the team, but especially during the sprint planning meeting and the sprint review meeting. Some challenges of a product owner include resisting the temptation to "manage" the team. The team may not self-organize in the way you would expect it to. This is especially challenging if some team members request your intervention with issues the team should sort out for itself. Resisting the temptation to add more important work after a Sprint is already in progress.
Being willing to make hard choices during the sprint planning meeting. Finally, balancing the interests of competing stakeholders.
Scrum Master Role is well defined. The Scrum Master is a facilitator for the team and product owner. Rather than manage the team, the ScrumMaster works to assist both the team and product owner in the following ways:
a) Remove the barriers between the development and the product owner so that the product owner directly drives development.
b) Teach the product owner how to maximize return on investment (ROI), and meet his/her objectives through Scrum.
c) Improve the lives of the development team by facilitating creativity and empowerment.
d) Improve the productivity of the development team in any way possible.
e) Improve practices and tools so that each increment of functionality is potentially shippable.
f) Keep information about the team's progress up to date and visible to all parties, cf., Schwaber (2004).
Sprint is an iteration of work during which an increment of product functionality is implemented. By the book, an iteration lasts 30 days. This is longer than in other agile methods to take into account the fact that a functional increment of the product must be produced each sprint. The sprint starts with a one-day sprint planning meeting. Many daily Scrum meetings occur during the sprint (one per day). At the end of the sprint, we have a sprint review meeting, followed by a sprint retrospective meeting. During the sprint, the team must not be interrupted with additional requests. Guaranteeing the team won't be interrupted allows it to make real commitments it can be expected to keep.
Sprint Backlog defines the work for a sprint. It is the set of tasks that must be completed to realize the sprint's goal(s) and selected set of product backlog items.
Sprint Goal is the result of a negotiation between the product owner and the development team. Meaningful goals are specific and measurable. Instead of "Improve scalability" try "Handle five times as many users as version 0.8." Scrum focuses on goals that result in a demonstrable product. The product owner is entitled to expect the demonstrable product (however small) starting with the very first Sprint. In iterative development, subsequent Sprints can increase the robustness or size of the feature set.
Sprint Planning Meeting is a negotiation between the team and the product owner about what the team will do during the next sprint. The product owner and all team members agree on a set of sprint goals, which is used to determine which product backlog items to commit from the uncommitted backlog to the sprint. Often new backlog items are defined during the meeting. This portion of the sprint planning meeting is time-boxed to four hours.
Sprint Retrospective Meetingis held at the end of every sprint after the sprint review meeting. The team and ScrumMaster meet to discuss what went well and what to improve in the next sprint. The product owner does not attend this meeting. The sprint retrospective should be time-boxed to three hours.
Stakeholder is person/ group or organization external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review.
User stories are one of the primary development artifacts for Scrum and Extreme Programming (XP) project teams. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. A User Story' is a unit of work that should be completed in one sprint. Smaller than that it's a task. A user story helps to create a simplified description of a requirement. In agile Scrum, a user story is a description of the objective, which helps a person to achieve a feature. For information on writing them see https://www.romanpichler.com/blog/10-tips-writing-good-user-stories/
The "The Official Scrum Guide" by Schwaber and Sutherland (2017) summarizes the fundamentals. The framework has few rules, but problems do arise. Common problems include: 1) too much reliance on Scrum software tools that often hinder team and client interactions; 2) lack of a full-time Scrum Master and/or lack of training and experience of the Scrum Master; 3) lack of a single, designated product owner; 4) poor team collaboration spaces; 5) poor coordination with other project teams and with a Project Management Office (PMO); and 6) lack of organizational commitment to Agile and Scrum processes and principles, cf., Eljay-Adobe (2018), Rubin, 2013.
References
Eljay-Adobe, "Scrum is Easy," DEV, September 12, 2017, updated on February 06, 2018 at URL https://dev.to/eljayadobe/scrum-is-easy.
Nicolaas, D., Scrum for Teams: A Guide by Practical Example, Business Expert Press, 2018.
Rubin, K. S., Essential Scrum: A practical guide to the most popular agile process, Boston: Addison-Wesley, 2013.
Schwaber, K. and J. Sutherland, "The Official Scrum Guide," Scrumguides.org, November 2017 at URL https://www.scrumguides.org/download.html
Schwaber, K., "SCRUM Development Process," at URL http://www.jeffsutherland.org/oopsla/schwapub.pdf
Schwaber, K., Agile Project Management with Scrum, Microsoft Press, 2004.
https://www.scrumalliance.org/community/articles/2007/march/glossary-of-scrum-terms
https://www.scrum.org/resources/scrum-glossary
Last update: 2020-02-06 03:20
Author: Daniel Power
Print this record
Show this as PDF file
You cannot comment on this entry
