Sometimes you simply need a faster way to finish work without worrying about preparation or planning. That’s what’s so great about the scrum framework. You can start making real progress toward project and organizational goals, and you don’t have to waste time discussing it. It’s a clean project framework that is about getting things done, but how does it work? Let us explain.
In this post, we will cover
- What is Scrum?
- The Scrum Framework, An Overview
- Pros & Cons of the Scrum Framework
- Scrum Values
- Roles in Scrum
- Scrum Artifacts
- Scrum Ceremonies & Events
- Scrum Framework in Project Management
- How You Can Get Started, Adopt Scrum
Learn about the system that has ruled software and tech for over 20 years and isn’t slowing down any time soon.
What is Scrum?
The scrum framework was developed in 1995 by Jeff Sutherland, who wanted to provide development teams with a system that allowed for constant feedback and collective, collaborative decision-making. Development—and other industries that don’t require much preparation to get work done—moves fast. When managing these types of teams, you only need a structure that supports productivity, which is exactly what the scrum framework provides.
Because of the lightweight quality of this framework, it’s extremely adaptable and amenable to your team, organization, and project goals. It’s clean, simple, repetitive, and very productive.
The teams who tend to use the scrum framework are often those who need adjustable solutions to rather complicated problems. Also, the scrum framework is purposely incomplete, meaning it’s just specific enough to give you a clear path for implementing the theory.
To counter the complexity of the problems, it’s a very simple framework that is easy to understand and implement. It allows for quick, small feedback loops and gives adequate space for airing out any issues that arise.
One of the biggest reasons it has become too popular, especially in software development, is how empirical it is. Empirical is a Greek-originated word that means “originating in or based on observation or experience.” By saying that the scrum framework is empirical in nature, we mean that it’s built upon collective intelligence.
On the other hand, a few reasons businesses tend to stay away from the scrum framework include
- It’s easy for the scope to creep due to the iterative structure
- There is a strict limit on how many team members can be involved, or else the framework isn’t as effective
- The lack of room for more than one sprint goal at a time
- There is a lot of pressure constantly on the development team due to the strict, short, and frequent deadlines
The Scrum Framework, An Overview
For those of you trying to understand this concept in one fell swoop, let’s discuss the main features of the scrum framework.
Scrum Definition
Developed in 1995, the scrum framework is a working structure that allows complicated projects and products to be broken down into smaller, more manageable features and tasks. It supplies teams with enough structure to be helpful but not so much that it’s limiting or inflexible.
Scrums rely on short-term, cyclical working periods called “sprints” that are attached to five types of repeating events and three artifacts.
These events include
- The Sprint
- Sprint Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
These artifacts include
- Product Backlog
- Sprint Backlog
- Increment or Sprint Goal
Scrum Values & Pillars
The scrum framework is not only defined by its flexibility and fast pace, but it also stands on the pillars and values it rests upon.
These values include
- Courage
- Focus
- Commitment
- Respect
- Openness
The pillars include
- Transparency
- Inspection
- Adaptation
- All standing on Trust
Additional Information on the Scrum Framework
The term “scrum” is based on a formation found in rugby in which the team comes together to move the ball forward—and they do it with force. The scrum framework does the same thing, but it’s a project they are moving forward instead of a ball.
The goal of this framework is to
- Allow for continuous progress and improvement
- Deliver value in increments
- Learn as you go
- Provide the team with room for experimentation and feedback from the collective
The scrum team consists of
- The product owner
- The scrum master
- The development or execution team
The scrum framework requires an atmosphere that allows for
- Work to be completed in short-term cycles called sprints
- The team has the autonomy to do their job and turn a selection of work into an increment of value
- Stakeholders to inspect the results and adjust goals for the next sprint
Pros & Cons of the Scrum Framework
The scrum framework is irreplaceable for fast-moving, productivity-focused teams that need to deliver a high level of value regularly.
Some key advantages of using the scrum framework include
- The ability to split large, complicated projects into more management tasks
- The product or project is put under testing regularly
- It supports the fast-paced quality of projects in evolving markets
- You can base sprints on timelines and budgets, which results in effective use of both time and money
- Feedback is received regularly and is implemented quickly
- Enables the team to focus on completion rather than just progress
- Due to the placement and team size, there is a high level of transparency and visibility
- It promotes autonomy because each individual’s efforts are visible
But it’s not made for everyone. Software development, marketing, and creative industries make sense with Scrum because of the strong focus on deliverables. Conversely, the industries that require structure, repetition, documentation, and planning will not have a fun time with scrum.
Some of the key disadvantages of using the scrum framework include:
- Regular issues with scope creep, if not handled properly
- Requires a highly-specialized and cross-functional team
- Requires small teams, never medium or large
- The daily scrums can be frustrating and place unnecessary pressure on team members
- In the event of the loss of a team member, the whole project can be impacted
- There are higher chances of failure if the team is not cooperative or committed
- Quality can be hard to implement consistently due to an increment-based approach
Based on this framework’s realities, you must be careful about using it. It’s not built for everyone, and that is okay. Sometimes, traditional project management really is the way to go.
The Pillars of the Scrum Framework
Each concept has a structure that supports it. The scrum framework is no different. In fact, for anyone who uses this framework, these values, principles, and pillars are extremely important and necessary for everyone to understand.
Scrum is able to exist because it’s built on three pillars. Transparency, Inspection, and Adaptation—all of which rest on trust.
Transparency
The entire process must be visible, specifically to those who are completing this work. When decisions are made, they need to be based on collectively understood artifacts (which we discuss below). Transparency flies out the window if artifacts can’t be collectively viewed and evaluated. And without transparency, this framework is unstable.
Inspection
Scrum is productive and not entirely chaotic and wasteful due to the amount of inspection that happens. Both the artifacts and the progress are inspected regularly and thoroughly to ensure a delivery of value, which also means detecting and reducing deviations from scope and issues.
Adaptation
Scrum moves so fast that it can easily move outside of the bounds of what is acceptable. That truth has to balance itself against the fact that this framework works better when people are self-managed, and teams are self-organized. They can adapt better that way.
Each of these three characteristics could sit in a triangle because of how each impacts the other. Transparency promotes inspection, inspection enables adaptation, and adaptation works best when people can clearly see what’s happening.
The Five Core Values of the Scrum Framework
When using Scrum, you really have to commit to supporting each other. Each action of each scrum team member should bolster these values and never diminish them. Ultimately, this framework and its values are about letting each other be independent and capable while supporting each other when there are gaps.
Roles in the Scrum Framework
Due to the small amount of team members, each one plays a pivotal role in the team’s success. And remember, management does not exist here in the same way it does in traditional project management. If anything, the scrum framework is known for its lack of management.
So, instead, leadership is responsible for breaking down the project into smaller tasks that can be organized, undertaken, and completed. They support the planning, completion, and review cycle in each sprint.
That is actually another reason Scrum is so popular in software development and tech. It helps teams concentrate on a smaller goal, perfecting and preparing it before it fits into the primary project goal—and each role serves that progression.
The Scrum Team
Inside the scrum framework, there are no substitute teams or hierarchies. It is what it is: a cohesive unit that is cross-functional, self-managed, and self-organized. That means each team member has different skills that support the collective goal. Also, they are all experienced and seasoned enough to manage their workload themselves. On top of that, they sort through the tasks and, as a team, decide who is doing what, how they’ll do it, and when.
These teams are small enough to be agile and large enough to get the work done. Having small teams keeps communication clear and allows the scrum framework to function how it was intended. If the teams get too large, they should be reconstructed into smaller ones—yet they can all share the product owner, scrum master, backlog, and goal.
The scrum team is responsible for all project/product-related operations.
- Development
- Research
- Experimentation
- Operation
- Maintenance
- Verification
- Stakeholder Collaboration
- And more
Generally, there are three roles in the actual team, including the
- Developers
- Product Owner
- Scrum Master
Each of these roles is described in more detail below.
DEVELOPERS
The developers are anyone whose role is just to get the job done. They aren’t accountable for any overarching themes. On the other hand, they are responsible for the following.
- They help create a plan for the sprint
- They help create a plan for completing backlog items
- They instill quality and move the project closer to its goals
- They assist in adapting the plan to meet the sprint goal
- Each holds the others accountable
- They cross-train each other in new skills to limit bottlenecks
PRODUCT OWNER
While product owners can be involved in the actual development, they tend to act more as a bridge between the organization and the team, which can be isolated from others to promote productivity.
They are responsible for filling out the product goal, clarifying obscurities, and aligning it with the organization’s goals. They also communicate the product goal. Product owners establish and then explain backlog items, ensuring the backlog is clear and visible.
The product owner is only ever one person, and even if they delegate any of the above tasks, they are still answerable for the outcome.
SCRUM MASTER
The scrum master has the most responsibility out of all the scrum team roles. Not only do they support the team in their productivity and help the product owner with their tasks, but they are also clear the way.
What does that mean?
The scrum master has the task of fostering a work environment where the team is protected from issues that could hinder productivity. They coach, support, and host all necessary scrum events while guaranteeing they are helpful, productive, and on time.
Scrum Master vs. Product Owner
While they work closely together, there are distinct differences between these two roles. First, the product owner is exactly that. They are the most informed on what this project is supposed to accomplish, which means they are the champions of the project. Their priority is ensuring the tasks are completed and moving the project forward. As the product owner, you safeguard the objectives.
In contrast, the scrum master is responsible for safeguarding the team. While they support completing tasks and meeting goals, they focus more on supporting the team.
Scrum Master vs. Project Manager
The scrum master, as we mentioned, is focused on keeping the team in line with scrum principles while supporting them on their way to completing their goals. They exist inside of the scrum framework and lead and consult. On the flip side, the project manager handles everything.
Project management oversees, controls, and influences the entire project. They manage risks, supervise task completion, and they regulate budgets. You can read more about a project manager’s role here.
Scrum Artifacts
When you are using the scrum framework, there are only three things you actually need. In Scrum, this is all the necessary documentation that you have to worry about. These include
- Product Backlog
- Sprint Backlog
- Increment or Sprint Goal
Each scrum artifact is explained in detail below.
Product Backlog
In the scrum framework, the product backlog is basically a giant to-do list. Each feature, objective, fix, and adjustment is documented (or reduced to more manageable tasks and then documented) on the product backlog. It’s the sole input to the scrum team regarding work to be done and the sprint backlog.
Items that can be done soonest and fastest are often deemed “ready” and will be selected in a sprint planning event. This list will be regularly refined to make tasks small and doable and limit how much is “in progress.”
Sprint Backlog
Following a similar logic, a sprint backlog is the to-do list of the sprint, the short working period where team members attempt to make progress. It is a plan made by the development team for the development that holds the why (goal), the what (product backlog items selected for the sprint), and the how (the plan for delivery).
Increment or Sprint Goal
The overall product goal can easily be multi-layered, complicated, and extensive, which makes it impossible to complete accurately in one sprint. So, that goal is broken down aggressively into increment or sprint goals. These are like stepping stones on your way to climbing the mountain.
Just like stepping stones, these goals are incremental, building up the project.
Multiple goals can live inside of one sprint. However, the work is not considered as part of an increment until the work fits the team’s definition of done, a parameter with the following characteristics.
- It’s a collective agreement that plainly defines completion.
- It follows the standards of the organization.
- It is considered the bare minimum.
- It’s created fresh for each project.
Scrum Ceremonies & Events
The scrum framework is best known for its cyclical, repeating events that are contained inside of sprints. Each scrum ceremony is a time-sensitive event that happens at predetermined intervals. These events include
- The Sprint
- Planning
- Daily Scrum
- Sprint Review
- Sprint Retrospective
Each of these scrum ceremonies is explained below.
The Sprint
To clarify, a sprint is where all these ideas turn into testable progress. They have a fixed length but never more than one month. Also, they follow one right after the other, so as one ends, the next begins.
During a sprint, no changes are made to the increment goal, the quality does not decrease (something the Product Owner monitors), the sprint backlog is fine-tuned as needed, and the exact scope can be clarified and negotiated. This means that certain details can be amended to fit better the current project landscape—something that easily changes.
Only when the product owner decides can the sprint be canceled.
Sprint Planning
Before everyone breaks off to go do their work, they have to decide what exactly is going to be done. That’s where the plan comes from. It’s created through the collaboration of the entire team. The product owner distributes whatever information is necessary to prepare people for this step. They ensure everyone is prepared to discuss critical backlog items and how they play into the bigger picture.
The product owner might even invite outside perspectives to give input. These planning sessions address why the sprint is valuable, what can be done, and how it will get done.
Daily Scrum
Each day, for about 15 minutes, the development team, the scrum master, and the product owner meet to discuss how things are going, what got done, and where everyone is headed next. During these meetings, the backlog is adapted and happens simultaneously in the same place each working day.
The scrum master and product owner only join if they participate in development.
These meetings improve communication, increase the speed of issue identification and problem-solving, and eliminate the need for other meetings. They should be no longer than 15 minutes.
Sprint Review
Once the working timeframe ends, it’s time to inspect. Here the team, the scrum master, the product owner, and any relevant stakeholders will collectively look over the outcome of the sprint, determine where to go next, and adjust the backlog as needed.
If the sprint was for one month, this meeting should last no longer than 4 hours.
Sprint Retrospective
This is the final sprint ceremony. Here, the team, the scrum master, and the product owner evaluate the entire sprint. Rather than focusing on what was produced, they examine the people involved. The group plans ways to increase both effectiveness and quality. They also look at issues, their causes, and how well the solutions did. This meeting should last a total of three hours if the sprint is one month long.
Let’s Make It Simple, The 6 Steps of the Scrum Framework
When you take a step away from the specifics of each event inside the Scrum framework, you see that it’s roughly a six-step process.
- The product owner makes a list of necessary features, enhancements, fixes, and tasks, creating the product backlog.
- The scrum team reviews that list and works to break down any unmanageable tasks and make them manageable.
- The group determines which tasks they complete in the coming sprint, which means they create the sprint backlog.
- The team, scrum master, and product owner will back away from other obligations and complete a sprint lasting anywhere from 2-4 weeks.
- During the sprint, there are daily scrum meetings, which are no longer than 15 minutes, covering what was done, what will be done, how, and any issues that arose.
- After the sprint, the product owner, development team, scrum master, and stakeholders review the progress. They will also review the people side of the sprint and see how that can be improved.
These steps repeat until the project requirements are met.
Scrum Framework in Project Management
While the scrum framework can be its own management system, it can also fit inside traditional project management. A small team, led by a scrum master and supported by a stakeholder that stands where a product owner usually is, can easily fit in traditional.
When you need quick creation or development and rapid testing, scrum is a very effective system—especially when you have a strict budget.
Agile vs. Scrum Framework
It’s not abnormal to think that agile and scrum are the same thing. And while they are similar, they are not the same.
The confusion comes from the fact that these two systems are based on the same core principle: continuous improvement. But scrum is a framework for getting the work done, and agile was created as a set of values to guide behavior and intention. These values include
- People Over Processes
- Working Product Over Documentation
- Collaboration Over Contract Negotiation
- Respond To Change Over Following The Plan
You can learn more about agile project management here.
How You Can Get Started, Adopt The Scrum Framework
When you need a team-focused approach to completing a project, the scrum framework is a great choice. It is not a great choice if you have cyclical projects that are generally a repeat of processes, such as construction.
It’s also not a great fit for projects that are heavy on the prep. The scrum framework is everyone collectively agreeing to start throwing stuff at the wall and see what sticks and what works. Few industries need that, and even fewer can handle it.
It’s also not made for projects where stakeholders are used to an authoritative, top-heavy angle on project management. They will be very uncomfortable with this management style.
Regarding implementation, we recommend that you start small. Select a highly experienced team that would enjoy a bit more independence. They also need to be trusted not to abuse it. Then, select a scrum master who is good at supporting people—someone who can set them up and step back. A stakeholder or the project “owner” could step into the product owner role and work as a bridge between this team and your organization.
When used right, the scrum framework is a great approach for letting creativity run wild—the right way.
Let New Ideas Find You
Here at A.McBeth, Inc., we know it’s better to open our thinking caps, receive new ideas, and use them occasionally than act like we know everything. Project management is pretty uncomfortable with that attitude, so we are offering up new (and old) ideas all month long, so sign up to be notified the next time one pops up. You won’t want to miss it!
