What Is the Scrum Methodology? All the Basics You Must Know
Confused by all the various terms in Scrum? This list will help you make sense of it all.
Join the DZone community and get the full member experience.Join For Free
Non-developers commonly think of software developers as solitary creatures — toiling in their cubicle, corner office, or favorite coffee shop for hours on end, tap-tap-tapping away without any human interaction, writing in a cryptic language only the initiated can understand.
While the cryptic language part is true, the rest actually isn’t.
This is largely to do with the rise of the Agile framework, which makes rapid and constantly evolving software development possible because it prioritizes the team over the individual.
And the Scrum methodology is how agile companies actually enable their teams.
What is the Scrum Methodology?
The Scrum method or Scrum framework, as it’s commonly known, gets its name from rugby.
This comparison was first put forward by Hirotaka Takeuchi and Ikujiro Nonaka in their well-known article for the Harvard Business Review, “The New New Product Development Game, in which they argue that a “holistic” or “rugby” approach, where a team tries to go the distance as a unit, passing the ball back and forth, may better serve today’s competitive requirements.
Under the rugby approach, the product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish. Rather than moving in defined, highly structured stages, the process is born out of the team members’ interplay.
In other words, Scrum is about continuous improvement, constant teamwork, and collaboration, as well as a high degree of flexibility.
With that in mind, you may still be wondering:
Agile and Scrum: What’s the Difference?
To properly define Scrum, it’s important to look at the ways in which it differs from Agile, the philosophy that gave birth to Scrum.
While Agile is a philosophy, a set of principles, a way to think about software development that guides behavior without telling you what to do, Scrum is a framework for putting Agile’s philosophy into practice. It helps teams start building Agile principles into their workflow.
Scrum is heuristic, meaning that it encompasses “any approach to problem-solving or self-discovery that employs a practical method, not guaranteed to be optimal, perfect, logical, or rational, but instead sufficient for reaching an immediate goal.”
Scrum recognizes that you don’t know everything at the start of the project. But over time, your work will evolve and improve as the team makes discoveries and changes based on their experiences, naturally adapting to the conditions and requirements of their particular project.
As you’ll see later, Scrum is built on short release cycles, quick iterations, and constant re-prioritization. It’s structured, but not rigid. And it can be tailored to the needs of any organization, project, or team.
There are, however, specific tools and processes built into the basic version of Scrum that you will undoubtedly have to use to make Scrum work.
What Are the Scrum Artifacts?
Scrum artifacts are the key constants in any application of the methodology. They’re tools for solving software development problems.
The 3 artifacts of Scrum are:
- product backlog,
- sprint backlog,
- and increment or sprint goal.
Let’s dive into each below.
The product backlog is generally maintained by the product owner or manager and includes a list of all the work needed to be completed.
It will have:
- and fixes.
Like everything else in Scrum, the backlog will be revisited, reworked, and reprioritized. And there are many reasons for this. The market changes, features are no longer relevant, problems are solved in unexpected ways, and so on.
The sprint backlog is a selection of items, user stories, bug fixes, and other relevant information that the development team has decided to implement for their current sprint cycle.
Before a sprint cycle is initiated, teams hold sprint planning meetings. This is when developers pluck out the necessary elements from the product backlog to include in the sprint backlog.
Of course, a sprint backlog can also change during a sprint, but the goal of each sprint should never be compromised. Changes made should only ever increase the speed of progress toward the goal.
Increment (Sprint Goal)
The increment, or sprint goal, is the end-product of a sprint. It’s also your team’s definition of “done.”
Some teams choose to hold an end-of-sprint demo where they demonstrate the increment achieved. Other teams prefer to release something to their customers at the end of every sprint, in which case, their definition of “done” would be “shipped,” meaning given to the customer.
Of course, on exceptionally large projects, developers can’t ship too often, maybe once a quarter. In that case, the team may decide that they can ship increments bundled together instead of each increment on its own.
And oftentimes, teams need to redefine their definition of “done” in the middle of sprints. Obviously, there is a lot of variety within artifacts as with the rest of Scrum. That’s why to implement Scrum properly, you have to constantly remain open to evolving even these most fundamental aspects of the methodology.
Let’s move on to the activities Scrum teams engage in throughout their work.
What Are the Scrum Roles?
Every Scrum team has three specific roles:
- product owner,
- Scrum Master,
- and development team.
Let’s quickly cover each.
The Scrum Product Owner
The product owner is the expert on the business, the customers, the market requirements, and the priorities for the work to be completed.
The Scrum Master
The Scrum Master coaches teams, product owners, and the business on the Scrum process and looks for ways to improve it.
The Scrum Development Team
The Scrum development team plans and initiates the Scrum sprints and effectively completes the software project.
What Are the Scrum Ceremonies and Events?
Like other methods, Scrum has its own ceremonies and events to keep your team on track.
They’re specifically designed to help you kickstart the Scrum process and get you into the habit of using its tools and workflows.
The Scrum events and ceremonies are:
- backlog grooming,
- sprint planning,
- daily Scrum,
- sprint review,
- and sprint retrospective.
Let’s take an in-depth look at each of them below.
Backlog grooming, sometimes known as backlog organization, is the ongoing maintenance of the product backlog. We mentioned this earlier in our description of the product backlog itself.
The product owner is tasked with keeping up with market demands and customer requirements and making sure the product backlog reflects this data. The product owner would also rely on feedback from users and developers to reprioritize (if necessary) and clean up the list to keep it relevant and lean.
Sprint planning is exactly how it sounds, a complete layout of the work to be performed during the current sprint. This is sometimes referred to as the “scope” of the sprint.
The Scrum Master leads this meeting and helps the entire team decide on the sprint goal. User stories that align with the sprint goal are typically added to the sprint from the product backlog. The development team votes and decides on each specific user story to use, choosing the ones that are most feasible to implement during the sprint.
At the end of the sprint planning, the Scrum Master will go around to each member of the development team and confirm that they’re all clear on the increment to be delivered by the end of a sprint.
The sprint is what everything else revolves around. This is when your development team turns plans into code and hammers out the agreed upon increment. Throughout this time period, the entire development team works together to deliver the final result.
The time it takes to complete a sprint will vary, but two weeks is typical for most sprints. Some teams believe one week is preferable (and easier to scope), while other teams believe you need an entire month to deliver a truly robust and meaningful increment.
For complex work that has you dealing with many unknowns, you should probably err on the side of a shorter sprint. This allows you to make enough progress to gain a foothold without creating a host of other errors and bugs. It also lets you check in with your team often to identify the pressing issues early on so they don’t get out of hand.
But, at the end of the day, Scrum is all about adaptation. So, if something doesn’t work, change it. Renegotiate the scope with the product owner and development team.
Scrum is based on empiricism – taking action and using the results of your actions to improve, constantly. Every insight and experience from every sprint informs the decisions for future sprints.
The daily sprint or “stand up” is a short meeting organized at the start of every day, preferably at the same time and place for building the habit and to keep it simple. Most teams try to keep the meeting time down to 15 minutes.
The goal of the Daily Scrum is to get all the developers on the same page and aligned with the sprint goal and to create a solid plan for the next 24 hours of development, ensuring everyone understands their roles and responsibilities. This is also the time for team members to voice any concerns they may have about the sprint goal, the increment, or anything else.
After a sprint is complete, the development team gathers together to view, demo and/or inspect the increment created. The team showcases the backlog items that are “done” to the product owner, team members, and other stakeholders.
It’s at this point the product owner can decide to release the increment or continue working on it. The product owner will also update the product backlog based on the current sprint which will carry over to the next sprint.
The sprint retrospective is at the heart of Scrum. This is where the entire team comes together and looks at what worked and didn’t work in sprints, projects, people, tools, and even these very events and ceremonies that makeup Scrum. This is the time for the team to focus on what needs to be improved, changed, thrown out, and kept.
And this is how Scrum naturally evolves over time for each unique organization that implements it.
If you enjoyed this article and want to learn more about Scrum, check out our compendium of tutorials and articles.
Published at DZone with permission of Siva Shanmugam. See the original article here.
Opinions expressed by DZone contributors are their own.