Scrum is a project management framework that helps small, close-knit teams develop complex products incrementally. Scrum focuses on how people work instead of what they do. Scrum relies on agile principles and is the most popular agile methodology out there.
Scrum is the most popular agile project management framework that's used in software development organizations. Scrum can also be used in schools, marketing agencies, government, and other types of organizations. Scrum was first introduced in early 1990s by Jeff Sutherland and Ken Schwaber. It got its name from rugby, where scrum is when a team huddles around the ball and tries to move it down the field in order to win. Scrum is a metaphor meant to reflect how everyone needs to work together to complete a specific project.
In Scrum, you deliver to your customer new code and functionality every two weeks. Those two weeks represent one sprint, and the whole workflow is built around them. To better understand how Scrum works, we'll discuss what happens before, during, and after the sprint.
Before you can start coding, you must plan what you'll work on. In Scrum, there are no big master plans like in Waterfall, where you lock up your resources months in advance. Instead, Scrum lets you work on one thing for two weeks and then reflect on what you'll work on next.
Everything starts with your users/clients. First, you get a wish list from your customers in a special format called user story, which looks like this:
• As a (role), I want (feature) so that (reason)
• As a manager, I want custom time reporting services to calculate my employees' exact salaries.
Then, you create a task for each user story, put it in a backlog, and estimate each task (together with the team). Finally, you decide on what items you will work during the sprint. If some item can't be done in one sprint, it's called an epic, and you have three options: split it across several sprints, leave it for later, or do a new project and form a separate team to work on it.
You set up a Kanban board to visually track progress, see who works on what, and control bottlenecks. The board is usually split into several task lists (columns):
• Backlog - all feature requests and bugs go here first
• Next Sprint - tasks you'll work on after the team finishes the current sprint
• To-Do - what the team needs to complete during the current sprint
• In Progress - tasks that the team is actively working on right now
• Testing - finished tasks that need to be tested before being marked as complete
• Done - finished tasks that are ready to be shipped once the sprint end
Once you've decided on what items to work on, the team pulls tasks from the To-Do columns and moves them to In Progress as they start working on them. Once they're finished, the task goes to Testing; if the task needs more work, it goes back to In Progress; once the task meets the Definition-Of-Done criteria, it goes to Done and is ready to be shipped.
Each day before work, the team has a daily standup. The meeting doesn't take longer than 15 minutes, and everyone shares a quick status update:
• Things I have done since yesterday's meeting
• Things I am going to get done today
• Obstacles I need someone to remove
To measure professional progress, the team uses a Burndown Chart, which is a graphical representation of work left to do versus time. That chart shows the team's efficiency, whether they will ship on time, and if the process must be optimized.
At the end of the sprint, the team reflects on what they've done. They have two reflection sessions:
• Sprint review (2h), where they discuss the work they've done and the planned work they didn't finish
• Sprint retrospective (1h), where they talk about the process (what went well and what could be improved in the next sprint)
After the reflection, the team estimates new user stories and decides on what to work on during the next sprint.
People frequently ask which role can cancel a sprint. The answer is that only the product owner can cancel a sprint if the conditions change significantly or the sprint goal becomes obsolete.
Scrum is more about the mindset than some checklist you need to follow to a T. Once you have an agile mindset, here's the most common way companies implement Scrum:
• Pick a product owner
• Pick a scrum master
• Create and prioritize a product backlog
• Refine and estimate items in the product backlog
• Put up a Kanban board
• Plan the sprint
• Have a daily stand-up
• Work and build a product
• When finished, do a sprint review and sprint retrospective
• Immediately start the next sprint
In Scrum, teams develop software in sprints and release what they've worked on every two weeks. This way, customers get bug fixes and new features as soon as they're done, and there's less risk altogether.
By design, agile teams are responsive and flexible. Scrum teams should be result-driven, lean, and small. Some experts say the scrum team size needs to be up to six people, but it's important to note that the agile team working in scrum has three primary responsibilities or roles.
The product owner is the visionary and represents the voice of the end user. If a team member has any questions regarding the functionality of some feature, it's the product owner's job to clarify the purpose of that feature. The product owner focuses on the business side of product development and spends most of the time talking with stakeholders. The product owner doesn't care about the technical implementation, only the end result. The product owner's main job is to:
• Gather and write user stories
• Refine and prioritize the backlog
• Handle clients and demo new features
In most cases, a key stakeholder or an executive has a vision of how the end product should look and how it will fit into the company's long-term goals. The product owner needs to manage communication efforts, notify the team about significant developments, and implement high-level changes when necessary.
The Scrum master's role and responsibilities are similar to the project manager's, with an emphasis on professional team facilitation and making sure the Scrum framework is followed. They go through training and learn how to guard processes, ensure feedback, and mentor junior team members. Scrum masters also monitor day-to-day functions, check in with team members, keep the scrum board updated, and ensure that tasks are completed on target. Scrum master, unlike traditional project managers, doesn't manage people because that goes against agile principles.
Scrum master's main job is to:
• Remove impediments for team members
• Facilitate team events
• Track sprint progress
• Improve processes
The team does all the actual work, from analysis and design to finding solutions, coding, and testing. They are self-organizing and work without supervision. Team members have different roles in the scrum team, and they are responsible for getting milestones and projects done on time and in excellent quality.
Scrum teams are cross-functional, meaning they don't have a clear sub-role, and everyone can do anything. Most teams compromise by hiring T-shaped workers so, while everyone can do anything, there is still some specialization and work division. Scrum work only if the team is small, up to 9 people. Any team larger than that changes team dynamics, thus rendering Scrum ineffective.
Scrum artifacts are information used by the scrum team and stakeholders to describe the product they're developing. The product and sprint backlog and increments are the most important ones of the seven agile artifacts.
A short and precise definition of the project's goal. It's used by the scrum team as a general direction for developing the product.
A list of user stories, bugs, and tasks that the scrum team must achieve to complete the project.
Guidance for the scrum team to achieve the sprint goal.
A to-do list of tasks that need to be completed in the current sprint.
A checklist of items used to define the factors needed for an increment to be released. It applies to all your work and increases the transparency among team members because everyone knows what needs to be done for an item to be checked as "done".
The deliverables produced during the current and all previous sprints.
A graphic depiction of how fast the scrum team completes the product backlog items during a sprint.
Agile is a way of thinking, and Scrum is a way of implementing it. There are some differences between these two terms, but the approach is the same because Scrum is based on Agile principles, even though it’s a decade older. Agile is a project management philosophy, while Scrum is an Agile methodology; Agile is focused on improvements and delivering value, and Scrum is focused on continuous development and testing; Agile is ideal for creative and experimental projects, and Scrum is better suited for smaller teams; Scrum features three key roles, which don't apply to Agile teams who are self-organizing; Scrum's delivery is based on sprints, while Agile delivers products at the end of the project; finally, Scrum is based on three pillars, and Agile relies on 12 principles.
On the other hand, comparing Scrum to Kanban means looking into two methods of managing projects. The differences between them are significant as Scrum focuses on delivering through sprints and holding regular meetings, while Kanban only focuses on visualizing the workflow and is less rigid. It’s also worth noting that Kanban boards are usually used by Scrum teams to visualize their work. Compared to Scrum, XP emphasizes the importance of engineering practices, and Lean is all about reducing waste.
Commitment— Each team member must commit to the sprint's objectives. Everyone should prioritize their assignments according to the value they contribute.
Focus— It's important to assign only a realistic workload to each team member, so they can focus on the current sprint's requirements. Daily standup meetings should be used to let everyone know which assignments will be the focus of the day.
Openness— Every morning, team members will discuss what they're working on and if they're facing any obstacles. They must be honest because otherwise they won't get the help they need to overcome challenges.
Respect— Scrum insists on respecting each team member equally, regardless of their role, age, and skill. It's not allowed to micromanage someone, degrade them, or disrespect their opinion.
Courage— Scrum master and product owners must demonstrate courage by standing up and pushing back when the sprint's scope is being breached. Team members should also have courage to get out of their comfort zone and speak up about the challenges they're facing.
Scaling scrum happens when multiple scrum teams work on delivering a product. It's not advised to scale scrum before adopting scrum within a company is complete and all the issues of implementing it are out of the way. The scalability of scrum indicates the ability to increase the number of teams working on a product while adding equal value to developing the product. Think hard before deciding whether it's absolutely necessary to begin scaling scrum.
There are several ways to scale scrum:
• SAFe
• Nexus
• LeSS
• Scrum@Sale
• Scrum of Scrums
The main benefits of introducing scrum are a more efficient use of time and money and managing projects in smaller and more manageable chunks. It's easy to make changes to sprint goals and shift priorities throughout the sprints without derailing the entire project.
Meetings are better defined and boxed. Everyone knows what each scrum meeting is for, so they come prepared and know what to expect. The timebox is clearly set, and every breach must be justified. These meetings help keep the project on track, and the team is on the same page with the stakeholders.
Successful project management and communication are two inseparable elements. So, whether you are running a Waterfall or Agile project, meetings are a vital component of project management. The agile methodology goes one step further by making scrum and agile meetings parts of its existing framework. Depending on your team's styles and preferences, these meetings can assume different timelines and forms, but they all include the same scrum methodology.
Sprint planning starts with the product owner explaining the vision and how team members should complete this project stage. Also, teams decide how much work they can complete within the sprint. This type of meeting happens when teams move from product backlog to sprint backlog as well. This step requires about an hour for the team to decide on the final items that will be included in the sprint.
Each day, team members gather for about 15 minutes to report any issues and discuss progress. Even though it's a brief meeting, it's still relevant to the scrum process. Daily scrum meetings are designed to keep all team members on the same page and bind them to a cohesive and functional unit. The scrum master is present during these meetings.
The primary purpose of a sprint review is to demonstrate what has been done so far. Stakeholders, scrum masters, and product owners must review the product and suggest necessary changes or improvements.
Team members speak freely and openly during this meeting about their organizational concerns and teamwork. The meeting should be impartial, non-judgmental, and friendly. This session is a crucial part of the development and team-building process. To some extent, future scrum projects depend on it.
Sprint retrospectives happen after each sprint review but before the next sprint planning. In most cases, this is an hour-long meeting. This is an improvement meeting, where team members try to identify past mistakes, and potential pitfalls and look for new ways to avoid those mistakes.
Development team members, scrum masters, and product owners need to attend this meeting. Sprint retrospectives help the organization locate activities the team is doing well and what needs to be done for the next sprint to be more productive.
Each sprint retrospective meeting includes five stages:
• Set the stage: set up goals and allow people to have some time to get into the right mood.
• Collect data: remember to help everyone by creating a shared pool of information.
• Generate insight: why do things happen the way they do? Use this step to pinpoint some patterns and try to see the bigger picture.
• Decide what to do: choose a couple of issues to work on and then create an action plan to address them.
• Select the retrospective: think about the ways you can improve retrospectives.
When it comes to length, sprint retrospectives shouldn't take more than 45 minutes per week. For example, if you have a week of sprint duration, then the retrospective meeting should last 45 minutes, for two weeks 90 minutes, and so on.
People who execute tasks should attend a sprint retrospective meeting. They include product owners or a scrum master, designers, developers, and engineers.
Anyone who isn't a sprint execution or scrum team member shouldn't attend sprint retrospective meetings because they cannot help, and their presence may damage the retrospective process. The scrum master runs the meeting and keeps everything in perfect order. Other participants offer their input and views on what happened and ways to achieve better results next time.
Retrospectives aren't strategic meetings that could change the direction of the organization. They usually focus on small changes to improve processes, collaboration, and teamwork, bit by bit.
Last but not least, we have a backlog refinement meeting, where teams focus on skills and the quality of work involved during the sprints. In this meeting, the product owner will connect with the development team and assess the final product.
• Participants— Sprint reviews include almost everyone related to the project. In contrast, a sprint retrospective involves a scrum team only, with no input from others.
• Deliverables— While both meetings are held at the end of each sprint, their outputs vary significantly. Sprint review output involves updating the product backlog with high-priority user stories for the development team to work on. The sprint retrospective output is an action that lists all the essential steps, which boosts the team's ways of working during the next sprint.
• Goals— In sprint review, the goal is alignment between product stakeholders and the scrum team to offer a universal direction for progress and development. The purpose of a sprint retrospective is to enhance scrum team execution for each sprint continuously. These two scrum events work best when they are separated, so don't try to merge them.
Get familiar with the most popular methodologies modern project managers use! Learn the basics and choose the best method to manage your teams and projects.
Choose the best methodology for your teams
