Agile in practice #3 - What is Scrum in Agile development?
Scrum is a software development framework based on Agile. But it’s so much more than that. In this article, we will talk about Scrum in detail: its principles and core elements. Read on further to learn about Scrum’s terminology and find out how teams organize their work.
Table of contents
What is Scrum in Agile development?
Scrum is one of the leading Agile frameworks in which a product is developed in short cycles, called sprints. During each sprint, which can last up to four weeks, the entire team is working towards a specific goal. They do so with the help of a Scrum master - a servant leader role responsible for the effectiveness of the team. It’s the Scrum master’s job to ensure that Scrum is being applied in accordance with the Scrum Guide (source).
Scrum has a set of values that define the spirit of Scrum Agile development. These values are Courage, Focus, Commitment, Respect, and Openness, as defined in the Scrum Guide (source). But how do they affect the way the work gets done?
The three pillars of Scrum in Agile development: Transparency, Inspection, and Adaptation
Scrum values are not something to just keep in mind. When the team truly embraces them, their work begins to unfold in the spirit of Transparency, Inspection, and Adaptation. These are known as Scrum pillars. Scrum values and Scrum pillars are interconnected, as specified in the Scrum Guide:
When the values of commitment, courage, focus, openness, and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.
A transparent team is one that clearly communicates its actions, be it achievements or mistakes. Every stage of the development process is reviewed and inspected - because without a clear measurement of progress, how can the team know if they are doing well? Adaptation is a natural progression of the previous two pillars: an ability to adapt to unexpected changes whenever there is a risk of not completing the goals of a current sprint (source).
Core elements of Scrum: artifacts, roles, and events
In order to understand how to use Scrum in Agile development, it’s important to learn about its core elements first. While everyone is free to combine Scrum with the tools and methods of their choice, there are concepts that are universal. They relate to three things: roles, events, and artifacts.
The Scrum artifacts
Scrum artifacts are pieces of information that are used to describe and communicate the state of product development. They can describe the goals of each sprint, define what the finished product should look like, or track the progress of development (source). Below, we will explain what each artifact is.
Product Backlog
In the simplest terms, a product backlog is a list of things that need to be done. Responsibility for this artifact falls to the Product Owner. A product backlog exists as long as the product does, therefore it can include bugs that need fixing in future iterations. The order of completion of backlog items is decided by their priority. Items with higher priority are taken care of first.
But, when working in Scrum in Agile development one must be realistic about what can and cannot be done. Before an item from the product backlog is added to a sprint backlog the team needs to discuss if it can be completed within a single development sprint. In case of a lengthy task or a complicated feature, it’s good practice to break them down into smaller pieces. These pieces can be then added to the sprint backlog.
Sprint backlog
Similar to the product backlog, a sprint backlog is a list of things to be done in the current sprint. A sprint backlog can be broken down into smaller pieces:
- sprint goal,
- items selected for the current sprint,
- the plan for delivering the increment.
These three elements make up the why, what and how of each sprint. While sprint goals define what the team is looking to complete in a sprint, the remaining two deal with how it is going to happen. Sprint backlogs are made by and for developers and are prone to change as the sprint goes on.
Coming back to one of the pillars of Scrum: transparency - the sprint backlog is the embodiment of this pillar. Before each sprint, team members must describe which features of the product they are going to focus on in the coming weeks. As the sprint goes on, every team member can then clearly see what it is that they are trying to collectively achieve. The result of each sprint is called an increment.
Increment
An increment describes all the work done during a sprint, be it a current or previous one. Increments are essentially backlog items that were completed and are aligned with the definition of done.
Definition of done
When working on a digital product, how do you know when it’s done? Each sprint is meant to end with a working iteration of a product. As such, the definition of done is a set of conditions that need to be met in order to consider the task complete.
Types of events in Scrum Agile development
In Scrum, meetings are called events. During these events, the development team gets to plan, execute and review their work. Each event has its specific name and function.
Sprint
A unit, a single cycle of product development. A single sprint can last up to four weeks. During that time, the team gets the chance to plan, implement and review their work. Each sprint has a definite goal and should end up producing a working iteration of the product.
Sprint review
This is an event where the team gets to summarize what they accomplished during the sprint and share what they have learned about the product and its development along the way. This could inspire a discussion about the future of the product. As a result, the team might decide to make some changes to the product backlog.
Sprint retrospective
The Scrum retrospective event is often referred to as a “retro”. It’s when the team looks back on the past sprint and tries to determine what went well and what could have gone better. This could apply to any element of the process: from the technology to particular team members. The idea of a retro is to learn from the collective experience and improve the team’s performance. The Scrum retrospective is the last event of a sprint. If there’s a need for another event it’s likely to be planning the next sprint.
Sprint planning
During sprint planning, the team discusses the items that are left in the product backlog. Selected items are moved to the next sprint backlog. Then, the team can start working on a plan to deliver them.
Daily meetings, aka daily Scrum
Just as the name suggests: during the sprint, the developers get to meet every day and discuss their sprint goal - if it’s achievable and what actions are they looking to take to get closer to completing it. Daily meetings also offer a space where everyone can freely share what it is that they have been working on and what they are going to focus on for the rest of the day. While it might sound like a way to keep tabs on the team, the goal of these daily meetings is to let other team members know what is currently happening with the sprint goals and how each team member is going to contribute to achieving those sprint goals.
Scrum roles and how they fit with Agile development
Scrum is only as effective as the people who use it. Below you will find more about roles in every Scrum team: product owner, developers and Scrum master.
Product Owner
The product owner is the person responsible for what is happening with the product and why it is happening. In the world of software houses, a product owner could be a person from the client’s side. Normally, a product owner should attend sprint planning, reviews, and retrospectives. They share their vision for the product and work closely with the Scrum team. This could take many forms, such as:
- taking care of transparency and the clarity of backlog items,
- defining the product goal,
- presenting the results of the sprint to the client,
- deciding on the priority of backlog items,
- managing stakeholders.
The product owner is responsible for these things, but it doesn’t mean that they need to do them themselves. This is particularly true in organizations where a single person acts as a product owner for multiple projects.
Developers - the driving force of every project
In Scrum, the developer’s job goes far beyond writing code. They are the ones that create the plan for each sprint. They deliver the product while keeping in mind the definition of done and the current sprint goals. Also, it’s up to every member of the developer team to keep each other accountable for the quality of their work.
Scrum master
The Scrum master is the servant leader of the Scrum team. Their job is to make sure that Scrum is implemented the right way and that the team understands it. A Scrum master works on three levels: Product owner, team, and organization. While the list of what a Scrum master does is long, the key responsibilities are:
- helping the product owner with the product backlog,
- helping developers self-organize and focus on the priorities,
- leading their organization and the team in implementing Scrum,
- taking care of the process,
- facilitating Scrum meetings (if necessary).
And that’s only the tip of the iceberg. The long list of their responsibilities comes with even greater accountability - Scrum masters are the ones answerable for the team’s effectiveness.
Scrum in Agile development - afterword
While this might seem like a lot of information to take in, everything becomes clear once Scrum is fully implemented. Strange job titles will become people with names and faces and every Scrum event will feel like another opportunity to meet them.
Scrum follows the principle of all or nothing. An organization that decides to use Scrum has to implement every single element that this framework offers. At the same time, they are free to use the tools and methods of their choice, thus it is entirely possible for two organizations to implement Scrum properly, but each in their own way. And what way will that be for your organization?
Share this article:
