Scrum and How to Adopt It – the Definitive Guide

You’ve probably heard about Scrum. It’s that “thing” that should help you manage your projects and deliver value quickly. And that’s what you should want, because:

1. Business environment changes faster than ever. 

New markets, new customers, new requirements. You want to stay in the business, so you need to react quickly and offer your customer the best products that solve their problems. 

2. Project management is becoming increasingly challenging.

You can’t spend too much time analysing, planning and creating the product your customers want. If it takes too long, they won’t want it anymore. 

Now that you are considering or have already decided to use Scrum, you are probably asking 4 questions:

1. What exactly is Scrum?
2. Is Scrum suitable for me/my team/my organisation?
3. What do I need before I start using Scrum?
4. How do I actually use Scrum?

And we are going to answer all of them.

#1 What is Scrum?

According to the Scrum Guide (written by Jeff Sutherland and Ken Schwaber, the creators of Scrum):

Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.

If you look again at the two points about business environment and project management in the previous section, you can see that the definition of Scrum perfectly addresses them.

The Scrum Guide also says:

Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques.

We will dive deeper into the framework later in part #4, but we can already say that although Scrum addresses the problems you are trying to solve, there isn’t a definitive step-by-step manual on what you should do. 

On one hand, that is great, because every organization is different and there is not one process that fits them all. 

On the other hand, if you just started implementing Scrum in your organization, the boundaries might feel too broad and you would rather see concrete instructions and examples. We will address that in part #4.

Scrum vs agile

Scrum is often called an agile method, sometimes the terms are even used interchangeably. But “agile” is not mentioned in the definition… That is definitely confusing. 

What is agile project management?

Agile is an approach to project management where the product is delivered incrementally from the start to the end of the project. Incremental delivery allows the team to react and adapt to changes.

What is the difference between agile and Scrum?

There are multiple agile frameworks and Scrum is one of them. That means that Scrum is agile, but agile is not (only) Scrum (e.g. there is another agile framework called Kanban).

#2 Is Scrum for your organisation/team?

When to use Scrum?

When you develop or manage complex projects.

Complex projects contain some level of uncertainty. Uncertainty means that you don’t have all the information before the project starts. Examples might be:

• Running a long-term marketing campaign. 

You should definitely have a high-level plan, but that will change based on the intermediate results of the campaign.

• Building a house.

You can’t say the house will be built after exactly X days. Maybe you will find an archeological site when you start digging. Or it will rain too often. Or the investor decides they want a different colour of the walls when they actually see it.

• Creating a new piece of software. 

You can run into technical issues. Or the customer realizes that they actually wanted something different. Or they like it so much that they want to add new functions.

If there is no uncertainty, then you don’t need Scrum. It is sufficient to employ classical project management methods, when you plan the whole project at once. However, it is increasingly unlikely for projects to contain no uncertainty.

What can Scrum be used for?

For almost any kind of project.

If you google Scrum, you will most likely stumble upon at least one article about Scrum software development. Software developers quickly embraced Scrum because they’ve seen it too many times: Customers look at the finished software and find out it isn’t what they actually wanted. 

But that of course doesn’t mean that Scrum is only for software development!

(Did you know that hook-and-loop fasteners had their first breakthrough as a practical tool for astronauts?)

Authors of the Scrum Guide say that Scrum has also been used:

• in schools
• in government
• in marketing
• for managing the operation of organizations 

… and for managing “almost everything we use in our daily lives, as individuals and societies”.

Now when you know that Scrum is for you, you may wonder:

#3 What do you need to start using Scrum?

You should be prepared to communicate (a lot).

The Scrum Guide says that “the essence of Scrum is a small team of people.”

Scrum is done by people and its results are for people, so you will definitely need to communicate with them in order to:

1. Get buy-in from the stakeholders
2. Build your Scrum team
3. Establish Definition of Done (DoD)

Get buy-in from the stakeholders

Who are the stakeholders?

Generally, a stakeholder is a party that has an interest in a company and can either affect or be affected by the business [Investopedia], e.g. investors, employees etc.

In Scrum, the definition of a stakeholder is narrower: It is ”a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery” [Scrum Glossary].

Depending on the structure of your organisation, stakeholders can be: 

• your boss or manager,
• other managers or directors,
• customers/users.

Big organisations have different structures and processes than smaller companies with a couple of teams (or only one). You have to tailor your approach and communication with stakeholders to your organisation. 

We will provide you with the basic ideas that have to be delivered and answer most common concerns that usually come from the stakeholders.

Why do I need buy-in from the stakeholders?

Because if you start using Scrum, your outputs may change:

1. You will produce small and frequent increments to the product.
2. You will seek feedback on the increments.
3. You will give estimates (not exact dates set in stone) for when the features are delivered.

That may (and probably will) require stakeholders to change their behaviour and expectations, so they definitely have to approve it.

Maybe they were used to having a discussion about the requirements only in the beginning and then having a finished product presented to them. 

Now they will have to frequently and actively participate in product development. 

You need their buy-in for that.

Maybe they were used to get an exact delivery date right after the specification is finished.

Now they will have to accept that 1) the specification evolves with the product and 2) instead of the delivery date they will get estimates and frequent new increments.

You need their buy-in for that.

There is also one caveat hidden in the stakeholders’ buy-in – it is trust and confidence. The stakeholders need to have the trust in your team, your team’s abilities and confidence in them being able to deliver the final product. These things can often prevent proper buy-in. 

Make sure you have the trust at the very beginning!

How do I get buy-in from the stakeholders?

By explaining that they will get better results (and everybody will be happy in the end).

When they hear that they should actively participate in product development, they may think it’s just another thing they have to add to their busy schedules. 

Explain that their expertise and/or feedback are critical:

1. To deliver a valuable product – so the customers are happy.
2. Not to deliver redundant or useless features – so you don’t burn money and time (which also makes customers happy).

When they hear that there won’t be a definite specification before the work starts, they may worry that they won’t get what they want.

Explain that living specification allows you to incorporate feedback all the time. That means that there is actually a much higher chance they get what they want, because they will get a better idea of what is being built and what they want to change when they see partial increments.

If you can provide examples of past projects where the initial specification didn’t cover all the requirements and required extra work, then even better.

When they hear that they won’t get an exact delivery date, they may as well start panicking. 

Explain that you will provide estimates and continuously refine them based on the knowledge you gain during the project. 

It often happens that deadlines are set and then missed, sometimes by weeks or months. 

Did that happen on your past projects? Explain that instead of exact but inaccurate dates, you will provide broader but realistic estimates. There’s no point in having a deadline that can’t be met and everybody knows that long before.

Also, do not forget that a lack of specific tasks or detailed specification is not a free ticket to ride or to an anarchy of the team doing what they want. There always needs to be a high level vision. This vision is mostly covered by use cases:

Why do I need the results? What do I want to achieve with it? 

I do not need to dictate what it should look like. 

An example can be a rephrasal of the famous Henry Ford quote:

Specification reads (non Scrum way): A horse that can ride faster than other horses.

Use case (Scrum way): I need to get from Boston to New York in 4 hours.

Scrum team result: Here is your new car.

Build Scrum team

Maybe you are wondering if you can build a Scrum team just by taking your current team and putting a label “Scrum team” on it. But there are more requirements that a Scrum team has to fulfill than just being a group of people. Of course your existing team can become a Scrum team, but this process usually involves more work and effort than just labeling the people. 

What are Scrum team’s capabilities?

The Scrum Guide says that “Scrum Teams are self-organizing and cross-functional”. 

It also explains what is meant by self-organizing and cross-functional.

Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. 

That tells us two important things:

1. People in the team have to be given responsibility (and trust!) for their work. Micro-management is not allowed.

2. People in the team have to be able to take responsibility for their work. They can’t do stuff only when somebody tells them to do it. They can’t ignore problems just because nobody told them not to ignore them.

Let’s be honest: for some organizations, the idea may look even radical. On the other side, the change is inevitable. As stated in the introduction, the environment is changing faster than ever. To react accordingly, organisations have to change too.

John Kotter, an expert on change management and author of the acclaimed bestseller Our Iceberg Is Melting, lists “enabling action by removing barriers“ such as “inefficient processes and hierarchies” as one of the crucial steps in the process of leading change. 

Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.

It is clear that if the team is going to build a house, there needs to be a bricklayer.

But it always isn’t so straightforward, especially when the product is not a physical thing. 

If the team is going to run a social media campaign, they can’t be told that the graphic designer won’t be in the team and will supply them with images and infographics only later when they are done with another project. This way, the team wouldn’t be self-sufficient – it would depend on an external worker who is not part of the team.

The Scrum team works in cycles called Sprints. A Sprint is a time-box, usually 1-4 weeks, during which a product increment is created. The length of the Sprint is always the same for a particular team, but can vary between teams. We will talk about the Sprint organization in part #4.

What are the roles in the Scrum team?

The Scrum team consists of:

• a Product Owner,
• the Development Team,
• a Scrum Master. 

Product Owner

According to the Scrum Guide:

The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is the person who, in terms of a product specification (represented by Product Backlog), acts as a proxy between the Development Team and the outside world (represented by the stakeholders). 

The stakeholders might have different requests or opinions about the product. It’s up to the Product Owner to facilitate this communication and make decisions. They are the sole person responsible for managing Product Backlog:

The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.

So what makes a good Product Owner?

• Communication skills – the Product Owner has to actively communicate with the Development Team and the stakeholders about the Product Backlog.
• Decisiveness – the Product Owner has to process all the requests to add/remove/change items in the Product Backlog and decide if they are going to be fulfilled.
• Transparency – all the decisions about the Product Backlog must be visible, so that everybody sees what is being worked on next.
• Trust and empathy – the Product Owner has to trust both the Development Team and the stakeholders with their expertise and take it into account when making decisions.

A typical scenario might look as follows:

A stakeholder requests a new item to be added to the Product Backlog. 

The Product Owner analyzes it: Does the item bring value? How does it fit in with existing items in the backlog? What are the implications for the future? Will it require further changes?

The Product Owner then discusses the item with the Development Team. The team states it’s a complex feature that would take longer to develop, but suggests a change that would provide similar value but took shorter to develop.

The Product Owner then gets back to the stakeholders. Would they accept the changed item? Is the trade-off with shorter development time good enough? If yes, the Product Owner adds the changed item to the backlog. 

But maybe stakeholders have new suggestions and propose another compromise, so the Product Owner analyzes it again and the cycle continues…

Development Team

The Development Team consists of professionals (Developers) who do the actual work of delivering product increments. 

(We will talk about how the increments are planned, delivered and reviewed later in the Scrum events section.)

Development Team is cross-functional with the following implications:

• It’s self-organizing:

The Developers themselves decide how to turn Product Backlog items into increments. They are the experts in their domain and therefore they know best which tools, materials, technologies etc. to use. 

• There are no titles or sub-teams:

The Developers may have different skills or areas of focus (e.g. business analysis or operations), but accountability belongs to the Development Team as a whole.

Scrum wants to avoid situations like when Developer A says: “I haven’t done my part but it is not my fault, as I was waiting for Developer B to finish their part.” There has to be active communication between A and B trying to prevent this.

Basically, you need people in the Development Team who have the knowledge to work on the product and also can really work together as a team. They don’t have to (and can’t) be perfect from the beginning. More important is that they are willing to improve continuously (Scrum even provides a specific event for that – more on that in the Sprint Retrospective section.)

Scrum Master

Let’s again look what the Scrum Guide says:

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

This might seem very… abstract. Well, the Scrum Master is the most abstract role in the team, but still valuable. 

The most important thing is that the Scrum Master is a servant-leader for the Scrum Team.

Everything that the Scrum Master does is a service. They serve the Product Owner, the Development Team and the organisation. 

That of course doesn’t mean that the Scrum Master makes coffee for everybody and fulfills all their wishes. That way they would only be a servant, but they are supposed to be a servant-leader. The Scrum Master coaches and guides people on which of their behaviours are helpful and which should be changed in order to maximize the value created by the Scrum Team. The Scrum Master also teaches the team to keep the duration of the meetings within the time box.

Let’s get back to the situation from the previous section about the Development Team, with Developer A being blocked by Developer B. If such a situation occurs, the Scrum Master may step in and suggest that A and B have a discussion. Is there anything in B’s part that A can help with? If there is, it will be beneficial for the whole team.

So what makes a good Scrum Master?

• Servant-leader attitude – the Scrum Master has to be able to put their ego aside. Their mission is not to look awesome, but to help others be even more awesome than they already are. Actually, the ultimate goal of the Scrum Master is not to be needed anymore. 
• Empathy and assertiveness – the Scrum Master has to deliver their message in such a way that people are willing to accept it.
• Communication skills – virtually everything the Scrum Master does involves other people and communication is essential.

As you can see, the Scrum Master certification is not on the list. 

People often ask: Do I need a Scrum Master certification? 
The answer is: Yes and no.

Some organizations (especially large ones) require that as a formal proof of your skills. If you want to work in such an organization, you have to get the Scrum Master certification.

Tip: There are lots of companies providing Scrum training and certification. Some of them are more respectable than others. Always check which certificates are accepted by your potential employer.

But a certificate alone won’t make you a good Scrum Master. Of course you need theoretical knowledge of Scrum values and principles. A lot of information can be found online or in books. What is important is how to apply the knowledge. Qualities listed above enable that.

How many members should be in the Scrum Team?

First, let’s count the Product Owner and the Scrum Master as two members. 

The Scrum Guide doesn’t explicitly say they have to be different people – it talks about roles, not members. There are even teams where those roles are fulfilled by a single person. In general, such a practice is strongly discouraged. 

The Product Owner is supposed to make decisions about the product, and the Scrum Master is supposed to serve the team (including the Product Owner). These are different things and can sometimes be in conflict, so they should be done by separate people.

Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint.

There are many opinions on the size of the Development Team. The Scrum Guide provides an upper bound of 9 and no lower bound. Interestingly, Jeff Sutherland, one of the authors of the Guide, recommends 7 as the upper bound on his website. We recommend having 4-7 Developers. 

So, together, the Scrum Team should be 6 to 9 people.

Establish Definition of Done (DoD)

At the end of each Sprint, the team should deliver a “Done” increment to the product.

However, you first have to define what Done means. If it seems too trivial to even think about it, hold on! 

You would be surprised how expectations may differ among the team and stakeholders.

For example, in software development, one Developer may think that the work is done because the code was written. Other Developers may think that it should also be tested to be marked as Done. And the stakeholders expect to actually see the feature running in some environment they have access to. 

That’s why it’s important to agree on the Definition of Done. 

A meeting where key stakeholders and the team are present can be sufficient for that. The definition might be adjusted later, but again, they all (stakeholders + the team) must agree on that.

Now everybody is happy with the idea of using Scrum. The next question is: How do you actually do Scrum?

#4 How do you “do” Scrum?

The Scrum Guide says that Scrum is:

• Lightweight
• Simple to understand
• Difficult to master

We can already check the first two items off the list. Now let’s talk about the practical steps to check off the third. 

It won’t be easy – but remember that Scrum is about continuous improvement. You don’t have to get it right for the first time. What’s important is that you learn from it and do it better next time.

To master Scrum and get the work on the product done, you will need to:

• have Scrum artifacts,
• hold Scrum events,
• control the process.

Scrum artifacts

There are three Scrum artifacts:

• Product Backlog
• Sprint Backlog
• Increment

Product Backlog

What’s in the Product Backlog?

Product Backlog represents everything that needs to be done on the product. It is owned and maintained by the Product Owner. The requirements are represented by multiple types of Product Backlog items.

User stories are the most common way to capture product feature requirements. They are “short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system” [Mike Cohn]. 

A user story typically follows a simple template:

As a < type of user >, I want < some goal > so that < some reason >.

A couple of examples:

• As a customer, I want to add an item to the basket, so that I can place an order later.
• As a seller, I want to see all orders of my products, so that I know what goods to ship.
• As a customer, I want to receive an email confirmation of my order.

As you can see, the third part (“so that…”) can be omitted if it’s not needed.

Along with the user stories, the Product Backlog can also contain other types of items – e.g. technical tasks or epics. Epics are similar to the user stories, but usually represent bigger pieces of work than the user stories. They are then broken down into user stories during the Sprint Planning.

Epics, user stories, tasks – they are all valid Product Backlog items with different levels of granularity. 

Prioritisation of the Product Backlog

Another important characteristic of the Product Backlog is that it is a prioritised list of items. 

Items with the highest priority are on the top of the backlog and are going to be worked on first. They should also be more granular than the items on the bottom of the backlog.

The Product Backlog items are prioritised by the Product Owner in cooperation with the stakeholders and the Development Team. The Product Owner sets the priorities that are aligned with business needs but also respect interdependencies among the items. 

Sprint Backlog

A Sprint Backlog represents everything that is being worked on in the current Sprint. It is owned by the Development Team.

During the Sprint Planning, the Development Team takes items from the top of the Product Backlog and puts them into the Sprint Backlog. 

Increment

According to the Scrum Guide:

The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.

The first part of the definition (“The Increment is the sum of all the Product Backlog items completed during a Sprint”) suggests that Increment is the delta, the difference that was added during a Sprint. 

But the second part (“and the value of the increments of all previous Sprints”) seems confusing. Even Scrum.org, founded by Scrum Guide’s co-author Ken Schwaber, has a slightly different definition in the Glossary:

Increment: a piece of working software that adds to previously created Increments, where the sum of all Increments – as a whole – form a product.

(We see that even the creator of Scrum slipped into software development and used the term software. Please feel free to replace the word with your product.)

The second definition isn’t contradictory to the first one, but we think that it points more towards understanding the Increment as a delta that was created during a Sprint. 

Further in the article, we will use the term Increment to refer to the delta.

The Increment must also fulfill two more conditions:

• It must meet the Definition of Done.
• It must be in a usable condition – regardless of whether the Product Owner decides to release it.

Three pillars of empirical process control

Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known.

There are three pillars that uphold every implementation of empirical process control:

• Transparency
• Inspection
• Adaptation

Transparency

The Scrum Guide says that “significant aspects of the process must be visible to those responsible for the outcome” and that “a common language referring to the process must be shared by all participants.”

The Scrum team is open to the stakeholders about their work and how it is performed. The stakeholders know:

• How the work is specified and who is responsible – all their queries must go through Product Owner.
• How the work is performed – the team works in sprints and delivers a product increment at the end of each Sprint, according to DoD.

Inspection

Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work.

Who is a Scrum user? The Scrum Guide doesn’t mention this term anywhere else, but we think that all members of the Scrum team are Scrum users. 

The second part about inspection not being too frequent is important. Product Owners, Scrum Masters or their managers sometimes tend to micro-manage and constantly want to know where the Developers are and what they’re working on. This is generally considered a bad practice and gets in the way of work. 

Although the Guide doesn’t prescribe that, virtually every Scrum team uses a Scrum board to communicate their status both inside and outside.

Scrum board

Scrum board is a board with columns representing statuses and with cards representing Sprint Backlog items. It can also include one column reserved for Product backlog items. 

When the card’s status changes, the board is updated. The person who is working on the item is responsible for updating its status. 

The Scrum Master can educate the Developers on why it’s important to keep the board up-to-date, but it’s never Scrum Master’s responsibility to actually maintain the board. Updates of the board can be done operationally, or can be part of the daily standup meetings.

The board can be physical or digital. Physical board can be a whiteboard, a big piece of paper on the wall, or just an empty wall – something you can divide to columns and put post-it notes on. 

However, teams which are partially or fully remote, or just work from multiple sites, can’t use a physical board. Digital boards solve this problem. 

There are many software tools you can use to create and collaborate on a digital board, e.g. Jira, Trello or Lumeer. 

Depending on the tool you use, it can also provide extra functionality as reports or notifications on changes.

Adaptation

If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.

Inspection wouldn’t be useful if it wasn’t followed by adaptation. Adaptation is an opportunity to change either the product or the process of creating the product such that it brings more value.

If the stakeholders say that a product feature needs a change to be more useful, the original specification is adapted and the feature (therefore also the product) is changed. Change is made to what the team works on.

If the team realizes that they can get better results with a change in the way they work (e.g. using a new tool), they adapt their process and start using the new tool. Change is made to how the team works.

Scrum events

Scrum events are also called Sprint events because they happen inside Sprints. Sprint is the main event and the container for all other events.

The Scrum Guide prescribes 4 events which are all specifically designed to enable critical transparency and inspection:

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Some teams add another event to their schedule: Backlog Grooming or Product Backlog refinement. This can happen as a formal event or continuously.

All Scrum events are time-boxed – the upper limit is calculated from the length of Sprints.

Sprint Planning

During the Sprint Planning, the team collaboratively creates a plan of work that is to be performed in the Sprint.

Time box is 8 hours per 4-week sprint (4 hours for 2-week sprint etc.).

The Planning answers two questions:

1. What work will be done?

The team discusses the functionality that will be delivered. They take items from the top of the Product Backlog (with highest priority), but also take other factors (such as dependencies) into consideration.

2. How will the work be done?

The Developers design the solution, usually breaking down the Product Backlog items into smaller units. The Product Owner helps to clarify the selected Product Backlog items and makes trade-offs if the Developers realize that there is too much or too little work.

The Product Owner can’t tell the Developers how many of the items they should work on – the Development team makes the commitment to finish the items, so only the Development team can decide how much work to take on. They take into consideration their projected capacity and past performance.

What should the Sprint Planning look like?

The question can be rephrased as “What does the process of creating the Sprint Backlog actually look like?” That depends on granularity of the Product Backlog items, complexity of the items, maturity of the team etc. Below, we provide an example scenario, but don’t take this as the only correct way to run your Sprint Planning!

Example scenario of Sprint Planning

Part 1: Introduction of new items
The Product Owner introduces the items on the top of the Product Backlog. The Developers might already be familiar with the items because of previous informal discussions or Backlog Grooming sessions. We recommend this approach especially for software development, so that the Developers can think about the items before the Planning and save time during the meeting. Of course the solution should be designed together, but the Developers may first need time to think individually to come up with ideas.

Part 2: Estimating
The Developers estimate Product Backlog items (Product Owner and Scrum Master don’t do any estimates). Again, this can also be done outside the Planning session. Estimating is a broad topic and we will discuss it later in the corresponding section.

Part 3: Selecting the items and design
The team agrees on what items will be put into the Sprint Backlog. That means that they need to do (at least high-level) design and assign the work. They may split the user stories into smaller tasks. They discuss the dependencies and how to order the items so that nobody will be blocked.

Daily Scrum

Daily Scrum is held on every day of the Sprint. The Development Team inspects progress towards the goal of the Sprint and plans the work for the day.

It is time-boxed to 15 minutes, so it is often also called the Standup Meeting (or just the Standup) to highlight the fact that it should be quick. The team can even stand during the meeting and doesn’t have to reserve a special meeting room with seats for everyone. 

What should the Daily Scrum look like?

The structure of the meeting is set by the Development Team. The Scrum Master only ensures that the meeting happens. 

Sometimes, the Product Owner or other managers tend to impose the structure themselves and treat the Daily Scrum as a status update. 

It is the Scrum Master’s task to teach them that the meeting is owned by the Development Team. Other participants shouldn’t disturb it or change its structure. 

The most common structure is that every Developer answers 3 questions:

1. What did I do yesterday (that helped the Development Team meet the Sprint Goal)?
2. What will I do today (to help the Development Team meet the Sprint Goal)?
3. Do I see any impediment (that prevents me or the Development Team from meeting the Sprint Goal)?

The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt or re-plan the rest of the Sprint’s work.

Sprint Review

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.

The Scrum Team and key stakeholders invited by the Product Owner attend and time box is 4 hours for a 4-week sprint. 

It is not necessary for all the stakeholders to attend (there may be too many of them), if those who attend have the knowledge and competence to provide feedback and participate in the discussion. 

The Sprint Review should happen before the Sprint Planning as it provides a valuable input to the plan.

What should the Sprint Review look like?

The Sprint Review is an informal meeting, and rather than being a status update, its aim is to get feedback and support collaboration. Therefore, it should include the following elements:

• Presentation and discussion of the Increment
• Discussion of what to do next

Presentation and discussion of the Increment

The Product Owner explains which Product Backlog items have been done. The Development Team demonstrates them and answers the questions.

The Scrum Guide also says that “the Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved” which partly overlap with what should be discussed during the Sprint Retrospective (described in the next section). 

We recommend discussing problems caused by external circumstances, not problems with the Scrum process itself. 

For example: The team realized that the component (physical component / food ingredient / software library…) they intended to use is not available. They managed to find a replacement, but it took some time and they couldn’t finish the Product Backlog item on time.

Discussion of what to do next

The Product Owner discusses the Product Backlog as it stands and all attendees collaborate on what to do next. 

Next shouldn’t be next in the context of sprints and delivery dates, because only during the planning the team decides what to deliver in the next Sprint. 

Rather, next should be about priorities, as we want to answer the question: What is the most valuable thing to do next?

The Scrum Guide in the end says that “the result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities”.

Sprint Retrospective

Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

It occurs after the Sprint Review and before the Sprint Planning and its time box is 3 hours for a 4-week Sprint. 

What should the Sprint Retrospective look like?

Sprint Retrospective is an internal meeting of the Scrum Team – nobody else can attend. 

It should also be a positive and informal one, so that nobody is afraid to present their opinions and discuss what didn’t go well. 

There are 3 basic questions which should be answered. It is not necessary to take turns and make every team member answer, it should rather be a collaborative activity:

1. What went well in this Sprint? (What should we continue doing?)
2. What went wrong in this Sprint? (What should we stop doing?)
3. What should we improve? (What should we start doing?)

Then, the team creates a plan on how to implement the improvements – to perform the adaptation. 

Some may be short-term activities (e.g. start using a new tool to speed up the development), some long-term ones (e.g. to discuss user stories in greater detail during the planning to reduce uncertainty during the Sprint).

We also recommend looking back at the previous retrospective and inspect if the improvements set there were implemented.

Product Backlog refinement (Backlog Grooming)

Product Backlog refinement meeting or Backlog Grooming is not prescribed by the Scrum Guide and thus is optional.

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. 

It reflects the need to continuously change and update the Backlog. This activity also happens during the Sprint Review, but that might be too late to discuss the items from the top of the Backlog, as the Sprint Planning usually happens on the same day.

The Scrum Team decides how and when the refinement is done. The Refinement usually consumes no more than 10% of the capacity of the Development Team.

Not all teams need to hold refinement meetings. Some are able to perform the activity continuously, e.g. through informal conversations during the Sprint. 

We recommend holding the meeting (even a short one) at least for the first couple of sprints. It helps to reduce uncertainty and complexity when doing the Sprint Planning, so that the planning is kept within its time box.

If the refinement session happens in the middle of the sprint, the Developers become familiar with what will probably be worked on next, and knowing the big picture may impact their decisions when working on the current Sprint Backlog items. 

It also provides valuable information to the Product Owner who may use it to update the priorities.

Estimating

Although the Scrum Guide mentions the Product Backlog items estimates in several places, it doesn’t provide more details on how to actually do the estimating. 

However, accurate estimating is critical from a business perspective. It allows the team and the stakeholders to project into the future and know (roughly, not exactly) when the increments will be delivered.

The Estimating is done mainly while doing the Product Backlog refinement, but some teams also estimate or re-estimate items during the Sprint Planning. Still, we recommend doing most or all estimating outside the planning meeting.

Who does the estimating?

Only the Development team – the Scrum Guide confirms that:

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

Should we re-estimate?

Yes. Estimates are not set in stone – they are called estimates for a reason. 

If you want to provide good projections to the business and to the stakeholders, you want to have good estimates. We intentionally use the word “good”, not “best”, because trying to get estimates 100% perfect can be counterproductive. 

If you spend too much time doing the activity, you will have less time for the actual work. We assume that the 80/20 rule applies here – with 20% of effort, you get 80% accuracy.

As the Product Backlog item moves from the bottom of the backlog to the top, the specification becomes clearer and uncertainty decreases. The initial estimate of an item from a couple of Sprints ago may need to be changed because:

• The team gained more information about this item when working on related Product Backlog items. Maybe they realize that some work can be omitted (or added), or that the requirement has changed.
• The item was too big and was split into a couple of smaller items. It’s possible and perfectly all right if the sum of estimates of the smaller items is higher or lower than the original estimate of the big item.

Then, you change your projections based on that new estimate. That might sound like something the stakeholders wouldn’t like – what if they want definitive projections that don’t change? 

We offer two arguments for that:

1. Provide the stakeholders with intervals, rather than with exact dates. 

E.g. “In the next 4-5 sprints, we expect to have these 3 epics completed.”

Scrum is for complex products and complex products always involve uncertainty that can never be reduced to zero. It’s rare to get the exact date right, so it’s actually more honest to provide an interval.

2. Assume that the stakeholders want the projections for a reason – to base other activities on them.

If the feature is to be delivered later than originally expected, that it is going to be delivered later and that’s it. They can be aware of it as soon as you are or they can learn it only after the expected delivery date/interval is missed.

What units should we estimate in?

Mike Cohn describes two types of estimating in his book Agile Estimating and Planning (which we highly recommend):

• Estimating in ideal days
• Estimating in story points

For both units, he recommends not to use arbitrary numbers, but one of the two estimating scales:

• 1, 2, 3, 5, 8… (Fibonacci sequence)
• 1, 2, 4, 8, 16… (every number is twice the previous)

This approach is based on the fact that people are good at relative estimates, e.g. “I expect this new task to be 2x more difficult than that old task, so if the old one is 2, then the new one is 4” (using the second scale). 

You can also think about those numbers as buckets – e.g. if the item doesn’t fit 3, then it’s 5 (using the first scale). If you put the item into the bigger bucket, you also create a small buffer and it’s more likely that you don’t finish it later than you predicted.

Estimating in ideal days

This is a time-based estimate.

An ideal day is a day which the Developer spends working only on the assigned task – without interruptions, meetings, emails, task switching etc. 

Ideal time can’t equal elapsed time because most of the days (if any) aren’t ideal. That means that you need to find a coefficient by which you multiply the number of actual days and get the number of ideal days. It might be somewhere between 0.6 and 0.7 (60% to 70%), but you will see the number for your team after a couple of sprints.

Estimating in story points

This is a size-based estimate. 

A story point is a unit of size and complexity. The Development team decides what one story point represents. It should be a piece of work that is small and that all Developers are familiar with.

If the Developers worked in the kitchen, then cutting an onion could represent one story point (we assume that every person working in the kitchen knows how to cut the onion!).

Then, when the Developers have mutual understanding of one story point, they use it as a reference point when estimating Product Backlog items.

And how do you do projections with story points? By calculating the velocity. Velocity is the average sum of story points of completed items in the sprint. 

Only those items which are done count – there are no partial achievements like “We did half of this 8-point item, so let’s count 4 points as done.” The unfinished item will be finished in the next sprint and the sums of story points from this sprint and the next sprint will average themselves out.

You will need a couple of sprints to know what your velocity is. Then you sum the estimates of your Product Backlog items, divide it by the velocity and get a projected number of sprints it will take to finish those items.

Velocity can change in time. As the team improves, they may be able to develop faster. Or some members leave and the speed of development decreases. If you regularly recalculate the velocity, your projections will get more accurate.

Ideal days vs story points

Estimating both ideal days and story points has positives and negatives, and you need to choose which better suit your needs.

At first sight, ideal days might look like a clear option – you can easily do time estimates instead of using some abstract units of size (such as story point). 

On the other hand, every Developer is different and the same item can take one Developer one hour and another Developer two hours. With story points, they can assign (almost) the same size and complexity to the item, even if it takes each Developer a different amount of time to complete it.

How should we do the estimating?

Planning poker is the most common technique. 

(Don’t worry, it has nothing to do with poker except that it uses cards.)

You need a set of cards (i.e. pieces of paper) for every estimator (Developer). Put numbers from the estimating scale on the cards (one number per card), so you have for example cards with 1, 2, 3, 5, 8, 13, 20, 40, 100. Clearly, this scale is not a perfect Fibonacci, but still it is commonly used.

And how to “play” the Planning poker?

Planning poker rules

Repeat the steps for every Product Backlog item that is to be estimated:

1. The Product Owner reads the description of the item and answers all the questions.
2. Each Developer privately selects a card with their estimate.
3. The team waits until everybody has a card selected.
4. Simultaneously, all cards are shown. If everybody has the same number, you end here.
5. If there are differences, the Developers start the discussion. They want to explain to the team why they chose that card.
6. After the discussion, return to step 2 – repeat the process of selecting the cards and discussion until the team agrees on one number.

Most of the time, one or two rounds should be sufficient.

Conclusion

Scrum is still considered a novel way of working (especially outside the software development field) and can bring a lot of value when implemented in a broad range of fields. 

Normally, when reading The Scrum Guide, people end up with even more questions than they had at the beginning. In this article, we tried to address most of the typical questions. Should you have some more that are still unanswered, get in touch with us and we can update the article.

Frequently Asked Questions