Scrum is a lightweight framework that empowers teams and organisations to generate value through adaptive solutions for complex problems. Over my 12 years as a professional Scrum trainer, I’ve seen firsthand how this framework can transform the way we work. Today, I want to share an overview of Scrum, breaking down its core components: five values, three accountabilities, three artifacts, and five events.
The Foundation of Scrum: Empiricism
At the heart of Scrum lies empiricism, which is built on three pillars: transparency, inspection, and adaptation. Transparency is crucial; without it, we cannot effectively inspect or adapt. However, achieving transparency requires trust—a commodity that doesn’t just appear; it demands deliberate effort to cultivate and maintain.
The Five Scrum Values
The five values of Scrum—courage, focus, respect, openness, and commitment—serve as guiding principles for team decisions. They are essential for fostering the trust and empathy necessary for effective collaboration. Here’s how each value contributes to a successful Scrum environment:
- Courage: Encourages team members to take risks and voice their opinions.
- Focus: Helps the team concentrate on the work at hand.
- Respect: Builds a culture of appreciation for each member’s contributions.
- Openness: Promotes transparency in communication and processes.
- Commitment: Ensures that everyone is dedicated to achieving the team’s goals.
The Three Accountabilities
In Scrum, we have three key accountabilities that form the Scrum team. It’s important to note that these roles are not merely job titles; they represent the responsibilities that each member holds within the team.
Product Owner: Responsible for maximising the value of the work done by the Scrum team. This includes developing and communicating the product goal, managing the product backlog, and ensuring its visibility and clarity.
Developers: This term encompasses everyone involved in creating the product. Developers are accountable for delivering a usable working product and are responsible for planning, quality, and collaboration.
Scrum Master: The Scrum Master ensures the effectiveness of the Scrum team by providing support and fostering relationships among team members and stakeholders. They do not dictate tasks but instead facilitate the team’s processes.
The Three Artifacts
Artifacts in Scrum provide the transparency necessary for effective decision-making. Here are the three key artifacts:
Product Backlog: An ordered inventory of everything that needs to be done for the product to succeed. It should be manageable enough for the Product Owner to understand and articulate clearly.
Sprint Backlog: Contains the Sprint goal, selected backlog items, and an implementation plan. It reflects what the team is currently working on and adapts as needed throughout the Sprint.
Product Increment: Represents the sum of all completed work at the end of a Sprint. It must be usable and meet the definition of done, ensuring that it can be delivered to customers.
The Five Scrum Events
Scrum events are time-boxed activities that facilitate the empirical process. Here’s a brief overview of each:
Sprint Planning: The team inspects the product backlog and adapts the Sprint backlog to create a focused plan for the upcoming Sprint.
Daily Scrum: A daily meeting for developers to maintain transparency and plan their next steps towards achieving the Sprint goal.
Sprint Review: Near the end of the Sprint, the team presents their work to stakeholders for inspection and feedback, allowing for adjustments to the product backlog.
Sprint Retrospective: Following the Sprint Review, the team reflects on their processes and identifies ways to improve their effectiveness.
The Sprint: The fixed-length iteration that encompasses all other events, providing a rhythm for the team’s work.
Embracing Change in a Modern Context
Scrum has evolved over its 25 years, adapting to new technologies that allow for both synchronous and asynchronous collaboration. This flexibility is vital in today’s fast-paced environment, where teams may not always be physically together.
In conclusion, the Scrum framework is a structured yet flexible approach to managing complex projects. It provides the necessary support to maintain integrity while allowing teams the freedom to innovate and adapt. If you’re looking to implement or refine your Scrum practices, I encourage you to reach out for a consultation. Together, we can unlock the full potential of your team and drive meaningful results.
If you found this overview helpful, please consider liking and subscribing to my channel for more insights. Let’s continue to explore the world of Scrum together!
Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems. The Scrum framework is made up of five values, three accountabilities, three artifacts and five events.
In this video I’ll go through an overview of each one, explaining what they’re for and why they are there. Focus will be on the process itself and will leave any complementary practices until later.
My name is Martin Henchewitz. I’ve been a professional Scrum trainer for 12 years, professional Kanban trainer for two years and a Microsoft MVP in DevOps for 14 years.
Scrum is based on empiricism, the three pillars of which are transparency, inspection and adaption. Empiricism is impossible without transparency and in order to get transparency we need trust. Without it, we’d be unable to see what’s going on. Trust is not something that just happens; it needs considerable and deliberate effort to create and maintain.
Five Scrum values help guide and inform the team decisions and help support trust and empathy. These values are courage, focus, respect, openness and commitment. Their purpose is to help build and support the trust needed to maintain the transparency required to get the most effective teams.
The three accountabilities, although you may see these same names used as job titles, this was not the intent of the Scrum framework and as the result of 25 years of accumulated misunderstandings. There are three accountabilities in Scrum which together form the Scrum team. The Scrum team is entrusted by the organization to create value for each Sprint. They operate as a decentralized, collaborative and autonomous team that is responsible for stakeholder collaboration, verification, maintenance, operations, experimentation, research, development and anything else that might be required to create a successful product.
The accountability of the Scrum team is to effectively create a usable working product of the highest possible value. Let’s see how that breaks down.
The Product Owner is accountable for maximizing the value of the work done by the Scrum team. There are many activities that they might imply to help them maximize that value. For example, developing and explicitly communicating the product goal, creating and clearly communicating product backlog items, ordering product backlog items and ensuring that the product backlog is visible, transparent and understood.
While the Product Owner remains accountable, there is no requirement for them to physically do this work themselves. Delegating some or all of these activities enables the Product Owner to scale and to focus on the strategies they need to be successful.
Scrum developers are accountable for creating a usable working product. The term developers here includes everyone involved in developing the product. Those folks may have skills in analysis, user experience, coding, testing, legal, architecture, DevOps or whatever other skills are required. The developers take accountability for planning, quality and each other.
The Scrum Master is accountable for the effectiveness of the Scrum team. They do this by providing services to the developers, the Product Owner and the organization as a lean agile practitioner. They have deep knowledge of the technology required by the Scrum team to be successful. These technologies might include processes, practices, tools and techniques relevant to the context of the product under development. They foster relationships between developers, the Product Owner and the stakeholders to create an environment within which they can all be successful.
The Scrum Master does not write or order backlog items, administer Jira or tell the developers what to do. In addition to these three accountabilities, there are stakeholders. Stakeholder is a general term given to anyone outside of the Scrum team that has an interest in their work. While stakeholders do not have specific accountability, they are expected to be involved in the process by providing feedback and collaborating with the Scrum team as often as needed.
There are three artifacts in Scrum. Without being able to see what is going on, we can’t really make effective decisions and each of the artifacts exists to provide the transparency that is the foundation of any empirical system. To provide this transparency, there are three artifacts in Scrum.
First is the product backlog, the purpose of which is to provide transparency over what we need to do next. That is, it provides transparency of the future. The product backlog is an ordered inventory of things that we need to be true for the product to be successful. It should not contain more items than the Product Owner can easily understand and articulate, but enough to foster understanding and the success for the product. Too many items create too many assumptions.
The commitment to the product backlog is the product goal. The product goal reflects the desired outcome for the next few Sprints and informs but does not control the contents of the product backlog. While the product goal provides focus, it does not preclude incorporating feedback, features of opportunity or other things as needed.
Next is the Sprint backlog. The Sprint backlog contains three things: a Sprint goal, the work that the developers have selected for this Sprint and an implementation plan to help them get started. The purpose of the Sprint backlog is to provide transparency over what we are doing now, ergo transparency of the present. The commitment to the Sprint backlog is the Sprint goal, which informs but does not control the contents of the Sprint backlog.
During the Sprint, the contents will dynamically adapt to the changing needs of the Scrum team in the business while maintaining the focus of the Sprint goal. The Sprint goal is collaboratively created and owned by the Scrum team and reflects the why of the Sprint. While the Sprint goal may only reflect part of the Sprint backlog, attention is also given to augmenting existing functionality, refactoring and updating the product, dealing with technical atrophy and creating automation.
Lastly, we have the product increment, representing the entire product. It provides transparency over what we have done, i.e. transparency of the past. Each consecutive increment is a concrete step towards the product goal and must be usable. Usable is a combination of backlog items themselves and the quality measures that represent completeness. The formal description of those quality measures is the definition of done. The definition of done is the commitment to the product increment. It represents the minimum product and technical qualities that are required to be able to deliver your product to customers. It should mirror shippable.
There are five Scrum events that serve empiricism. Sprint planning, daily Scrum, Sprint review and Sprint retrospective are all time-boxed events. This means that you should spend enough time fulfilling the purpose of each event but not more than the maximum specified in the time box. Wrapping the entire Scrum process is the Sprint itself. The Sprint is our fixed length iteration within which all the other activities are completed and represents the cadence of adaptation between the Scrum team and the stakeholders.
While mentioned in the Scrum guide, product backlog refinement is not a specific event; it’s a term that represents all of the work done by the Scrum team on items in the product backlog rather than those selected for the current Sprint. All of the work to understand, evaluate, document and size things that may end up in future Sprints is regarded as refinement and every member of the Scrum team participates as needed.
It’s also important to note that Scrum is 25 years old and the technology available to us at the time necessitated a clear focus on people being physically together. Applying new technological advances to the context of Scrum allows teams to operate in both synchronous and asynchronous collaboration as needed while still fulfilling the intent of the Scrum values.
The first event in Scrum is Sprint planning. This event is where the Scrum team inspects the product backlog and adapts the Sprint backlog. Its purpose is to plan the Sprint. Focus for the upcoming Sprint is created with the Sprint goal that is formulated by the Scrum team. The developers then select items from the product backlog that best enable them to work towards this goal while considering the order of the product backlog and the needs of the product.
These choices may also trigger a change in the Sprint cup. Next, the developers create enough of an implementation plan to allow them to get started. Creating too much of an implementation plan would create excessive overhead for the Scrum team as new information is discovered. The output of Sprint planning is the Sprint backlog, which contains the Sprint goal, selected backlog items and enough implementation details to get started.
Next is the daily Scrum. The daily Scrum is a daily event by and for the developers where they maintain the transparency of the Sprint backlog based on what’s happened since the last one. The purpose of the daily Scrum is for the developers to plan what they are tactically doing next to achieve success in this Sprint. Based on the work that has been completed and new learnings uncovered since the last daily Scrum, we may need to adapt the contents of the Sprint backlog.
While this tactical plan may change, the Sprint goal remains constant and only the Product Owner can choose to abandon the current Sprint goal and the Sprint itself. The Sprint review occurs near the end of the Sprint. This event includes both the Scrum team and stakeholders and is where the work for the Scrum team is offered for inspection. The purpose of the Sprint review is to plan what’s next and maintain transparency of the product backlog.
In pursuit of this transparency of the future, we need to reconcile the impact of changes in the product, the business and the market since the last Sprint review on the product backlog and the product goal. This is a collaborative event where we physically update the product backlog to bring it in line with our current understanding of the future, maintaining its transparency.
Finally, we have the Sprint retrospective. It occurs immediately after the Sprint review and allows the Scrum team to inspect themselves and adapt their processes, practices, tools and relationships. The purpose of the Sprint retrospective is for the Scrum team to plan how they are going to increase their effectiveness. Finding ways for the Scrum team to be as effective as possible within the bounds of the organizational constraints is the responsibility of the entire Scrum team. Pushing the bounds of those organizational constraints is the accountability of the Scrum Master.
These four events wrapped in the Sprint form a set of concentric feedback loops that create an empirical process control system and allow the Scrum team to iteratively and incrementally create the best possible product within the current constraints.
So the Scrum framework is made up of five values, three artifacts, three accountabilities and five events. Nothing more, nothing less. The Scrum framework is like the timber frame for your house. It does not control the use that you put to each room, its decorations or its content. It does however give structure and support where needed to maintain its structural integrity. If you want to change the timber frame of your house, you can, but due consideration must be given to the impact on that integrity.
If you found this video useful, please like and subscribe to our channel to encourage us to make more. If you need help getting started or just tuning up your existing Scrum, please use the QR code here or the link below to book a free consultation.
