Speak to an Advisor
AU
EU
IE
UAE
UK
USA
SA
SG
Scrum is a framework that helps teams work together by encouraging them to learn through experiences, self-organise while working on a problem, and reflect on their results so they can improve. Scrum is a very useful Agile framework and is often even referred to as scrum methodology, even though it is not a methodology. A methodology is a way to systematically solve a problem but a framework is a structured approach to problem-solving. In this ultimate guide to Scrum framework, we explain the main features of this approach, helping you understand it better.
Scrum is often introduced with various different adjectives - some describe it as theory others as a philosophy or a structure they use to reach their goals, some call it Scrum methodology... but in a nutshell, it can be described as an Agile framework that helps people, teams and organisations generate value through adaptive solutions for complex problems. This framework is purposefully incomplete as it just provides people with guidance rather than strict and detailed instructions.
In a nutshell, Scrum process happens in three steps -
And then the process is repeated.
Scrum is based on a 1986 paper written by Hirotaka Takeuchi and Ikujiro Nonaka for the Harvard Business Review titled “The New New Product Development Game.” That paper described the benefits of self-organising teams in innovative product development and delivery but through a metaphor of rugby. Jeff Sutherland, Ken Schwaber, and Mike Beedle later applied those ideas to the field of software development and created a new method - Scrum. Scrum 'methodology' got its name after the rugby term, continuing with the use of the original metaphor. This method was first introduced in the early nineties.
Scrum implements empiricism - a scientific method that asserts that knowledge comes from experience and makes decisions based on what is observed. It is also founded on lean thinking; it tries to reduce waste and focus on the essentials. Scrum replaces a programmed algorithmic approach with a heuristic one, with respect for people and self-organisation to deal with unpredictability and solving complex problems. The key for this to work is in organised scrum roles and time-boxed events.
The scrum team consists of three roles: a scrum master, a product owner, and developers or development teams. There are no sub-groups or hierarchies within a scrum team, it is just a cohesive unit that is responsible for all product-related activities, such as stakeholder collaboration, maintenance, operation, experimentation, research and development, and anything else that might be required. They internally decide who does what, when, and how. The team is both small enough to remain productive and have good communication and also large enough to complete all necessary work - it is usually around 10 people.
The scrum master is accountable for establishing Scrum by helping everyone understand and practice it. The scrum master is the facilitator of the scrum development process. In the context of the scrum team, the scrum master is essentially a leader who coaches the team to be self-managable and cross-functional. There are different roles scrum master has because a scrum master serves the scrum team and product owner, as well as the organisation itself. If you wish to become a Scrum master yourself, take a look at the Institute's IPM Scrum course.
The product owner is accountable for maximizing the value of the product resulting from the work of the development team. He or she is accountable for effective product backlog and they may represent the needs of many stakeholders in the product backlog. So any changes to it are done by them and in order for something to be changed, the product owner needs to approve it and do so. Their decision must be respected by the whole organisation.
Developers are the people in the scrum team that are committed to creating any aspect of a usable increment for each sprint. The skills development team needs depend on the domain of work, however, the rest of their roles during a sprint are always the same. The development team is accountable for creating the sprint backlog, establishing quality by adhering to the definition of done; adapting their plan each day toward the goal and holding each other accountable.
The sprint is the main event that contains all other events, each of which is an opportunity to inspect and adapt scrum artifacts. They are designed to enable transparency and create regularity. Optimally, all events are held at the same time and place to reduce complexity. All of the events are time-boxed and the length depends on the complexity of a sprint. Here are all the key scrum events:
The sprint is the foundation of Scrum. It is a fixed-length event used to create consistency. They are always interconnected as a new sprint starts immediately after the previous one was concluded. All the work necessary to achieve the product goals is done within sprints.
The purpose of sprints is to enable predictability by ensuring inspection and adaptation of progress toward a goal. During a sprint, the product backlog is refined as needed and the scope might be clarified and renegotiated with the product owner but there are no changes made that would endanger the sprint goal. Each sprint may be considered a short project as it is better to use shorter sprints to limit the risk of cost and effort. In case the sprint goal becomes outdated, the sprint can be cancelled but only by the person with the authority to do so - by a product owner.
Sprint planning initiates the sprint by laying out the work to be performed for the sprint. It is done by the entire team. During the sprint planning meeting, there is a discussion about the most important product backlog items and how they map to the product goal. Some of the topics covered during the sprint planning meeting include discussions of the sprint's value, what work can be done during the sprint and how it will be done.
The purpose of the daily scrum is to inspect progress toward the sprint goal and adapt the sprint backlog as necessary, adjusting the upcoming planned work. It is a 15-minute event held at the same time everyday for development team. Sometimes, if the product owner or scrum master are actively working on items in the backlog, they also participate. Using daily scrum meetings creates focus and improves the self-management of the team.
The purpose of sprint review is to inspect the outcome of the sprint and to determine future adaptations. During the sprint review, the scrum team presents their work to key stakeholders and then they review the progress towards the goal together. They discuss what was accomplished during the sprint and what has changed in their environment. Then the next step is decided and, if needed, the product backlog is adjusted.
The purpose of the sprint retrospective is to plan ways to increase quality and effectiveness. The team discusses both what went well and what didn't and inspect what problems occurred and how they were solved, or if not- how they should be. By identifying the most helpful changes, the scrum team improves its effectiveness. The sprint retrospective concludes the sprint.
Scrum artifacts represent work or value. They are designed to maximize the visibility of key information so that everyone inspecting them has the same basis for adaptation. Each artifact contains a commitment. Its purpose is to provide information that can enhance transparency and focus against which the progress can be measured. That way, the commitments also reinforce empiricism and scrum values.
The product backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the scrum team. Product backlog items that can be done by the development team in one sprint are selected for the next sprint planning. Before acquiring this level of visibility, the product backlog is refined by being broken down and items are further defined into smaller and more precise ones. In this step details like description, order and size are determined - although characteristics of items often depend on the domain of work. Thinking of the details is the task for the development team but the product owner is there to help them understand and select trade-offs. The product owner is also accountable for other product backlog-related activities such as developing and clearly communicating the items and goal, ordering the items and ensuring that the product backlog is visible and understood.
The main commitment for product backlog is the product goal. The product goal describes a future state of the product which can serve as a target for the team to plan against. It is contained in the product backlog, as the product backlog defines “what” will fulfill the product goal. It is a long-term objective for the team and they must fulfil it or sometimes, abandon it before taking on the next.
The Sprint Backlog explains scrum process by answering three questions - why, what and how. It is composed of the sprint goal (answering why), the set of product backlog items selected for the sprint (answering what), as well as an actionable plan for delivering the increment (answering how).
It is a plan made by developers, for developers. It describes what they plan to accomplish during the sprint to be able to achieve the goal. It is updated throughout the sprint and should contain enough details that the development team can inspect their progress in the daily scrum.
The main commitment for sprint backlog is the sprint goal. The sprint goal is the single objective of that sprint. It is created during the sprint planning event, after which it is added to the backlog. The goal is what the development team works towards. However, if the work turns out different from what was expected the development team then negotiates with the product owner about the scope of the backlog within the sprint but without it affecting the goal.
An Increment is what gets produced at the end of a development period. It is a step towards the product goal and each one of the increments have to work together. There can be multiple increments within a sprint. They can be delivered to stakeholders at any time, even prior to the end of the sprint. But usually, the sum of the increments is presented at the sprint review before that.
The main commitment for an increment is the definition of done. Work cannot be considered part of an increment unless it meets the definition of done. The definition of done is a formal description of the state of the increment when it meets the quality measures required for the product. An increment is created the moment a product backlog item meets the definition of done.
The development team is required to conform to the definition of done. Especially if there is more than one scrum team working on a product, they must mutually define it so that it can create transparency by providing everyone with a shared understanding of what work was completed as part of the increment. In case it does not meet the definition of done, the item can't be presented at the sprint review and should be returned to the backlog to be reconsidered.
Scrum has an iterative, incremental approach to optimise predictability and to control risk. Scrum methodology, or rather an Agile approach, combines four events used for inspection and adaptation within a containing event, the sprint. These events work because they implement the empirical scrum pillars:
1. Transparency - Process and work must be visible to not only those who are performing the work but also to those who are receiving it because artifacts that have low visibility can lead to decisions that decrease value and increase risk. It is necessary for inspection because otherwise, an inspection is misleading.
2. Inspection - The artifacts and the progress toward agreed goals must be inspected often and thoroughly in order to detect potential problems. To do this, the five events are used. After the inspection has been done, adaption can follow. There is no point in doing adaptation without inspection because the events are designed to provoke change.
3. Adaptation - Adaptation is needed in case there are any aspects of a process that deviate outside of acceptable limits or if the result itself is unacceptable. The adjustment of process or materials must be made as soon as possible to minimize further deviation.
Successful use of Scrum depends on people following these five values:
1. Commitment of the team towards achieving the goals and supporting one another
2. Focus on the work in each sprint
3. Openness of the team and stakeholders about the work and the challenges
4. Respect the team has for its members and considers them to capable and independent people
5. Courage to work on tough problems and do the right thing
These values give direction for decision-making, steps the team needs to take and general actions and behaviours that should reinforce these values, not undermine them.
Scrum principles are the foundation on which this framework is based. They are applicable to any type of project or organisation and can be modified to meet the requirements of the project or an organisation using it but they are non-negotiable because scrum principles are considered core guidelines for proper application of the scrum framework. These are the six principles of scrum:
1. Control over the empirical process - In Scrum 'methodology', decisions are made based on observation and experimentation rather than on detailed upfront planning. This is called the empirical process. It relies on the three pillers of Scrum.
2. Self-organisation - Scrum believes that employees are self-motivated and seek to accept greater responsibility. They deliver much greater value when self-organising which results in an innovative and creative environment - much more conducive for growth.
3. Collaboration - Collaboration is needed for product development. By having interaction with stakeholders, development team can deliver the best product. This principle focuses on the three core dimensions of collaborative work: awareness, articulation, and appropriation.
4. Value-based prioritization - The fourth principle of Scrum highlights the framework’s drive to deliver maximum business value in a minimum time span. This principle drives the structure and functionality of the entire framework. While prioritising, there are three factors that need to be considered- value, risk and dependencies.
5. Time-boxing - The concept of "time-boxing" was introduced because Scrum treats time as a limiting constraint. Fixing a certain amount of time for each process and activity in a project ensured that the development process is more efficient. The duration of events is time-boxed.
6. Iterative development - Iterative development helps to better manage changes and build products that satisfy customer needs. The iterative model allows enough flexibility to ensure that any requested change can be included as part of the project. User Stories may have to be written constantly throughout the duration of the project.
Both Agile and it's framework, Scrum, rely on an iterative process, frequent client interaction, and collaborative decision making. The key difference between them is
So, other than this one, there are also other differences between Agile and Scrum, such as:
Just like any other framework, Scrum also has a few disadvantages. Because of that Scrum is sometimes combined with other management techniques that can help resolve some of these drawbacks. But even with its disadvantages, Scrum has many benefits because Scrum is a framework that employs various processes, techniques and methods from already existing practices.
Explore our Courses
Upcoming Course Dates
Corporate Training
Partnership
Certification Overview
IPM Certification
IPMA Certification
PMI Certification
PRINCE2® Certification
IPM Membership
Events
Mentorship
Articles
Expert Insights
Ebooks & Toolkits
Publish Your Writing
The Institute
Faculty
Global Advisory Board
Apply to Lecture or Volunteer
Apply to Intern or Campus Ambassador
