Scrum is a framework for solving complex adaptive problems with high levels of unknowns, uncertainties, or risks around what to build or how to build it. Scrum involves a cross-functional and self-managing Scrum team that uses empiricism to build products iteratively and incrementally to reduce risk and deliver early and often. The Scrum team uses the Scrum events to regularly inspect and adapt the 3 Scrum artifacts.
Scrum is founded on Lean thinking and empiricism. Lean thinking reduces waste and focuses on essentials. Empiricism asserts that knowledge comes from experiences. That is, do the work, see how it went, and then decide what to do next based on what was just learned. The 3 pillars of empiricism are transparency, inspection, and adaptation. Transparency into the work is necessary in order for the team to properly inspect the work and adapt accordingly. Regular timeouts are also necessary for the team to stop what they are doing, pause, look back at what just happened, and then decide how to move forward. In Scrum, the Product Increment provides transparency into what has been built so far. The Product Backlog provides transparency into what still needs to be built. The Sprint Backlog provides transparency into what is currently being built. The 4 events of Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective within the containing Sprint event provide the opportunity for the team to regularly inspect and adapt based on the transparency provided by the updated artifacts.
The events in Scrum are time-boxed. Once the end of the time-box is reached, the event ends and the team moves on (irrespective of whether the work to be done is completed or not). Based on the size of the Sprint, each event has a recommended maximum time limit. For a 1-week Sprint, Sprint Planning is timeboxed to 2 hours, Daily Scrum to 15 min/day, Sprint Review to 1 hour, and Sprint Retrospective to 45 min. The timebox limits increase proportionally for longer Sprints.
When the team has a short period of time to do something, the team prioritizes and figures out what’s most important to work on right now. The team breaks down large and complex work to fit in the timebox. The team focuses on finishing and delivering the work within the timebox. The team gets the opportunity to get feedback at the end of each timebox. With frequent feedback, the team adjusts and continuously improves to become more effective. These are all benefits of timeboxing.
Scrum is just a framework, which means it is purposely incomplete. It is not a prescriptive methodology with detailed instructions. Instead, it is just a lightweight guide that provides guard rails to keep teams heading in the right direction and prevents them from falling off. The Scrum rules, team structure, way of working, accountabilities, artifacts, and events, are set up to keep the team on track by regularly inspecting and adapting. If Scrum is only partially implemented, the guard rails might crack, and the team will not realize the benefits that Scrum delivers.
Based on a team’s context, organization, type of product being built, unique challenges, and their latest observations and learnings, a team may employ additional practices and techniques within the framework. What works for 1 team in 1 organization might not work for another team in another organization. It’s all contextual and there is no 1 best way of using Scrum. For those reasons, Scrum is said to be lightweight and simple to understand, yet difficult to master. Lightweight and simple to understand because the Scrum Guide is less than 20 pages and just lays out Scrum theory along with the Scrum accountabilities, artifacts, and events. It’s difficult to master because Scrum requires a change in how organizations and teams are traditionally structured and how they approach work, and many are resistant to change and find the necessary changes too disruptive. And that’s Scrum. A framework used for solving complex adaptive problems. There is no hiding in Scrum. A team has a short period of time to deliver value. If they can great! If they cannot, it will be obvious and transparent as to why. Scrum on its own, will not solve the team’s problems, but instead, Scrum shines a bright light on the team and organizational impediments. It’s up to the team and the organization to decide what to do about those impediments and how to address them for continued success.
Next check out the entire Scrum in a Nutshell series:
Scrum is a framework for developing, delivering, and sustaining complex products. It all starts out with our stakeholders, customers, and users that have an idea about a product they need and want developed. They collaborate directly with Developers to turn this idea into reality. Developers in Scrum are not just programmers. They are part of […]
In Scrum, there are 3 accountabilities, 3 artifacts, and 5 events. The 3 accountabilities in Scrum are: The 3 artifacts in Scrum are: The 5 events in Scrum are: And that’s the Scrum Framework as defined by
The Scrum team consists of 3 accountabilities, Developers, Product Owner, and Scrum Master. Developers are accountable for building and delivering a quality working Product Increment at the end of each Sprint. They are a small group, typically 3 to 9 members that are cross-functional and self-organizing. Developers are cross-functional to remove bottlenecks and dependencies. Developers […]
The Product Backlog is an ordered list of hypotheses, requirements, features, enhancements, or Product Backlog Items that help the team accomplish the Product Goal. The Product Backlog is the team’s single source of work. Meaning, anything the Developers are working on should be coming from the Product Backlog. There are no side requests. Any work […]
In Scrum, the Sprint starts with Sprint Planning where the Scrum team plans out their work for the Sprint and creates a Sprint Backlog. The Sprint Backlog is the team’s plan to accomplish the work. Sprint planning is timeboxed to 2 hours per week of Sprint, so for a 2-week Sprint it is one event […]
The Daily Scrum is a brief daily planning event by the Developers to inspect their work and the progress they are making toward the Sprint Goal that will result in a Product Increment. The Developers created their Sprint plan or Sprint Backlog in Sprint Planning at the beginning of the Sprint. However, this plan is […]
The Sprint Review is a working session for the stakeholders, users, and customers to collaborate with the Scrum team which includes the Developers, Product Owner, and Scrum Master, and inspect the progress made toward the Product Goal based on the latest Product Increment. The Sprint Review is about getting feedback from the stakeholders and users […]
The Sprint Retrospective is a reflection event that occurs at the end of each Sprint. It is for the entire Scrum team which includes the Product Owner, Developers, and ScrumMaster to inspect how they are operating and then come up with a continuous improvement plan to adapt and become more effective as a team and […]
The Product Increment is the output of every Sprint and is an increment that brings the team one step closer to the overall Product Goal. This means that each Sprint is focused on a cohesive set of Product Backlog Items that meet a Sprint Goal and not random unrelated items. Once a Sprint starts and […]
For teams to succeed with Scrum, team members must become proficient in living the 5 Scrum values of commitment, focus, openness, respect, and courage. Commitment: In Scrum, the team commits to each other, not to other people, but to each other, on supporting each other to deliver on the Sprint Goal and Product Goal. Focus: […]
Scrum is a framework for solving complex adaptive problems with high levels of unknowns, uncertainties, or risks around what to build or how to build it. Scrum involves a cross-functional and self-managing Scrum team that uses empiricism to build products iteratively and incrementally to reduce risk and deliver early and often. The Scrum team uses […]
Back in February 2001, at the lodge in Snowbird Utah, 17 thought leaders from the software industry got together to discuss the state of software development and compare various lightweight frameworks that popped up in the late 90s because of dissatisfaction with the traditional waterfall approach to building products. The participants shared and learned about […]