EXIN Agile Scrum

Foundation Workbook

2
Scrum Framework

Page 29
EXIN Agile Scrum
Foundation Workbook

Scrum Framework

You now have an abstract understanding of Agility, and you might have wondered how it is
possible to make it work. Well, Scrum is one of the answers to such a question; one of the
best answers actually. Most of the Agile companies use Scrum nowadays:

Others
34%

Scrum
52%

Scrum+XP
14%

Scrum does not belong to a certain organization, in the way that PRINCE2 or PMBOK Guide
do, so there are different interpretations of it available in various resources. The most
credited resource amongst all of them is scrum.org, defined in a very short guide called
Scrum Guide. This guide is a very good reference, but it is not a self-study material. We have
kept this part of the book compatible with Scrum Guide.

Quick Overview of the Scrum Framework

Each Scrum project is done in a number of Sprints. “Sprint” is the Scrum term for “iteration”.
We use a Product Backlog to define the remaining scope of the product. We pick a number
of items from the top of the Product Backlog to be done through the current Sprint. We run
Sprints as many times as required, until:

1. the project is finished, because:

a. all the items in the Product Backlog are done;
b. the customer has realized that the latest iteration is enough, and there is no
justification to spend more time and money adding more features;
2. the project is terminated for some reason (e.g. it is not justified any more).

Page 30
EXIN Agile Scrum
Foundation Workbook

The next figure shows an overview of the framework:

Product
Backlog Product
Backlog Product
Backlog Product
Backlog

Sprint Backlog Sprint Backlog Sprint Backlog Sprint Backlog

Sprint #4 Sprint #5 Sprint #6 Sprint #7 Sprint #8

Increment #4
Increment #5 “Done”, and
Increment #6
Increment #7 potentially
releasable

To be applied
Feedback Feedback Feedback Feedback to the Product
Backlog

Sprint Daily Sprint Sprint

Planning Scrum Review Retrospective

Sprint #6

See “Sprint #6” as an example: each Sprint itself has a number of timeboxes inside:

 Sprint Planning: a short timebox for selecting the user stories from the top of the
Product Backlog and creating the Sprint Backlog;
 Daily Scrum: a 15 minute timebox to collaborate and coordinate on a daily basis;
 Sprint Review: for demonstrating the increment to the customer and receiving
feedback;
 Sprint Retrospective: for reviewing the Sprint and planning for improvements.

There are three roles in Scrum:

 Product Owner – this person is responsible for creating and maintaining the Product
Backlog, which requires constant communication and collaboration with the
customer;

Page 31
EXIN Agile Scrum
Foundation Workbook

 Scrum Master – this person ensures that the Scrum framework is followed entirely
and correctly, which requires coaching, training, and problem solving;
 Development Team – a set of technical, yet self-organized and cross-functional
experts who develop the solution.

Note: “programmers” are called “developers” in some companies. In Agile literature, a

“developer” is anyone who contributes to the production of the final solution. The term
“developer” can refer to analysts, solution designers, UI designers, programmers, testers,
etc.

The Scrum framework will be explained in the three following chapters:

 Scrum Roles, which explains the three roles in more detail;

 Scrum Events, which explains all the timeboxes defined in Scrum, and also the
development and management lifecycle of the framework;
 Scrum Artifacts, which explains the management products/concepts required in
Scrum (e.g. performance monitoring).

Scrum Roles

Scrum Team
There are three roles in a Scrum project; no less, and no more. We are not allowed to define
any other roles, because it is harmful to the unity of the team, and it is not compatible with
the philosophy of Scrum.

Page 32
EXIN Agile Scrum
Foundation Workbook

A Scrum Team consists of the following three roles:

Product Owner Scrum Master Development Team

1 person 1 person 3 to 9 people

Full-time or part-time Full-time or part-time Full-time (recommended)
Business-oriented Scrum coach and facilitator Specialists

The term “Scrum Team” refers to all the project team members: everyone internal to the
project. Scrum Team members usually have only one of the three standard roles of Scrum:
Product Owner, Scrum Master, or Development Team member. It is possible, however, for a
single person to be assigned to more than one of the standard roles, but it is not
recommended.

The Scrum Team is a part of the performing organization (the company which executes the
project either for itself or as a contractor for an external customer).

Other persons can also be involved in the project, but they are not considered internal to
the project and Scrum theory does not have much to say about them. They should have a
certain set of behaviors though, to make it possible for a Scrum project to succeed.

The customer (either internal or external) should understand and adopt the Scrum
framework too, as the relationship between the customer and the Scrum Team and the way
we deliver the project completely changes when we switch to the Scrum framework.

The Scrum Team has two essential characteristics:

 Self-organized: The Scrum Team manages its own efforts rather than being managed
or directed by others. In traditional methods, management efforts are separated and
centralized; a subset of the project team is responsible for project management, and
others are only responsible for specialist activities. However, management and
specialist efforts are not separated in Scrum.

Page 33
EXIN Agile Scrum
Foundation Workbook

 Cross-functional: The Scrum Team has all the expertise and competencies needed to
get the job done without any help from outside the team.

These two characteristics are designed to optimize the flexibility, creativity, and productivity
needed for the Agile environment of Scrum.

Role 1: The Product Owner

Product Owner Scrum Master Development Team

1 person 1 person 3 to 9 people

Full-time or part-time Full-time or part-time Full-time (recommended)
Business-oriented Scrum coach and facilitator Specialist

Each project needs a business-oriented person, aimed at maximizing the business value of
the product and the work of the Development Team. In Scrum, this person is called the
Product Owner. Product Owners, like the two other roles, are from the performing
organization, rather than from the client side. There might be one or more people from the
client side assigned to manage the product, but they would not be called Product Owners.

This role belongs to one person. There can be a committee to handle the responsibilities of
this role, but in such a case, there should be one person representing this committee, and
we call this one person the Product Owner.

They do not need to have application area knowledge of the project; they are focused on
the business aspects. In software development projects, for example, Product Owners do
not need to be developers themselves; they just need to know a little about development,
and a lot about how the business operates.

The Product Owner is responsible for the Product Backlog. The Product Backlog is a
prioritized list of items (usually user stories) that the client expects from the project; this is
the main planning tool in Scrum. It is also the responsibility of the Product Owner to make
sure that each item (user story) is easy to understand for the Scrum Team, and other
stakeholders.

Page 34
EXIN Agile Scrum
Foundation Workbook

Product Owners should communicate effectively with the customer (the inevitable success
factor in every project management method), and use the information to keep the Product
Backlog updated with all the changes. They also measure the performance of the project,
forecast the completion date, and make this information transparent to all stakeholders.

Communications
Requirements

Communications

Performing Organization /
Customer Scrum Team

Product Owners understand the business, so they can rank each Product Backlog item based
on its return on investment as well as any other factor they find suitable for the business
point of view of the project. The items will be sorted based on their business value (or just
“value” for short), so the higher they are on the list, the sooner they will be developed by
the Development Team.

The entire organization must respect the Product Owner’s decisions for the project to be
successful. No one, not even the CEO, should allow themselves to try to override those
decisions. No one should tell the Development Team what item to deliver, except for the
Product Owner, who sets and orders the items. A Product Owner’s decisions might be
influenced by others, but s/he must have the final say.

Product Owners might delegate some of their responsibilities (such as preparing the list of
items for the Product Backlog) to the Development Team, but they stay accountable for
them.

Page 35
EXIN Agile Scrum
Foundation Workbook

Role 2: The Scrum Master

Product Owner Scrum Master Development Team

1 person 1 person 3 to 9 people

Full-time or part-time Full-time or part-time Full-time (recommended)
Business oriented Scrum coach and facilitator Specialist

Scrum Masters are those who fully understand Scrum, and help the Scrum Team by
coaching them, and ensuring that all Scrum processes are implemented correctly. The
Scrum Master is a management position, whereby the Scrum Master manages the Scrum
process, rather than the Scrum Team. S/he is a servant-leader for the Scrum Team.

Besides ensuring that the Development Team understands and uses Scrum correctly, the
Scrum Master also tries to remove impediments to the Development Team, facilitates their
events, and trains and coaches them.

Scrum Masters help the Product Owners too, by helping or consulting them on finding
techniques, communicating information, and facilitating related events.

The responsibilities of Scrum Masters are not limited to the Scrum Team. They should also
help those outside the Scrum Team understand the appropriate interactions with the Scrum
Team in order to maximize the business value. The Scrum Master usually leads the
organization in its effort to adopt Scrum.

It is possible for a single person to be both a Scrum Master, and a member of the
Development Team, although this is not recommended. Being a Scrum Master of a normal
project might not occupy 100% of the time of a person; in this case, the best solution is to
assign that same person as the Scrum Master in more than one project, rather than making
them a member of the Development Team.

Most of the internal and external communications about the Scrum process are done by the
Scrum Master, while most of the internal and external communications about the content
of the project are done by the Product Owner. Note that the Scrum Master is not involved in

Page 36
EXIN Agile Scrum
Foundation Workbook

the content (the meaning, estimation, business value, etc. of the user stories, or the content
of the increments).

Role 3: The Development Team

Product Owner Scrum Master Development Team

1 person 1 person 3 to 9 people

Full-time or part-time Full-time or part-time Full-time (recommended)
Business-oriented Scrum coach and facilitator Specialist

Members of the Development Team are application area experts who are responsible for
delivering backlog items, and managing their own efforts.

They should be cross-functional: being capable of doing the A to Z of each Product Backlog
item. They should be self-organized: find their own way instead of receiving orders. They
should be aligned with the goal of the project instead of working blindly. A task might be
assigned to a single member during the Sprint, but the whole Development Team will stay
accountable for that task; no individual owns any task.

The Development Team delivers the final product of the project in step by step Increments.
They always work in a product-based way.

It is highly recommended for members of the Development Team to work full-time in a

single project, to stay focused and agile. The composition of the Development Team should
not change frequently. If there is a need to change team members, then this change should
not happen during a Sprint. At any time, there will be a short-term decrease in productivity
when the composition of the team changes.

Scrum is mostly effective when there are 3 to 9 Development Team members. For large
projects, we can use a scaled model with multiple Scrum Teams.

Page 37
EXIN Agile Scrum
Foundation Workbook

Other Roles
You might have the temptation to give Development Team members more specific titles,
such as designer, tester, quality inspector, and team leader; but Scrum does not allow this!
All members should have the same role, and the same title: Development Team member.

Scrum is totally dependent on collaboration and team-work. Development Team members

should be united and completely aligned with the goal of the project. If you give them
different titles or roles, they will focus on their own particular role in the project instead,
and they might not pay enough attention to the final product. Each Development Team
member is responsible for all the outputs created in the Development Team, even though
each of them might be focused on a specific set of tasks.

Who Is the Project Manager?

Now that we have reviewed all the Scrum roles, you might ask yourself, who is the project
manager?

The answer is simple: there is no such role in Scrum; and none of the three roles of Scrum
act as a traditional project manager.

Some people consider the Scrum Master to be the equivalent to a traditional project
manager; but this is not true, because the Scrum Master’s responsibilities are very different
than those of a traditional project manager. Scrum Masters are not responsible for planning,
for example.

Others might consider the Product Owner to be the equivalent to a traditional project
manager which is also not correct. Even though they are responsible for parts of the
planning and monitoring of the project, for example, planning and monitoring is also
partially done by the Development Team. Besides that, managing the framework is also a
project management responsibility, which is done by the Scrum Master.

So, a better question to ask is: what happens to project management?

The project management responsibilities are distributed among the three roles of Scrum
and there is no centralized project management in Scrum.

Pigs and Chickens

A pig and a chicken were hanging out, when the chicken suggests they open a restaurant.
“What should we serve?” the pig asks enthusiastically. The chicken replies “Ham and eggs”.
The pig does not accept, claiming that “I would be committed, while you would be only
involved”.

The whole Scrum Team are the pigs in this analogy, while the rest of the stakeholders,
including the customer and senior management are just chickens.

Page 38
EXIN Agile Scrum
Foundation Workbook

It is essential to differentiate the pigs and chickens in any project, to increase productivity.
Chickens do not have a direct authority in the project execution.

Scrum Events

Introduction to Scrum Events

Sprint Daily Sprint Sprint

Planning Scrum Review Retrospective

Sprint

There are five events in a Scrum Project:

1. Sprint: Each Scrum project is a set of Sprints. A Sprint is a container for the four
other events (as represented in the above diagram), development effort, and the
maintenance of the Product Backlog.
2. Sprint Planning: Sprint Planning is the first event inside a Sprint. The Scrum Team
plans the items they are going to deliver in the Sprint and the way they will deliver
them.
3. Daily Scrum: The Development Team starts working on the objectives of the Sprint
as soon as Sprint Planning is completed. During the Sprint, the Development Team
holds a daily meeting (15 minutes) to coordinate the work for the next 24 hours. This
meeting is called the Daily Scrum.
4. Sprint Review: Before the end of the Sprint, the Development Team presents
(demonstrates) the outcome of the Sprint to the customer and receives feedback.
This meeting is called Sprint Review (also known as Sprint Demo).
5. Sprint Retrospective: After the Sprint Review and just before the Sprint is over, the
Development Team holds an internal meeting to review the Sprint and use it to
improve the process (lessons learned) in the next Sprint. This meeting is called Sprint
Retrospective.

These events are designed to enable critical transparency, inspection, regularity, and
adaptation. We prefer to use these predefined meetings with fixed objectives and maximum
durations (timeboxed) instead of ad-hoc meetings, which usually waste our time.

Timeboxing
There is an essential concept in Agile methods, called timebox: a predefined maximum
duration of time. In order to maximize productivity, all the Scrum events must be
timeboxed.

The duration of a timebox should be agreed upon and fixed. We are free to change the
duration based on lessons learned, but not frequently, and never based on single occasions.

Page 39
EXIN Agile Scrum
Foundation Workbook

For example, we are not allowed to say that “we have a lot to do this time, so let’s increase
the duration for this particular timebox”. What we are allowed to say is “based on the
previous ten timeboxes, we realized that the duration of our timeboxes is not suitable, and
a 30% increase in duration might better fit our needs. So, let’s increase it from now on”.

Suitable Workspace
Scrum events are communication tools, and it is important to prepare a suitable
environment for them. One of the requirements is to have the team co-located in a single
room, instead of having them distributed in their organizational departments, for example.
This improves the relationship among team members and facilitates their collaboration.

Osmotic communication
Having team members co-located in a single room is not just about making conversations
easier, but also about osmotic communications, where people can gain useful information
by overhearing, and get involved and help each other as needed.

It is good practice to maximize osmotic communications. It is mainly done by proper co-

location, but even distributed teams can benefit from it by applying some simple rules; e.g.
whenever you want to send an email to a peer, copy everyone in.

Co-locating the team and having osmotic communication is mandatory in the Crystal family
of Agile methodologies, including Crystal Clear.

Crystal methods are focused more on people, interaction, community, skills, talents, and
communications in the first place, rather than processes.

Managing Distributed Teams

It is highly preferable to have co-located teams that work together in a single project room.
However, we might need to have distributed teams sometimes, with people in other cities
or even countries. In the worst case, they might be living in totally different time zones,
which makes collaboration much harder.

It is still possible to use Scrum with distributed teams, but we should make the best use of
the modern technology to facilitate their interactions and expect a rather lower productivity
level.

Event 1: The Sprint

Sprint Daily Sprint Sprint

Planning Scrum Review Retrospective

Sprint

Page 40
EXIN Agile Scrum
Foundation Workbook

Each Scrum project delivers the product in a number of iterations, which are called Sprints.
An Increment is developed in each Sprint. An Increment is a potentially releasable part of
the final product. An Increment is a sum of all Product Backlog items completed so far in a
project, and this Increment keeps getting bigger after each Sprint. Therefore, you can
consider each new Increment at the end of a Sprint to be an updated version of the previous
Increment with new features and functionalities. Increments may or may not be actually
released (put into use), but should always be potentially releasable.
Customers usually request changes when they see the Increment (during the Sprint Review),
and we add these new requests to the Product Backlog.

Sprint #5 Sprint #6 Sprint #7 Sprint #8 Sprint #9

Increment #5 Increment #6 Increment #7 Increment #8

Sprint is a timeboxed event, which means we should fix its duration at the beginning of the
project and not change it. Sprints are usually fixed at one month or less.

An important point is that we do not change the items of the Sprint Backlog after the Sprint
is started, and the plans are set. The Sprint Goal (discussed further in Sprint Planning) should
not change either. The Product Owner and the Development Team might try to clarify and
renegotiate the scope as more is learned about the items to be delivered, but they will not
change the Sprint Backlog stories. Even the composition of the Development Team should
not change during a Sprint. These constraints are designed to make it possible to focus and
get things done.

Each item (user story) in the Product Backlog should normally be developed in a single
Sprint as this is much easier to manage. The Product Owner and the Development Team
select a number of items from the top of the Product Backlog (this has already been
prioritized by the Product Owner) and aim to get them “Done” (100% complete). We want
them to be really “Done” when the Sprint is over, and create an Increment. An Increment is
the sum of all the completed items created during the current Sprint and all previous
Sprints.

It is important to agree on a definition of “Done” at the beginning of the project. We will not
call something “Done”, unless it fits the definition. A 99.999% completed item is not
considered as “Done”, it would not be part of the Increment, and it would not be
demonstrated to the customer at the Sprint Review.

Page 41
EXIN Agile Scrum
Foundation Workbook

Setting the Duration of the Sprints

Most companies use Sprint timeboxes of 2 to 4 weeks. If we use Sprints longer than one
calendar month, it is likely that the unapplied changes will become large enough to create
problems. This will increase the complexity and risk. Therefore, we should keep the Sprints
to no more than one calendar month. Sprints should not be too short either, because we
would not be able to produce complete Backlog items during it. Our goal is to deliver the
final product item by item, inside the Sprints; we do not want to split a single Product
Backlog item across several Sprints.

Another important point about setting the duration of the Sprints is the amount of
adaptation needed for the project. A project with two-week Sprints receives almost twice as
much feedback and opportunities for adaptation as a project with four week Sprints.

We do not change the duration of Sprints on an ad-hoc basis. E.g. we are not allowed to say
that we have to develop lots of user stories this time, so let’s have a longer Sprint. However,
if we realize that the duration we have chosen is not appropriate for the project, we are free
to revise it for the rest of the Sprints. We do not expect to make such changes often.

Overtime Work, Buffers, etc.

There are two common questions about managing the Sprints:

 Are we allowed to do overtime work to complete all the Sprint Backlog items? It is
not forbidden, but highly discouraged. One of the Agile principles is to have a
constant pace, to keep the quality of the product and the morale of the team. So, it
is better to avoid overtime work. Note that the Sprint Backlog only contains what we
estimate we can get done during the Sprint, and we do our best to deliver all of
them, but there is no guarantee. All projects have a high level of uncertainty,
especially IT projects.
 Is it possible to have a buffer or contingency time for the Sprints to make sure that
we can get everything done? Again, you should not be worried about getting
everything done. The Sprint is timeboxed and we do not extend it, not even for one
day. There are also no buffers at the end of the Sprints. The team might prefer to
only assign a percentage of its capacity (e.g. 80% or 90%) to develop the user stories
and the rest for the pet projects, spikes (research on the same project), etc.

Canceling Sprints
Even though backlog items in each Sprint are frozen and do not change, the Product Owner
has the authority to cancel a Sprint. This can happen when the Sprint Goal becomes
obsolete, due to changes in the Product Backlog, strategies, approach, etc. When a Sprint is
canceled, the items that are “Done” will be reviewed and accepted, and the rest of the

Page 42
EXIN Agile Scrum
Foundation Workbook

items (not started or partly complete) will be put back into the Product Backlog to be done
in the future.

Sprint 0
There is no such thing as Sprint 0, and there is no difference between the first Sprint and the
rest of the Sprints. We just start delivering potentially releasable increments as soon as the
project is started, and do not spend any time designing or preparing before it.

Well, we have to spend a few days at the beginning, creating an initial state of the Product
Backlog, enough to define the first one or two Sprints before starting the Sprints. However,
this duration should be limited, and we do not wait until every user story is defined and
estimated, because it is not an adaptive approach.

Event 2: Sprint Planning

Sprint Daily Sprint Sprint

Planning Scrum Review Retrospective

Sprint

The Development Team does not wait until the Product

Backlog is 100% planned (all requirements are gathered and
cleared) to start developing the project. As soon as the Product
Backlog is mature enough (has the necessary number of
stories) to provide the information for the first Sprint, the
Product Owner and the Development Team can start the first
Sprint.

The first thing to do in each Sprint is Sprint Planning. Sprint Planning is a timeboxed
meeting, usually fixed to 8 hours for a one-month Sprint, or shorter for Sprints of less than a
month. All three roles should attend this meeting.

The Development Team should estimate the capacity of work it can deliver in a single Sprint.
The Product Owner has already ranked and ordered the Product Backlog based on the value
of the items. The Product Owner also ensures that the items (stories) are easy to
understand. The Development Team then selects an appropriate number of items from the
top of the Product Backlog, and puts them in the Sprint Backlog, to deliver in the current
Sprint. The amount of work for each item is estimated by the Development Team and the
total amount of work of the selected Product Backlog items is close to the estimated
capacity of the Development Team.

Following the selection of the items, the Scrum Team should draft a Sprint Goal. The Sprint
Goal is an objective that should be met within the Sprint by the implementation of the

Page 43
EXIN Agile Scrum
Foundation Workbook

Product Backlog. The Scrum Goal provides guidance to the Development Team on why it is
building the Increment.

This is a sample Sprint Goal:

Enabling all the essential parts of the website store to set up a complete purchase
process. This makes other features of the website more meaningful to the customer.

The Product Backlog should be ordered in a way that facilitates setting Sprint Goals, and
composing the goal is the responsibility of the whole Scrum Team.

The scope of the Sprint, which is made up of the items selected from the Product Backlog,
might need to have more details added to during the Sprint. These details should be aligned
with the Sprint Goal, and in the likely event of renegotiations, they should be done in the
presence of the Product Owner. The Sprint Goal is also included in the Sprint Backlog.

When the items to deliver are selected and the Sprint Goal is agreed, it is time to plan how
to deliver the items into a “Done” product Increment and realize the Sprint Goal. This is the
last part of the Sprint Backlog. The Sprint planning is not necessarily completed in this
meeting. Having a detailed plan for the first few days is enough; the Development Team can
prepare detailed plans for the rest of the work later.

A detailed plan is a breakdown of a Product Backlog item into detailed tasks which needs to
be done in order to create the item. Each task might have estimates, dependencies, and
other similar information to make tracking possible.

The Sprint Backlog will be ready at the end of this meeting, and the Development Team
should be able to describe what items they will deliver through the Sprint, and how they will
do it.

Page 44
EXIN Agile Scrum
Foundation Workbook

There is no specific rule on documenting, storing, and presenting the Sprint Backlog. It can
be written on a board similar to one shown in the following figure:

Sprint Goal To Do Doing Done

The goal of this sprint is to

make the purchasing part of
the website mature enough
to be able to handle the
whole process and users can
experience a full purchasing t.2.2

process, through which other

functionalities of the website
will be more meaningful.
t.3.1

Yellow sticky notes on the board above are tasks that are created by breaking down each of
the blue user stories. These tasks define what the Development Team will do to deliver each
item, and they are responsible for preparing them. Some tasks are created at the Sprint
Planning meeting, and some others during the Sprint.

The Sprint Backlog consists of the following:

1. The Sprint Goal;

2. Selected items from the Product Backlog, to be delivered during the Sprint;
3. A detailed plan for turning the selected items (stories) into “Done” Increments of the
product and to realize the Sprint Goal.

As you can see, the three Sprint Backlog elements (Sprint Goal, Product Backlog items
selected for the Sprint, and the detailed plan) are shown on the sample board. This sample
Scrum board also has extra features for tracking the tasks and items in “To Do”, “Doing”,
and “Done” columns. The next figure shows the same Sprint after the first item is Done and
items #2 and #3 are in progress.

Page 45
EXIN Agile Scrum
Foundation Workbook

Sprint Goal To Do Doing Done

The goal of this sprint is to

make the purchasing part of
the website mature enough
to be able to handle the
whole process and users can
t.2.4
experience a full purchasing t.2.2
process, through which other
functionalities of the website
will be more meaningful.
t.3.2
t.3.1

You can also see that extra tasks have been added to the lower ranked items (items #3 to
#5). This is how the detailed plan of the Sprint evolves while it progresses.

Items in the Sprint Backlog usually have the same order they had in the Product Backlog,
and therefore, the Development Team should work on the higher ordered items first.

Event 3: Daily Scrum

Sprint Daily Sprint Sprint

Planning Scrum Review Retrospective

Sprint

The Daily Scrum is normally a 15-minute meeting for the Development Team to inspect the
work done since the last meeting, and to synchronize their work and plan for the next 24
hours. It must be held on a daily basis.

During the Daily Scrum, each member of the Development Team should answer these three
questions:

1. What has been accomplished since the last meeting?

2. What will be done before the next meeting?
3. What obstacles are in the way?

They should assess progress towards the Sprint Goal and

forecast the likelihood of completing the items before the
Sprint is over.

Page 46
EXIN Agile Scrum
Foundation Workbook

The Daily Scrum meeting should be held at the same time and place throughout the Sprint,
in order to minimize the complexity. It is just for the Development Team; it is not a status
meeting for all the stakeholders.

The Development Team should also monitor Sprint progress each day, and therefore, it is a
good idea for the Sprint board to be visible during the Daily Scrum meeting. They can use a
burn-down chart to track their remaining work and to check if they are going to complete all
items before the end of the Sprint.

Sprint Goal To Do Doing Done

The goal of this sprint is to

make the purchasing part of
the website mature enough
to be able to handle the
whole process and users can
t.2.4
experience a full purchasing t.2.2
process, through which other
functionalities of the website
will be more meaningful.
t.3.2
t.3.1

Sprint Burn-Down Chart

80
70
60
50
40
30
20
10
0
1 2 3 4 5 6 7 8 9 1011121314

The above figure contains the Sprint Burn-Down Chart (the tracking information), and this
can be updated after each Daily Scrum meeting. Burn-Down Charts are discussed further in
the next section.

Event 4: Sprint Review

Sprint Daily Sprint Sprint

Planning Scrum Review Retrospective

Sprint

The duration of this meeting is normally four hours for a one-month Sprint. If the Sprints are
shorter then the meeting will be proportionally shorter.

At the end of the Sprint, the Scrum Team and other stakeholders gather and hold a four-
hour meeting to present and inspect the “Done” items (the Increment) from the current
Sprint. The presentation of the Increment in this meeting is intended to collect feedback and
raise change requests as soon as possible.

Page 47
EXIN Agile Scrum
Foundation Workbook

We welcome changes in Scrum and encourage them to be demanded, because it increases

the satisfaction of the customer and will create a final product that better matches the
needs of the customer.

The Development Team does not present an item, unless it is 100% complete based on the
agreed definition of “Done”. The Product Owner makes sure (before the Scrum Review) that
presented items are “Done”. The Development Team demonstrates and explains the items.

Note that 99% progress is just 0% “Done”. It is not even common to calculate any
percentage complete values in Agile projects, since the only measure of performance is the
“Done” pieces of product. This is nothing to worry about, since the Product Backlog items
are usually small.

Any user story that is not “Done”, will go back to the Product Backlog and the Product
Owner will order it again. If it is still at the top of the Product Backlog, it will be picked to be
completed in the next Sprint.

The Product Owner discusses the status of the Product Backlog, and the likely completion
dates based on the progress.

Project Increment
Status demo

Feedback

Performing Organization
Customer

Finally, the whole Scrum Team collaborates on revising the Product Backlog based on the
output of the Sprint, and the feedback received from the customer.

Event 5: Sprint Retrospective

Sprint Daily Sprint Sprint

Planning Scrum Review Retrospective

Sprint

Page 48
EXIN Agile Scrum
Foundation Workbook

This meeting is normally three hours for a one-month Sprint. If the Sprint is shorter than
one month, then the meeting will be proportionally shorter.

After the Sprint Review and just before the end of the Sprint, another meeting will be held,
aimed at process improvement (learning lessons), which is called Sprint Retrospective.

There is a rule: we should always look for ways to improve. It does not matter how little the
improvement is, there should be an improvement. This meeting is a formal opportunity for
improvement, even though we do not limit our improvement to the results of this meeting.
We will review (inspect) the Sprint, with regard to people, relationships, processes, and
tools, and identify ways of improving them in the next Sprint.

Activity: Product Backlog Refinement

Besides the timeboxed events discussed before, there is also an ongoing activity in Scrum
projects called Product Backlog grooming or Product Backlog refinement. It is the act of
reviewing and revising Product Backlog items, which typically involves adding details,
estimates, and order to them. The Product Owner is responsible for ordering (prioritizing)
the items, and the Development Team is responsible for estimating.

The main difference between this activity and the five Scrum events is that Scrum events are
all timeboxed, but grooming is an ongoing activity that happens throughout the Sprint. This
activity should not consume more than 10% of the time of the Development Team.

Slack
Sprints come one after the other, without any slack, based on the Scrum Guide. Some
people prefer to have one or two days off between every two Sprints to have a small rest.
However, there are some reasons against having an official slack designed in the framework:

 The Development Team is self-organized, so if they believe that they need to take
some days off, they should decide to do so, instead of having it in the framework.
 Besides that, having a constant pace is essential, and we do not expect the team
members to be under abnormal pressures in any Sprints and need a special rest
afterwards.

Scrum Artifacts
Scrum artifacts – results/products of our management activities – are designed to increase
the transparency of information related to the delivery of the project, and to provide
opportunities for inspection and adaptation.

There are six artifacts in Scrum:

Page 49