Learn About Scrum
Scrum is an Agile approach to managing work, designed to help teams manage complex projects through an iterative, incremental and collaborative approach.
Originally created for software development, Scrum is now widely used across industries, from marketing and education to manufacturing and research. Using Scrum, teams face rapidly changing requirements and high uncertainty with a measured and empirical approach to continually deliver value.
There are 4 Agile Values and 12 Agile Principles. The 4 Agile Values come straight out of the text of the "Manifesto for Agile Software Development".
The Agile Values help us understand the importance of placing ...
-
People and our Relationships with them higher than the Processes and Tools we use;
-
functioning Products higher than Comprehensive Documentation that is seldom used;
-
Customer Collaboration higher than reliance on a strict Contract to guide us;
-
Response to Change higher than committing to a Plan.
The Agile Principles help us understand better ways to achieve these Values. The Agile Principles focus on Customers, Communication & Collaboration, converting Management to Leadership, how to create Self-Organizing Teams, and creating a sustainable Process.
Agile Values and Principles
Respect
Openness
Courage
Commitment
Focus
Scrum Values
In Scrum, we have a little rule that helps us get work to 'Done': When we take on a unit of work, we agree to only work on that one thing until it is 100% done. No multi-tasking.
Scrum teams are committed to reaching the current Sprint Goal together, and to help each other when anyone on the team needs help.
We must treat everyone equally, or nothing will succeed on a Scrum Team. No superstars, no titles, no pedestals.
We have the courage to talk about the difficult subjects. Addressing problems takes courage.
If we do not have open communication, we can't solve our problems.
Scrum Roles
Roles Vs Accountabilies
Technically, as of November 2020, the Scrum Roles are now 'Accountabilities'. Arguing the difference is about as fruitless as trying to explain to your cat why it shouldn't sit on your keyboard. There are accountabilities for each role on the Scrum Team, let's go over them at a high level.
Product Owner
Product Owners OWN the product. This means that they own the responsibility of making all of the big decisions about the product's future. They manage the Product Backlog (all of the currently known work for the product). They are responsible for making that work transparent, clear, and concise. Product Owners need to collaborate with stakeholders, and Developers, DAILY!
Developers
Too often when people see the term 'Developers', they think 'software engineers', 'programmers', or 'coders'. This is not the case. 'Developer' is short for 'Product Developer'. This means we call everyone who has a skill that we need to create the product is a potential Developer. Developers must be 100% dedicated to ONLY the Scrum Team, though. So anyone on several projects is OUT! Developers get to decide how the product is built. Not the 'what', but the 'how'. No one is allowed to tell Developers how to do their work - not even other Developers. They mutually decide how the work will be done, and then self-organize around doing it.
Scrum Master
While the Product Owner has authority over the product, the Developers have authority over the building of the product...Scrum Masters have no authority. Scrum Masters have an obligation to look out for the best interests of the team, the product, the organization, etc. Scrum Masters are supposed to be the most educated on how things run efficiently, and then coach the team to achieve that efficiency. At no point does this description say that the Scrum Master manages the work, the people, the process, or anything. Scrum Masters are not managers. Scrum Masters have 3 main services they provide (most Scrum Masters aren't even aware of this):
1st Service: Coach the Product Owner into understanding the extent of their role, and how to perform the techniques of the job.
2nd Service: Continually coach the entire Scrum Team into greater self-organization.
3rd Service: Coach the entire organization into becoming more Agile, and where Scrum is being used, help those teams using it.
There are three artifacts in Scrum. Each one is a representation of work, in one state or another.
Product Backlog
The Product Backlog is a representation of all of the currently known work for the product. But it is a list of work that we could possibly engage in in the future. This is not work we are doing right now.
Sprint Backlog
The Sprint Backlog is a representation of the work that we are currently focused on. It is the list of work we've selected for this Sprint.
Increment
In Scrum, the Increment can mean several things. When speaking of the Scrum Artifact called the Increment, 'Increment' means the representation of all work the Scrum team has produced for the product. It is the sum total of all work that has ever been done.
Scrum Artifacts
There are five events in Scrum. There are four 'formal' events and a container event. Please do not refer to these as 'ceremonies' - this is not a religion.
The Sprint
The Sprint itself is a container for most of the other elements in Scrum. It contains the Sprint Goal, Sprint Planning, Sprint Backlog, the Daily Scrums, the Increment (for that Sprint), Sprint Review and Sprint Retrospective. The Sprint is the one event in Scrum that is not considered a 'formal' event, because no one meets at a designated time and place to 'do' it. The Sprint is a fixed timebox in which a Scrum Team runs through their Scrum-based process one time. That's it. It's not a deadline for getting work done.
Sprint Planning
Sprint Planning kicks off a Sprint. As soon as Sprint Planning starts, the Sprint starts. The three parts of Sprint planning are designed to give Scrum Teams a good enough plan to get started with the work of the Sprint. We understand, through the Agile Values, that no plan is perfect. So, we want a 'good enough' plan - not a perfect one. The three parts of Sprint Planning consist of defining a Sprint Goal, Defining what Product Backlog Items will help meet that goal, and how the Developers plan to get the work done, step-by-step.
Daily Scrum
Most Scrum Teams are doing this incorrectly. It's a good thing that success for a Scrum Team does not hinge on the team doing the Daily Scrum right! Very often we see Scrum Masters quizzing all of the Developers on what they did the day prior, what are they going to do today, and what, if any, impediments do they have. That is a status meeting! Daily Scrums are supposed to be the 'anti-status meeting'. The perfect Daily Scrum is defined as follows: "The Daily Scrum is a daily planning meeting for Developers, by Developers, to plan out who is going to work with whom, on what, to get the team one day closer to the Sprint Goal."
Sprint Review
The Sprint Review is an opportunity for stakeholders to receive a demonstration of the work completed during the Sprint, and to give actionable feedback to the Scrum Team on going forward developing the product. Important note: the Product Owner is not a stakeholder - they are a Scrum Team member. This is a collaborative session where the team and the stakeholders decide what are the upcoming important things to focus on, and if the team has gone in the wrong direction, this is a good time to correct their course.
Sprint Retrospective
The Sprint Retrospective is a private, closed-door, meeting for the Scrum Team to decide what needs to be improved and how to improve it. This is not a complaint session, this is a continual improvement session. The Product Owner absolutely needs to be in attendance - they are part of the team. A real Retrospective is not complete without a step-by-step plan (called a Continual Improvement Item) for improving at least one thing the team is experiencing.
Product Backlog Refinement (not an event!)
Product Backlog Refinement (PBR) is a continual activity (not an event) that the entire Scrum Team engages in to gain transparency on lesser understood Product Backlog items. Generally, you might take a large item on the Product Backlog (like an epic), the Product Owner will describe all of the details they know about the item. The Developers will ask clarifying questions, and the team will use that information, or lack thereof, to decompose that work for that item into many much smaller items (maybe called User Stories). These new, smaller items would then need to be estimated by the Developers, based on the understood effort needed to complete the work items. There are many other things teams can do while engaging in PBR, but those are the basics.
Events
Scrum isn’t just a framework ... it’s a game-changer for how teams plan, build, and deliver. By breaking complex work into short, focused Sprints, Scrum helps teams deliver value sooner, adapt faster to change, and stay aligned with real customer needs. Transparency is built into every step, so everyone, from stakeholders to developers, always knows where things stand.
The result: Faster delivery, happier customers, and more motivated teams who actually enjoy working together.
Scrum transforms busy groups into high-performing teams that continuously learn, improve, and deliver meaningful results.
Benefits
A successful Scrum adoption doesn’t happen by accident. It begins with well-trained leaders who understand how to set their teams up for success. The Scrum Master and Product Owner play critical roles in shaping how Scrum works within an organization, and high-quality training from a Certified Scrum Trainer (CST) makes all the difference.
In my Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) classes, leaders learn not only the mechanics of Scrum but also the mindset behind it. They explore how to create clarity, enable collaboration, and foster continuous improvement. Participants discover why crafting a strong Definition of Done takes time and thoughtful iteration, and why that work should begin before the first Sprint ever starts.
Likewise, a well-prepared Product Owner sets the foundation for success by establishing a compelling Product Vision, defining at least one desirable Product Goal, and mapping out a customer journey or feature roadmap. From there, they can refine that roadmap into high-value Sprint Goals that guide the team’s early progress.
All of this preparation leads to focused, high-performing Scrum teams ready to deliver real value from day one.