Scrum Guide: Master Scrum in just 15 minutes

Classical business planning and waterfall development

In the "old days", when the business environment was not yet so volatile, complex and competitive, making and executing plans was very different than it is today, at least in most industries. Back then, we were able to plan very long-term, for five years or more, since the global markets, industries and competition were much more predictable and stable. 

The rate of technological, social and economic change was much slower than it is today. The frequent term for accelerating changes is singularity.

Having a quite stable business environment not long ago meant it was much easier to make long-term plans, most frequently using classical tools like Porter’s five forces, SWOT analysis, benchmark analysis, business planning with very detailed financial projections, long-term product development plans and so on. 

Companies did an extensive analysis, and planned how to win the market in a few years.

Similarly, in software development the Waterfall model, a methodology that breaks down project activities into linear sequential phases and where each phase depends on the deliverables of the previous one, was the way to plan new software solutions.

Classical business planning and waterfall development can still be very useful today (in some cases and industries) or they can even complement the agile way of doing things.

But the main requisites for that are that the industry is very stable and predictable, nonmalleable by any bigger player, the historical data are available and provide future predictability, and there’s little chance of disruptive innovation in the industry.

Additionally, you have to also accept that any snapshot of a business environment using analytical tools can become outdated quite quickly.

Just like for engineers, to put the waterfall model in use customers should know exactly what they need, there must be no unknowns in terms of how to build the solution, and nothing should change along the way of the development process.

If requirements may change, the Waterfall model has a hard time providing the desired results. And as you probably guessed, there are fewer and fewer industries and projects that would provide such predictability and stability.

We’re living more and more in an environment where, as Darwin already said, the most adaptable survive and thrive.

That’s where agile comes into play.

Source: Agile in a Nutshell

Why is there a need for an agile approach?

In a volatile, complex and competitive economy things change fast and often, and businesses need to constantly adapt to these changes. 

If you don’t manage to respond to these changes in an agile way and adapt, preferably in a way that uses these changes to make you even stronger and put you in a better position, the organization most often suffers losses, or might even go out of business.

In addition, the most successful companies are constantly improving, experimenting and removing waste in order to create more value for the markets. You probably know the famous Amazon mantra that their success at Amazon is a function of how many experiments they do per year, per month, per week, and per day.

Constantly experimenting, looking for ways to do things better, and adapting to changes is all part of being agile, but to be as concrete as possible here are some examples of changes that require an agile approach to doing business:

• Customers often change their minds or want something new
• Customers don’t know exactly what they want, thus you must constantly experiment
• New technologies and disruptive innovations are constantly entering the market
• Market conditions are changing pretty regularly
• Competition has become global, especially with the Internet
• The best competitors are constantly experimenting, looking for better ways to do business
• As a business you must move fast and excel at time management
• Unpredictable challenges and changes are always a threat
• Every decade or so we face a major crisis as we did in 2008 when the financial crisis hit, in 2020 when COVID-19 arrived and so on.

The main goal of the agile approach is to successfully respond to the changes listed above. 

In practical terms, that means you as a business minimize waste (you minimize activities that have zero value for the market), deliver value as quickly as possible, and stay away from any fixed ideas on how things should be (also called emotional agility), but rather constantly reorganize and improve. 

You have to move fast, experiment a lot, and keep your agility high. Unfortunately, that sounds much easier than it actually is, but luckily Scrum is the framework that provides all the guidance needed to achieve this.

Welcome to the world of agile methodologies

Agile methodologies are not something new. The Agile manifesto was introduced in 2001, and since then different agile frameworks have taken off. The most popular is of course Scrum, but there are also other frameworks available that complement or compete with Scrum. 

Some examples of such frameworks are Extreme programing, Kanban, Scrumban, Lean development, Design Thinking and so on.

All these techniques provide valuable tools to allow you to do things in a more agile and efficient way. Since Scrum is the most popular and useful framework, we will put our focus there, but, nevertheless, we want to mention each of the above methodologies briefly for your further exploration.

Source: Gartner

Design thinking

Design thinking, lean and agile are different concepts, but very interrelated and complementary to each other. Design thinking is about exploring the problem, lean is about building the right thing, and agile means building the thing right. 

Before building things, we have to explore what makes sense to build. That’s where design thinking and lean come into play.

So, what is design thinking? The design thinking method states that we should have a hands-on, user-centric approach to exploring the problems that our customers are facing. Exploring and later solving these problems can lead to innovation. The design thinking process is based on six steps:

• Empathize with users
• Define problems
• Ideate and generate a bunch of crazy ideas
• Prototype
• Test what works and what doesn’t based on the users’ feedback
• Implement

Lean product development

The lean approach in general originated during the revolution of lean manufacturing and lean thinking, developed by Taiichi Ohno and Shigeo Shingo of Toyota. 

Lean product development (also called the lean startup approach), based on lean manufacturing, is a new look at the development of innovative products, emphasizing quick iterations of product development based on new insights into the customers’ wishes.

In the modern economy, the question “Can this be built?” isn’t important anymore, because nearly any product can be since enough means of production are available. 

Significantly more important questions in the modern economy are whether a certain product should be built and whether it is possible to build a long-term, sustainable business model around the product. In other words, is somebody prepared to buy the product?

So, the main business challenge isn't to build the product, but to systematically get feedback from the market about whether the product is even interesting for potential customers. That’s what lean is all about. Lean offers a set of tools to address this problem such as:

• The Lean Canvas
• Validated learning with customer discovery
• Minimum viable product
• Innovation accounting
• Pivots etc.

Extreme programming (XP)

Extreme programming (XP) is an agile approach in software development that involves short development cycles and allows team members to quickly respond to changing requirements. 

It encourages values such as frequent verbal communication, pursuing simplicity and clarity, acquiring constant feedback, having the courage to remove obsolete things, and respecting yourself and others.

Other elements of extreme programming include:

• A flat management structure
• Not building features until they are actually needed
• Expecting changes in customer’s requirements
• Programming in pairs etc.

Kanban

Kanban is a very simple lean method which aims to visualize workflow for better management. Its goal is to help identify bottlenecks, limit work in progress, and provide continuous flow and delivery on projects. 

The key value of Kanban is that it is a system for the visual management of tasks. Since we are all visual beings, visualizing the work process and tasks can be of great help with work management.

In practice, Kanban is nothing but a whiteboard with columns (to-do, in progress, done) and post-it notes with written tasks on them. After you have the board and sticky notes, you simply stick them in one of the columns, depending on the phase the task is in. 

Now you have a nice visual representation of what needs to be done, the work in progress and tasks that are being completed. Today, Kanban boards are an important part of visualizing work when using Scrum.

The ultimate guide to understanding Scrum

The word Scrum comes from rugby, describing a method that involves players packing closely together with their heads down and attempting to gain possession of the ball. 

It’s a chaotic, unpredictable and competitive situation on the field, and it greatly represents today’s volatile, complex and competitive business environment.

In a short summary, the Scrum framework helps you to dissect work into small and manageable pieces called user stories, which can be done by a self-organizing and cross-functional team within a prescribed time frame, usually 7 or 14 days. 

The prescribed time frame is called a sprint and provides a productive dynamic for a team.

In addition, Scrum puts a lot of emphasis on relationships in teams, creating a valuable outcome, collaboration with all stakeholders, responding to change, and constantly improving the way you do work. It’s a formula for how to be flexible, adaptable, and fast enough in today’s challenging environment. 

Now let’s deep dive into this revolutionary framework.

General overview

Before describing each part of Scrum in detail, having a general overview can be really helpful. Scrum consists of roles, workflow and artefacts. 

The main elements of Scrum are:

Roles	Workflow	Artefacts
Product Owner Scrum Master (Development) Team	Sprint Planning Sprint Review (Release!) Sprint Retrospective Daily Scrum	Product Backlog Sprint Backlog User Stories Product Increment (Outcome) Burn-down Chart

The roles in a Scrum team are:

• Product owner – Manages priorities, talks to all stakeholders, takes care of products
• Scrum master – Facilitates the Scrum framework, removes obstacles
• The team – Cross-factual, fully committed team

The workflow is based on:

• Sprint Planning – Defining the scope of work for the next 2 – 4 weeks
• Daily Scrum – Short, 15‑minute daily meetings to keep commitment among peers
• Sprint Review – Review of the work completed after the sprint
• Sprint Retrospective – A discussion of what went well and what could be improved

And the artifacts of Scrum are:

• Product Backlog – A list of everything that will be delivered
• Sprint Backlog – A list of tasks that will be delivered in the next sprint
• User Stories – Small, independent, valuable, estimable, testable delivery features / outputs
• Burn-down Chart (Total effort, Velocity) – Progress plan based on the actual capability of the team

Now let’s go into detail for each of the listed elements of Scrum:

The Scrum team and roles

The team is the most important aspect of doing things the agile way. Without an outstanding team, not only is the framework hard to follow, but the relationships cause too much drama, unproductive conflicts, and ego battles.

On the other hand, an outstanding team knows they must cultivate psychological safety among the team, put customer feedback before their egos, turn conflicts into better outputs and follow the framework to make sure it brings the best out in their work.

The Scrum team consists of three roles:

• Product Owner
• Scrum Master
• (Development) Team

Product owner

The product owner’s main focus is on delivering value: in other words making a product people will actually use. They are voice of the customers and the person talking to all stakeholders. 

The key skill of the product owner should be good communication and the key personality trait, empathy. This, and they must be a “product person”, meaning the person in this role knows the business processes, understands the value, etc.

The main tasks of the product owner are:

• Managing product backlog
• Making personas and workflows, and writes user stories
• Prioritizing tasks – Value, Importance & Dependencies
• Talking to all the stake holders

Product owner deliverables are:

• Transparent and visible backlog
• Product demonstrations
• Release management
• Priorities, scope, funding, schedule
• Summaries of progress (to sponsors)

It’s important that the product owner and Scrum master are not the same people. It’s also important that the product owner doesn’t manage the team or add new tasks during sprints.

Scrum master

A Scrum master is a servant-leader that facilitates the Scrum framework; in other words they make sure the Scrum framework is followed. It’s important that the person is not typical product manager, but actually a servant-leader.

It’s very beneficial if the Scrum master has a project, software engineering, designing, and testing background, and of course they have to master Scrum and be a huge advocate of the Scrum framework. 

The key personality trait of a scrum master is that they should have a charisma and key skill to possess is coaching.

The main tasks of the Scrum master are:

• Organizing key sessions and workflow events (planning, retrospective etc.)
• Supporting the product owner
• Making sure that work that needs to be done is well understood (definition of work done)
• Encouraging team to improve
• Removing any obstacles for delivery
• Encouraging self-organization and cross-functionality

Scrum master deliverables:

• Manages Scrum workflow (team events)
• Educates all the stakeholders about the Scrum framework
• Helps to understand the backlog (bridge between the product owner and the team)
• Ensures regular progress of the team
• Remove all the obstacles wherever possible (managers, meetings, etc.)

Scrum Team

The team should consist of 5 – 7 people, plus the product owner and Scrum master. It’s almost mandatory that the team work full time on the project and that they are fully committed. 

It’s beneficial if they are frequently enough in the same room (every working day if possible,) or have the best possible remote work equivalent.

What’s even more important is that the team be cross-functional or interdisciplinary, meaning it has the necessary mix of skills to get the job done. 

The team should also be self-organized and provide psychological safety for the whole team. Communication in the team should be honest, and transparent, and mutual respect is mandatory.

The Scrum Workflow

Now that we know the main Scrum roles, let’s focus on the workflow. The Scrum workflow consists of four main events:

• Sprint planning and sprint execution (1 – 4 weeks)
• Daily Scrum
• Sprint review
• Sprint retrospective

Sprint planning

Sprint planning is about defining the scope of the work (from the product backlog), that will be done in the coming sprint. A sprint most often lasts for 1 or 2 weeks, but in some cases it can be up to 4 weeks.

Before sprint planning, backlog grooming should be done, namely making sure all the tasks are up to date and priorities are clearly set. During the sprint planning, the team reviews the backlog and selects the tasks that will be done in the following sprint.

Team members should sign up for tasks, which should drive better commitment. The selected task should be moved from the backlog to the sprint backlog. The sprint planning should take around 2 hours for a bi-weekly sprint.

In the sprint planning three main questions are addressed:

• What can be done in the following sprint?
• How will the chosen tasks get done?
• Why is the sprint valuable for stakeholders?

Daily Scrum (standup)

The daily Scrum is about ensuring daily commitments in front of peers. It’s an event that should take place each working day, at the same time and place. 

It’s important that the daily Scrum not last more than 15 minutes, and that’s why it’s recommended for the team members to stand during the meeting.

All the stakeholders are invited to the daily Scrum, but only the team speaks. Each member explains three things, with no detailed discussions (the discussions are done afterwards individually):

• What did I complete yesterday?
• What do I plan to complete today?
• Do I see any obstacles (risks, issues, dependencies, wrong assumptions etc.)?

It’s really important that no one comments during a Daily Scrum, but rather takes all the information as input for further discussions and organization of work.

Sprint review

The last parts of the Scrum workflow are the sprint review and retrospective. The sprint review is a detailed review of the work completed and the quality of the work done. 

An even more important part of the sprint review is delivering a release, since the main point of Scrum is frequent deliveries that give the necessary feedback on what the optimal next step is.

So, the finishing line of each sprint review should be a demo of the outputs presented to the stakeholders. In Scrum, the final sprint goal is called Increment, which is the usable end-product of a sprint. 

Only after getting the feedback should a new Scrum sprint should be planned. That’s the key part of agility.

Sprint Retrospective

In addition, at the end of each sprint, a retrospective should be done. The retrospective is about the constant improvement of the team. 

This is the hardest part of the Scrum workflow, but the most beneficial, since it encourages the team to become more and more efficient and build better relationships. 

During the sprint retrospective each team member should answer the following three questions:

• What went well?
• What could be improved?
• What should we stop, start, continue doing?

The answers to these questions should be valuable inputs for further improvements on how the team functions and gets work done.

The Scrum Artefacts

The third part of the Scrum framework, besides roles and workflow, is the Scrum “artefacts”. An artefact is an object that is made by a person, such as a tool or a decoration, but in Scrum, artefacts are advanced lists, plans, and descriptions of what needs to be done.

The main Scrum artefacts are:

• Product backlog
• User stories
• Sprint backlog

Besides these Scrum artefacts the Scrum framework also provides tools for planning and time management (planning poker), and estimating team velocity and how quickly team will deliver the tasks from the backlog. We’ll mention all these briefly in the following sections.

Product Backlog

The product backlog is a list of everything that will be delivered, ordered into a delivery sequence. We could say the product backlog is a type of to-do list, presented through user stories. 

The product backlog should be visible to everyone, but it’s in the domain of the product owner, who should regularly groom the product backlog.

The product backlog should list all the item types that need to be delivered, from new features, fixing bugs, solving performance and usability problems, and all other tasks, technical work and knowledge acquisition needed by the team in order to get work completed.

The items on the product backlog should be prioritized based on business value (value points), the size of an item (story points), and all dependencies and dates needed for an item to be delivered.

User Stories

User stories are a special way of describing what needs to be done. It’s a switch from a task-based perspective to the user-value perspective. User stories should be written based on a strictly defined formula, which describes the value provided by the team’s output. The formula goes along the lines of:

• A user story role (as a)
• A user story (I want… so that…)

An example of a user story is: 

As a registered user in X.com online shop, I want to receive an email after making a purchase so that I have a confirmation and proof of the order.

User stories should be small, independent, valuable, estimable, and testable. Each user story should also have a user story name and prioritization (Value Points / Story Points). Usually, every user story should also have:

• Definition of Done – when exactly a user story is considered completely done (Peer review, unit test, documentation, PO approval, etc.).
• Definition of Ready – what needs to be present before a team can start working on a user story (knowledge, equipment, dependencies etc.).
• Acceptance Test Criteria – what standards should be meet so the work can be considered done (user input, process, outcome).

Only the definition of done is an official part of the Scrum.

User stories are grouped together in two ways:

• Theme – A collection of independent, but related user stories (example: UX improvements)
• Epic – Value is delivered when the entire epic is completed (example: User management)

Sprint backlog

A sprint backlog consists of all items that are selected for the coming sprint. As mentioned, items are not assigned to the team members, but members should sign up, which provides better commitment. 

The sprint backlog is usually presented on a Kanban board, visually representing what’s on the to-do list, what’s in progress, and what’s already have been done during the sprint.

Item estimation

The Scrum framework provides a special way of time planning and estimating how long it will take to complete an item. There are three essential categories for making the estimations:

• Velocity: How much effort the team makes in one sprint (story points, ideal days)
• Burn-down chart: How much work remains
• Release burn-up chart: Represents total work, work in progress (WIP), and work completed

The estimations are made based on the Story Points, Ideal Time (effort) and Real Time (duration). And all estimations are done via a special method called planning poker.

Planning poker

In planning poker, members of the group make estimates by playing numbered cards face-down on the table. The numbered cards are based on an adapted Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89). 

By hiding the figures in this way (instead of saying them aloud), the group can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates.

The planning poker is done via the following process:

• The Product Owner provides a short overview of one user story to be estimated. The team is given an opportunity to ask questions and discuss to clarify assumptions and risks.
• Each individual lays a card face down representing their estimate for the story. During the discussion, numbers must not be mentioned at all in relation to feature size to avoid anchoring.
• Everyone calls their cards simultaneously by turning them over.
• People with high estimates and low estimates are given a soap box to offer their justification for their estimate and then the discussion continues.
• Repeat the estimation process until a consensus is reached.

The units used in planning poker can be duration days, ideal days or story points.

Scaling agile and Scrum

Scaling agile is how Scrum is scaled across the whole company, as well as across all departments and teams. 

Scaling Scrum is based on small, cross-functional team organizations and provides a framework how these teams can collaborate with each other while keeping the bureaucracy to a minimum.

There are several different frameworks for scaling agile, such as:

• SAFe - Scaled Agile Framework
• LeSS – Large Scale Scrum
• Scrum@Scale

Let’s look briefly at Scrum@Scale. In Scrum@Scale two new role in the workflow are presented. The concept of the team of teams requires some new roles and activities:

• The Chief Product Owner - The person responsible for setting the vision of the Scrum of Scrum, aligning the backlog priorities with all involved Scrum teams and stakeholders, and coordinating e a single backlog.
• The Scrum of Scrums Master - The person responsible for facilitating the Scrum of Scrum framework across the whole organization.
• The Scaled Daily Scrum - The goal of daily meetings is to understand collective progress towards goals and to address issues raised by participating teams. A representative of each team should attend this event to provide synchronization among teams.

Scrum@Scale presents two more teams: one is the Executive Action Team, which fulfills the Scrum Master responsibilities for the entire agile organization, where a higher number of Scrum teams are organized. 

The second team is The Executive Meta Scrum Team, which is responsible for the organizational vision, setting strategic priorities, and securing the budget. You can read more about Scrum@Scale here.

The 12 agile principles and the main Scrum values

In the agile manifesto, 12 agile crore principles are presented. These are the foundations of how agile should be done, and also the values Scrum was built upon. These 12 agile principles are:

• Customer satisfaction comes first
• Changing requirements are a standard
• Frequent deliveries should be made
• Measuring of progress is essential
• Sustainable development and constant improvement are a must
• Close cooperation with all stakeholders
• Regular adaptation to changing circumstances is mandatory
• Teams should be self-organized
• Simplicity is the key
• Technical excellence must be the team’s base
• Face-to-face conversations are the best
• There’s nothing without motivated individuals

Based on the 12 agile principles, the main Scrum dive values developed, which are:

• Commitment: Team members should individually commit to achieving their team goals, each and every sprint.
• Courage: Team members should have the courage to work through conflict and challenges together so that they can do the right thing.
• Focus: Team members should focus exclusively on their team goals and the sprint backlog; there should be no work done other than through their backlog.
• Openness: Team members and their stakeholders must agree to be transparent about their work and any challenges they face.
• Respect: Team members must respect each other to be technically capable and to work with good intent.

The main obstacles to Scrum and agile

Last, but not least, let’s look at the main obstacles preventing organizations and teams from doing work in an agile way and the obstacles faced when implementing Scrum. From the Scrum framework perspective, there are elements that are easy to implement, hard to implement and very hard to implement. 

Here’s a table representing the level of difficulty:

Easy	Hard	Very hard
Less documentation Fewer processes Scrum software (at start) Agile board (Kanban)	User stories Daily Scrum Sprint Retrospective Customer collaboration (user testing)	Item estimates Retrospective & Improvement Continuous Delivery

The most common barriers to implementing Scrum are organizational culture & traditional structure, not meeting basic agile prerequisites (one project, same room etc.), rock stars that assert how things should be done differently, and last but not least faking agile, meaning you are following the framework only half way. Poor customer collaboration and communication can also be added to the list. 

But...  to successfully complete a project today, the team must be agile.

They need a new set of tools to have a fighting chance of getting outstanding work done. At the end of the day, a big chunk of projects fail and never deliver the value they promised, simply because of rigidity, poor management, and no commitment. 

That’s what Scrum helps to solve, and it all starts with a foundation of understanding where the most value comes from when managing projects. Your focus should of course be on the things that drive the most value in managing projects.

Some value in managing projects	The most value in managing projects
Processes and tools Comprehensive documentation Contract negotiation Following a plan	Individuals & interactions Working (well-crafted) output Customer collaboration Responding to change (adding value)

If you want to be agile, you have to be serious about implementing the Scrum framework as a whole. There should be commitment from top management to each team member. 

Remember, it’s easy to write and talk about agile, but doing it is extremely difficult. But the winners know: the hard road becomes easy with time, and easy road becomes hard. So be and stay agile!