When thinking about “what is Scrum methodology?” you inevitably discover it’s largely about teamwork.
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.
In today’s modern DevOps hubs, coders and testers are constantly interacting with one another.
At least, the effective ones are.
Because with the rise in the Agile framework comes rapid and constantly evolving software development processes.
Which brings us to the subject of today’s post:
The Scrum methodology.
Some of you are familiar with this popular application of Agile principles while the rest of you are probably asking yourselves “what is Scrum methodology?”
We’re going to answer that question.
And then we’re going to detail the various aspects of Scrum to show you precisely how it works and how you can apply it in your business.
Let’s jump in.
“Scrum” comes from Rugby when a team is working together towards a common goal.
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 their word, “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:
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.
One way to understand this difference is by recognizing what Agile and Scrum really are.
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.
The meaning of Heuristic, from Wikipedia, being, “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.”
We would also argue it’s not optimal or perfect, but it’s certainly logical and rational. And it’s definitely a practical method for reaching your immediate goals.
Scrum recognizes that you don’t know everything at the start of the project.
But over time, your work will evolve and improve.
The team will make 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.
However, there are specific tools and processes built into the basic version of Scrum that you will undoubtedly have to use to make Scrum work.
The first is “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:
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:
It mainly acts as a to-do list.
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.
However, the goal of each sprint should never be compromised. Changes made should only ever increase the speed of progress toward the goal.
The Increment, or Sprint Goal, is the end-product of a sprint. It’s also your team’s definition of “done.” Also called a milestone.
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.
Every Scrum team has three specific roles:
Let’s quickly cover each.
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 coaches teams, product owners, and the business on the Scrum process and looks for ways to improve it.
The Scrum Development team plans and initiates the Scrum sprints and effectively completes the software project.
Check out: Top Scrum Certifications of 2021
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:
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 make up 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.
Scrum is one method of implementing Agile.
But to make it work, you need to put Agile into practice in your organization first, and then use Scrum to apply Agile’s philosophy and principles.
That’s where we come in.
ATC specializes in Agile consulting. We can help you:
Reach out today to discover how to apply Scrum to your next software initiative.
In today's challenging job market, marked by layoffs, budget cuts, and recession fears, workers under…
The introduction of the Hybrid Cloud in 2011 revolutionized global businesses that solely depended on…
SaaS companies typically operate on a subscription model, which makes their sales cycle more intricate…
For years, companies across industries have been adopting Agile approaches for greater adaptability and speed.…
The race to become future-ready is critical as organizations stand to gain 1.7x higher efficiency…
Having a worldwide adoption of 87 percent, Scrum has unlocked a powerful way for companies…
This website uses cookies.