EXIN Agile Scrum

Foundation Workbook

EXIN Agile Scrum Foundation Certification

EXIN Agile Scrum Foundation is a professional certification focused on the Agility concept
and the Scrum framework which is useful for those involved in Agile environments or those
planning to migrate to one and wanting to prove their knowledge. The certification program
is defined and provided by EXIN, a world-leading provider of independent information
management certification and accreditation.

General information about the exam:

 Prerequisites: none
 Type of questions: multiple choice
 Number of questions: 40
 Pass mark: 65%
 Open book: no

Since there are no prerequisites for the exam and based on the fact that you can register
and take the exam online, it is really accessible for everyone, especially those who prefer to
self-study.

This book covers almost everything you need to know for the exam. You would easily pass
the exam by reading this book entirely and carefully. However, the Agility concept is wide
and you can always come across a question on a topic that is not covered in this training
manual.

This book is approved by EXIN as a resource for the EXIN Agile Scrum Foundation exam.

You can find out more about the exam here:

https://www.exin.com/NL/en/exams/&exam=exin-agile-scrum-foundation

You can take a sample Agile Scrum Foundation exam via the same webpage when you are
ready.

Page 5
EXIN Agile Scrum
Foundation Workbook

1
Agility Concept

Page 6
EXIN Agile Scrum
Foundation Workbook

Agility Concept

The word “agile” is an adjective, meaning: to move quickly and easily, or to think quickly and
in an intelligent way (Oxford Advanced Learner’s dictionary). However, “Agile” (with a
capital A) is used to refer to a group of frameworks used for the development and
management of initiatives1. The main goal of Agile frameworks is to make the development
quicker and smoother, and to create an output that is more satisfying for the customer.

Almost everyone in the IT business has heard of Agile and is willing to try it; whether or not
they and their customers are ready for such a change. There are even customers out there
that expect you to be Agile, while they do not accept some of its consequences (e.g. lack of
upfront documentation).

So, let’s start this book by reviewing the concept of Agility to create a solid foundation
before discussing an actual framework in the next chapter.

Project Delivery Method and Lifecycle

The common development processes for an IT project are as follows:

 Analyze
 Design
 Construct
 Integrate
 Test

There are different formalized processes for the development of IT projects, but they are all
similar to the processes above. Some processes might be named differently, split, or
merged, but the concept is the same. These processes are required for every IT project,
regardless of the lifecycle used: Agile or traditional. The main point here is how we arrange
the processes, which creates different lifecycles. Some lifecycles are Agile and some are not.

So, let’s take a look at the different ways we can design the development lifecycle based on
the standard development processes.

One way of running the processes is to have them run one after another, as shown in the
next figure.

1
“Initiative” is the term used to refer to both projects and programs. A program is an initiative which is
focused on creating a result instead of a product. Programs are done with multiple related projects.

Page 7
EXIN Agile Scrum
Foundation Workbook

In this lifecycle, we start with the first process and spend enough time on it until it is
completed. Then we close the process and move to the next one. Each process creates an
output: a document, some code, or a new state in the code.

High-level Detailed
project plan project plan

Analyze Design Construct Integrate Test

Scope prediction Architecture Product

prediction

The first step (Analyze) is to specify the requirements and define the scope of the project. It
is very important to have a well-defined scope to avoid further problems in traditional
environments. The output is a document that might be called “Requirements Specification”
or something similar.

The second step (Design) is to design the architecture of the solution, resulting in a
document that might be called “Solution Architecture”.

The third step (Construct) is to build the software in its entirety. Then, in the fourth step, the
code is integrated and finally tested and debugged in the last step.

This is the traditional way of developing IT solutions and it is still commonly used in many
organizations today. It is often referred to as the Waterfall model. The main characteristic of
this lifecycle is that everything is defined before the development starts and there is a clear
separation between the processes. There might be some overlap between the processes
sometimes, but it would still be a Waterfall lifecycle.

This characteristic of defining everything upfront and trying to stick to it is called predictive,
so the model that we have just described is a predictive lifecycle. The Waterfall model is a
common name for the predictive lifecycles in the IT development world.

In a predictive lifecycle, the project is run step by step. Each step is dedicated to a certain
concept of the project and everything is designed and planned upfront. This lifecycle is great
for many projects, such as building a house, hospital, or airport. However, when it comes to
IT projects, it is very hard to use such a system because the customer usually does not know
exactly what they want, and therefore, they keep changing the requirements throughout
the project. Think of a project to build a hospital: it may face lots of changes, but is it
possible that you would end up with a theme park instead of a hospital? Of course not.
However, it is quite possible for IT projects to start creating something like a “hospital” and
end up with something like a “theme park”!

Page 8
EXIN Agile Scrum
Foundation Workbook

The problem is that the customer does not know what they want, until they see the working
software, which is provided too late in predictive lifecycles (at the end of the project). We
can use the following lifecycle to avoid this problem:

 Analyze  Analyze  Analyze  Analyze  Analyze  Analyze

 Design  Design  Design  Design  Design  Design
 Construct  Construct  Construct  Construct  Construct  Construct
 Integrate  Integrate  Integrate  Integrate  Integrate  Integrate
 Test  Test  Test  Test  Test  Test

Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6

Increment Increment Increment Increment Increment Increment

(product) (product) (product) (product) (product) (product)

We use a number of iterations in this lifecycle, which are called Sprints in Scrum. We run all
the development processes on a part of the product in each iteration. The main reason for
using iterative lifecycles is to have interim solutions at the end of each iteration, show them
to the customer, receive their feedback, apply this feedback to the next iterations and thus
reduce the amount of rework in later iterations.

So, we have interim solutions (Increments) along the way and we can receive useful
feedback after each iteration. We want to receive feedback as soon as possible so that we
apply them in the next iterations of the project. A consequence is that the number and
content of the building parts are dynamic. So, instead of creating a full requirements
specification before designing and building everything, we start incrementing and iterating
with a limited number of building parts and let the other parts of the scope form as the
project goes on. This is called an adaptive lifecycle; a lifecycle that develops the final
solution in an iteratively and incremental way, by adaptation.

What we call Agile, is technically equivalent to using adaptive lifecycles. The Waterfall or
traditional methods use a predictive lifecycle as mentioned earlier in this chapter.

Note that an adaptive lifecycle is not just the process of dividing the development of the
features into multiple stages; it focuses on limiting the plan to a few iterations in the near
future, and using the output of each iteration to plan a little further toward the future.

Another important point concerning adaptive lifecycles is that we do not run a mini-
waterfall inside each iteration. A mini-waterfall runs all the development processes for all
iteration items in the same time: specifies the iteration, then designs it, then builds it, etc.
We use mini-agile inside iterations, which focuses on single features at a time, and runs all
the development processes for them separately.

Page 9
EXIN Agile Scrum
Foundation Workbook

Feature 1
Each development Feature 2
process is run once to Feature 3 Mini-Waterfall (wrong)
cover all features. Feature 4
Feature 5

Feature 1
Each development Feature 2
process is run separately Feature 3 Mini-Agile (right)
for each features. Feature 4
Feature 5

Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6

Increment Increment Increment Increment Increment Increment

(product) (product) (product) (product) (product) (product)

There are many frameworks using this adaptive lifecycle; all known as Agile frameworks.
Scrum is the best-known Agile framework, though there are other Agile frameworks such as
XP, DSDM Atern, and Crystal. The second half of this book is mostly focused on Scrum, while
the first part on the Agility concept is applicable to all Agile frameworks.

Agile Manifesto
So far, you know that an Agile framework is one that uses an adaptive development lifecycle
instead of a predictive one. Agility was around back in the 50s, where it was considered a
strange and sometimes anarchistic viewpoint; in a time when the traditional method did not
even have a name such as Waterfall, because it was the de-facto way of working.

The term “Agile” has become more and more established and was formalized by a group
that prepared and signed a statement of values for Agile projects back in 2001, known as the
Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions Over processes and tools

Working software Over comprehensive documentation
Customer collaboration Over contract negotiation
Responding to change Over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck Ward Cunningham Andrew Hunt Robert C. Martin Dave Thomas
Mike Beedle Martin Fowler Ron Jeffries Steve Mellor

Page 10
EXIN Agile Scrum
Foundation Workbook

Arie van Bennekum James Grenning Jon Kern Ken Schwaber

Alistair Cockburn Jim Highsmith Brian Marick Jeff Sutherland
© 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice.

This short manifesto explains the whole Agile idea in the simplest way. Take some time and
see how you can match it with the idea of adaptive lifecycles.

Value 1: Individuals and interactions over processes and tools

Most management systems are focused on the processes and tools. We have
been trying to improve without paying enough attention to the human part of
the projects. In extreme cases, some managers consider team members as the
simple pieces of a complex machine, which can be easily replaced, without
interrupting the work. However, we have realized that we cannot have such a
perfect machine in projects, because of all the uncertainties involved and the
creativity required. Therefore, focusing on the processes and tools is not enough.
The best way to improve the performance is to focus on the human aspects.

Value 2: Working software over comprehensive documentation

Why do we create comprehensive documentation to begin with? We do this in

order to communicate with the customer and to create a foundation for the
solution that is supposed to satisfy the customer. However, the fact is that the
customer does not know what they want, until they see the working software,
and no documentation can replace the working software for this purpose.

It does not mean that we do not have any documentation in Agile projects, as
some people falsely believe. For example, we still need operation manuals, which
can be documents, even though we might prefer to have them as videos instead.
We also have lots of tracking information in our configuration management
system to help us support the development process. However, documents such
as “requirements specification” and “solution architecture” are not used in an
Agile environment.

Value 3: Customer collaboration over contract negotiation

An adaptive environment is meaningless without adaptation, and the basis for

adaptation is the customer collaboration. We are not dependent on any upfront
design, and we are open to any changes requested from the customer at any
time during the project. Late changes do not create lots of rework for us,
because we do not have an upfront design to revise for each change.

Value 4: Responding to change over following a plan

Page 11
EXIN Agile Scrum
Foundation Workbook

We do not plan the whole project upfront, because we know that our customer
does not know what they want. Instead of following a forced plan, we use an
adaptive lifecycle, which is based on responding to change.

Agile Principles
There are twelve principles accompanying the Agile Manifesto, which describe the Agility
concept even further:

Principle 1: Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.

The goal is to have a satisfied customer, because they will return and they will
also recommend us to other potential customers. But how? By delivering the
solution that they really want and we know that it is not quite possible
without being adaptive and delivering frequent, early, and continuous working
software. Such flexibility is still possible in predictive lifecycles, but it is too
expensive.

Principle 2: Welcome changing requirements, even late in development. Agile processes

harness change for the customer's competitive advantage.

Using an adaptive lifecycle, we can always accept changes, because there is no

big upfront design to be fixed each time we want to change something.
Besides that, we are happy to receive change requests, because each change
is a step closer to what the customer really wants.

Principle 3: Deliver working software frequently, from a couple of weeks to a couple of

months, with a preference to the shorter timescale.

The customer will have a better understanding of what they want when they
see the working software. We will receive feedback and use it for adaptation.

Different frameworks have different iterations. In Scrum, for example, we are

not allowed to have iterations longer than one month, while some other
frameworks accept longer iterations. We always prefer shorter iterations, as
long as it is enough for creating a meaningful increment (working software).

Principle 4: Business people and developers must work together daily throughout the
project.

The involvement of the business/customer is usually limited to specifying the

requirements at the beginning of a predictive environment, and again at the
end, to approve the final solution. However, we need them to collaborate

Page 12
EXIN Agile Scrum
Foundation Workbook

with the developers on a daily basis in an adaptive environment, because their

input is the source of the adaptation.

Principle 5: Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.

An Agile environment is based on a cross-functional and self-organized team

that manages itself and finds its way instead of receiving orders. This is a big
responsibility for developers and not all developers are capable of working in
this way. When we have suitable team members, we should trust them,
motivate them and empower them to enable Agility.

Principle 6: The most efficient and effective method of conveying information to and
within a development team is face-to-face conversation.

Team members in a traditional environment are focused on their specialist

activities and might even be located in different places (usually in their
organizational departments). We cannot even call them a team sometimes;
they are just a number of individuals working on the same project. In contrast,
in an Agile environment, we need a real team, and the members should ideally
be co-located to enable continuous communication. After all, nothing can
replace face-to-face conversations.

It is a big advantage to have co-located teams, but it does not mean that we
cannot have an Agile project with a distributed team. However, we should
make the best use of the modern technology to minimize any lack of face-to-
face communications, and expect a lower level of productivity at the end of
the day.

Principle 7: Working software is the primary measure of progress.

A 99% progressed item is still 0% “done”. How can we know the progress of a
quantum of work, unless we go deep into technical matters? We do not do it,
because we want to have a common language with the non-technical
customer and keep them engaged. The solution to this is that we only have
“done” or “not done” backlog2 items (backlog items must be non-technical).
And it is OK; after all, the backlog items are small enough to show our progress
by a simple done/not-done measurement.

Principle 8: Agile processes promote sustainable development. The sponsors, developers,

and users should be able to maintain a constant pace indefinitely.

2
Backlog: a list of features we are going to develop. A backlog acts like a plan for the scope of the project.

Page 13
EXIN Agile Scrum
Foundation Workbook

Working is not the goal. Realizing the product is the goal. Working overtime
might seem to make things go faster, while, in reality, it reduces the output by
decreasing the productivity and increasing defects. We prefer to have a
sustainable pace.

Principle 9: Continuous attention to technical excellence and good design enhances agility.

Avoiding upfront design does not mean that you do not need to be worried
about the design. Agile projects do have design; it is just done inside each
iteration for each backlog item.

We should always pay attention to technical excellence and good design to

avoid problems; not forgetting that the goal is a “good enough” solution
rather than a perfect one.

Principle 10: Simplicity – the art of maximizing the amount of work not done – is essential.

An Agile project is managed and delivered in a simple manner. Scope

management, for example, is handled simply by putting the essential
information on an index card or sticky note. We do not need sophisticated
tools to handle the project, and keeping it simple makes it easier to
collaborate with the customer.

Principle 11: The best architectures, requirements, and designs emerge from self-organizing
teams.

People usually work better when they are respected and have the authority to
decide how they work. It is better if all team members are accountable for
everything in the project. For example, designers do not work in isolation;
they are in constant contact with the programmers, and can use this
information to improve the designs and make them more practical.

Principle 12: At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly.

We believe that there is always room for improvement, no matter how well
we are working. So, we spend some time investigating the previous iteration
and find opportunities for small improvements. The goal is to improve every
iteration at least a little bit.

When Can We Use Agile?

Unfortunately, Agile frameworks are not applicable in every project. They are known to be
applicable in IT projects, which is correct, but they are also very helpful in organizational
change initiatives and research projects.

Page 14
EXIN Agile Scrum
Foundation Workbook

So, is it possible to use an Agile framework to build a house? The answer is usually no.

What is the difference between these two projects in your opinion?

You remember from the previous section that having an incremental and iterative lifecycle
is the common characteristic of Agile frameworks. The point is that it is not possible to
develop everything like that. In the case of a house for example:

1. We cannot produce (develop) the house iteratively, because the interim outputs are
not working solutions (the customer cannot live in a house that is 50% done). What
is the use of a building foundation without the other parts of the house? It is not
possible to stop this project in the middle and start using the product. What is the
use of a house without utilities? Besides that, all the development processes should
be run separately inside the iterations in contrast to a complete upfront design,
which means we should be able to design the foundation without knowing the
design of the other parts of the structure it is going to support, which is not possible
when building a house.
2. We cannot develop it incrementally. For example, we cannot build a simple building
foundation to enable work on the rest of the structure and then go back and
improve it before the end of the project.

Besides, why do we need an adaptive lifecycle when building a house? The customer for a
house knows what they want and we do not need to show them interim solutions to receive
feedback and constantly adapt the structure of the house.

As an exercise, consider the writing of this book as a project. Can it be done iteratively and
incrementally? If your answer is yes, do we “need” to create it adaptively?

Another point worth mentioning here is the difference between projects and programs. A
project is used to create an output, such as a piece of software. A program is used to create
an outcome, such as a business capability, and is done through a number of related projects
or other work. A project can be done predictively (traditional) or adaptively (Agile), but a
program should always be adaptive. It is so, because a program is focused on an outcome
rather than an output. We might be able to define the output upfront, but that is not
possible for outcomes. We will have the outcome in mind and try to find the means with
which to achieve it, and we should be open to changing the means as we progress.

So, if it is a program, you should deliver it in an adaptive way. If it is an IT, organizational

change, research, or similar project, you can use Agile frameworks; but you do not have to!
There are lots of IT projects developed in traditional environments which are successful. The
point is that if you can manage the change in your organization and you have the required
potential, then you will have a much higher chance of success using Agile frameworks. The
more uncertainty and change you have in a project, the more useful Agile frameworks will
be.

Page 15
EXIN Agile Scrum
Foundation Workbook

Managing the Scope

Type of Scope items

We usually define the scope in a simple or structured document or concept. This concept is
usually called Product Backlog in Agile projects. A Product Backlog contains a number of
“items”, and each item describes a building block of the final solution.

We have three alternatives for defining Product Backlog items:

1. Requirement specification – this is the most traditional way of defining the scope. It
is formed by technical terms that are clear to the development team, and are usually
based on architectural relations between items.
2. Use case – this is based on the user’s understanding and needs rather than a
technical description, and describes a detailed scenario with all the actions that an
imaginary user will do and the behaviors expected from the solution.
3. User story – this is similar to a use case, but does not contain all the details of the
user behavior and only focuses on the user’s needs and purpose.

We need to be able to communicate and collaborate with the customer in Agile

environments in order to receive feedback and adapt accordingly. After all, an adaptive
lifecycle is not useful when we do not adapt! Therefore, we need to have a common
language with the customer. A technical definition of a feature is not useful, so we prefer to
use the non-technical way of defining the scope, which is use cases and user stories.
Between these two, the user stories are preferred, because they are easier to understand.
This is a sample user story: As an end user, I want to receive a list of my last transactions. Or,
as a system administrator, I want to reset passwords. Everyone can understand them.

A user story has three parts:

As a …, I want to …, [so that …]

1. “As a …”, defines the role that is going to interact in the story; e.g. end user,
administrator, or manager.
2. “I want to …”, defines the expectation of the role; e.g. search apartments, calculate
the tax, grant permission to someone and sign-up on the website. Please note that it
is only about actions and a sentence like “as an administrator, I want to have my
system to use SQL Server” is not a user story! A user story is about doing something,
rather than having something.
3. “so that …”, this optional part of the user story explains the reason behind this action
and helps with the interpretation of the story. The reason for some stories is so
obvious that you might not need to mention it.

There are two essential rules about Product Backlog items:

Page 16
EXIN Agile Scrum
Foundation Workbook

1. They should be non-technical. This is because the Product Backlog is our tool for
communicating with the non-technical customer. Normally, a ten year old child
should be able to understand each user story.
2. They should be independent of each other, so that we can freely develop them in
any order.

We usually write down the Product Backlog items on index cards or sticky notes and put it
on a physical board. This approach is preferred to using an application, unless you have
distributed teams.

Adaptation of the Scope

The main difference with Agile scope management is that the full scope of a traditional
project is defined and agreed upon upfront, before starting the design and build. In Agile
projects, only part of the scope is defined at the outset (as much as is needed for the first
few iterations) and we start designing and building the solution with the incomplete scope.
While we are involved in the iteration, we continuously add new items to the Product
Backlog and refine the existing ones based on the feedback we receive from the customer
and the better understanding we all gain from the project. This is one of the main features
of an adaptive lifecycle.

The Product Backlog is a dynamic concept for storing the items that we are going to
develop. So,

 When we are done with an item, we take it out of the Product Backlog;
 When we select a number of items from the Product Backlog to be developed in the
next iteration, we take them out of the Product Backlog and put them in the
iteration backlog (the Sprint Backlog in case of using Scrum);
 If an item is not done until the end of the iteration, we put it back to the Product
Backlog; even if it is in progress.

We usually assign a business value to each Product Backlog item and sort the list, so that
items with more business value are placed higher. When we want to start a new iteration,
we should pick items from the top of the Product Backlog, which means that we always
develop items that have the highest business value. This is how we stay focused on the
value and the business needs. Some Agile frameworks use methods such as MoSCoW
prioritization instead of, or in combination with the quantified business value assignments
to sort the backlog items. We will discuss MoSCoW prioritization later in this chapter.

The Product Backlog is the main planning tool in most Agile frameworks. It contains the
scope of the project, along with a level of time, resource, risk, and quality plan, in the
simplest possible way.

Page 17
EXIN Agile Scrum
Foundation Workbook

Functional vs. Non-Functional Features

Each item in the Product Backlog explains a feature of the final solution, preferably in the
form of a user story. One confusing problem is how to handle non-functional features, since
they are technical by nature; user stories should be non-technical.

Our previous examples of user stories are all functional features. Other features such as
performance and security are examples of non-functional features.

Non-functional features are those which should be applied to almost all functional features.
Take performance for example: there are performance considerations for every functional
feature. E.g. we do not expect a simple search to take two minutes. The solution is to add
the non-functional features in the Definition of Done (DoD). The Definition of Done is a
concept that contains all the things we should do or consider for every user story. The
development processes, quality criteria, coding standards, and non-functional features are
all parts of the Definition of Done.

So, when we are developing any user story, we would check them against non-functional
features mentioned in the Definition of Done, and we would not call them “done”, unless
they adhere to all of them. This is what we usually call acceptance criteria in traditional
environments and it is a part of quality planning.

Some non-functional features might be applicable to only a few user stories and therefore,
the Definition of Done would not be an appropriate place for them. In this case, we just add
them to the back of the user story card. Yes, we might have some extra information about
some user stories, such as special acceptance criteria, descriptions, specific non-functional
features, etc. The front of the card belongs to the user story text (e.g. as an administrator, I
want to reset passwords), the business value, and the estimate (story points). The back of
the card belongs to everything else. For example, how do we inform the user of the changed
password, what kinds of passwords do we accept, etc. And yes, it has to be short; we do not
have that much space on the back of the card, and that is the whole point: we should keep it
simple.↑

ID: 0209 Value: 2842  Only strong passwords are acceptable.

 Password reset link should be sent to
As an end user, I want to reset my
the registered email address.
password, so that I can have access to
 The user should answer the security
my account again.
question correctly before having the
Estimate: 5 SP password reset.

Front side of a sample backlog item Back side of a sample backlog item

So, do not forget this: every user story should be understandable and demonstrable to the
non-technical customer. Avoid jargon, unless you are talking within the development team.

Page 18
EXIN Agile Scrum
Foundation Workbook

Bugs
We create a working increment of the final solution at the end of each iteration, which
should be potentially releasable. We keep them “potentially releasable”, so that it would be
easier for the customer to try it and give us feedback. Some of the iterations might actually
be released and used by the end users.

It is very common to discover bugs after the demonstration of the potentially releasable
increment or even during the use of the released product. In this case, there are different
ways of handling them:

 It is preferable to create stories for the bugs and add them to the Product Backlog.
We never add new items to the current iteration backlog, as we have to focus on the
preselected ones. So, in this case, we need to wait until the next iteration to pick the
bug from the Product Backlog and add it to the backlog of the next iteration to be
fixed. Of course, bugs should be sorted like other user stories, and if they do not
have a high value, we will have to wait for a later iteration before fixing them.
 If it is not acceptable to wait too long to fix the bugs (if the product is being used at
that moment), we can keep them outside the Product Backlog and assign a
predefined maximum effort of the team (5%, for example) to work on bugs instead
of developing new items. We usually use a separate backlog and a Kanban board3 for
the management of bugs in this case.

It is inevitable that we will have some bugs; but how many? If you have lots of bugs, maybe
you should improve your Definition of Done by adding more tests, improving the way you
develop, etc. It is really important to be proactive.

If a defect is not detected by the development team and is found by the end users after a
release, it is called an escaped defect. The number of escaped defects is an important metric
for measurement of the quality of work.

Spikes
Sometimes we are not sure how to develop something from a technical point of view. In this
case, we use a “spike” to investigate it; a small development activity to learn the technical
elements of the solution.

There are two types of spikes:

1. Technical spikes: these are focused on finding the development approach;

2. Functional spikes: these are more about prototyping and finding or understanding
the required functionality.

3
Kanban board: a board showing different steps of work, used to track the status of each work item. Items are
usually added to the board on sticky notes.

Page 19
EXIN Agile Scrum
Foundation Workbook

Spikes should be timeboxed (e.g. one or two days). Some teams have the spikes outside the
normal iterations, while the more common way is to have them inside the development
iterations.

A spike sometimes refers to a task within multiple tasks required for a Product Backlog item.
They are usually separate items. For example, we can have a spike for a normal user story in
the current iteration, and the actual story in the next iteration.

One of the main reasons for having spikes is to enable the team to give an estimate for the
user story. It is not a complete exploration, but rather a quick and fast study, aiming at
understanding and estimating.

MoSCoW Prioritization
The MoSCoW prioritization is a great technique for scope management and is an essential
part of DSDM Atern. It is not very common yet to use it in Scrum frameworks, but it is a
good idea to use it anyway.

MoSCoW is a combination of the first letters of Must Have, Should Have, Could Have, and
Would not Have This Time. In this technique, we assign one of those letters to each feature,
based on the following definition:

 M (Must Have) – is a feature that must be in the final product, and the final product
would be useless without it. E.g. brakes in a car.
 S (Should Have) – is a very important feature for the final product, and we will face
problems without it. However, we can find a workaround for that (using another
solution in parallel, doing it manually, etc.) and still use the solution that lacks it. E.g.
air conditioning in a car.
 C (Could Have) – is a really helpful feature that we would really like to have in our
solution, but frankly, it would not create a problem if we do not have it. E.g. A
camera and display in the car, which can be used to help with reversing.
 W (Will not Have This Time) – is a nice feature, but we are not going to invest in it
now. Maybe later. E.g. online monitoring of the mechanical status of the car.

When we assign these priorities realistically, we know that the minimum for an acceptable
product is the solution containing all the M user stories. Our expected product is the one
that contains all the M and S user stories. The ideal product is the one that contains all the
M, S, and C user stories.

MoSCoW prioritization is a great way of focusing on the business value: focusing on the real
needs instead of the fancy features (Could Have items).

Page 20
EXIN Agile Scrum
Foundation Workbook

Keeping the Scope Dynamic

The scope of a project is fixed in traditional methods. We have a precisely defined set of
requirements, and we try to get them done within a predefined budget, time, and quality.
However, we are not always on track; in this case, we do not want to compromise the
scope, and rather increase the time or budget or decrease the quality in order to deliver all
the features. This is not favorable in Agile frameworks.

We focus on the business needs in Agile frameworks, and compromising time and quality is
not a good idea, because IT products have a very short operational lifetime. If we spend
more time creating a solution just to have all the fancy features included, we are losing
value.

Some Agile frameworks do not allow changes in duration. The project is guaranteed to be
finished on time. If something goes wrong, we will drop some of the unnecessary features
(scope) instead. DSDM Atern is one of these frameworks.

The following figure shows the classical triple constraints of projects and the different ways
in which we can handle them:

Atern Approach

Features Fixed Time Cost

Quality

Quality?

Time Cost Variable Features

Traditional Approach

It is not necessary to follow the Atern principle of delivering on time in Scrum. However, we
still develop higher-value user stories first. So the increase in the value of each iteration will
be less and less as we progress though the project. We help the customer realize this, and
we should therefore be ready to stop the project after each iteration. When the customer
realizes that the current iteration has enough value, they may not want or need to spend
extra time and money to receive the remaining small value features, so they may choose to
close the project. This is another reason why we must keep the iterations “potentially
releasable”.

Page 21
EXIN Agile Scrum
Foundation Workbook

Product Scope in Agile Environments

To understand the difference between the scope of the final product in an Agile
environment and the difference it has with the traditional one, take a look at the next
diagram which shows the result of a research done by the Standish Group in 2011,
concerning the average use of software features.

Always
7%
Often
13%

Never
45%
Sometimes
16%

Rarely
19%

The average use of software features (2011)

This is the disaster we are trying to avoid in Agile environments: nearly half of the features
in an average software are almost never used, which means we are spending twice as much
time and money; a real waste. The main reason that Agile projects are faster is that we are
incorporating a mechanism that eliminates such outputs.

The reason for such waste in traditional environments is that we force the customer to
specify everything upfront, and since change is usually followed by time and cost claims
later in the project, the customer tries to think about every possible feature they might
need. As it turns out, most of those upfront specified features are useless. We do not have
this problem in Agile projects due to two reasons:

1. We do not force the customer to specify everything upfront, so they do not need to
be over-creative by defining every possible feature. Besides that, they know that we
welcome changes at any time, so they can relax.
2. We help the customer understand the business value of each feature and avoid
those that do not really help the business, even if they have been defined in the
Product Backlog.

Page 22
EXIN Agile Scrum
Foundation Workbook

The Timebox Concept

There is an important concept used in Agile frameworks: timebox.

Each timebox has two major characteristics:

1. It has a pre-defined maximum duration. We never extend the duration of the

timebox just because we need to finish something. We adapt ourselves to finish
everything inside the timebox, and if it is not possible, we drop activities that have
the least importance. So, each timebox has a maximum time, however, there are
two types of timebox regarding the minimum time:
a. Fixed duration: some of the timeboxes are completely fixed, and not only is
the maximum time not extendable, but also the minimum is fixed. So, if we
have done everything, and we still have some time left, we either pick new
activities based on the rules defined in the framework, or just take some time
off! This type of timebox is used to create regularity and is usually used for
the major events.
b. Max duration: some other timeboxes have a maximum duration, which is not
extendable, but does not have a minimum duration. So if we are done with
all the activities and have extra time, the timebox will be considered closed,
and we will start another timebox. This type is used to maximize flexibility,
along with regularity, and is usually used for smaller events or those that
cannot have extra activities.
2. Timeboxes have a predefined and usually frozen set of items to be completed. We
define the items upfront and do not change them. We can refine the items (e.g. user
stories), but we do not completely change them. We do not add new items or
remove items. Of course, this is only the case until the next timebox, when all new
changes are applied. This is so, because everything is changing in Agile environments
all the time, and we need to focus to stay productive. So, while everything is
changing, we keep short durations frozen and focus on development. The only
exception is that if the timebox is of a fixed duration instead of a max duration, we
can add extra activities once we are done with all the pre-defined ones.

As you might have guessed, each iteration is timeboxed. They are fixed duration timeboxes
in most frameworks. We also have lots of meetings either inside or outside the iterations,
which are timeboxed as well; e.g. planning timebox. You can see a concrete example of
Scrum timeboxing in the next chapters.

Using timeboxes is a great strategy for increasing productivity, both in your personal life and
in projects. Some of the advantages are:

1. It creates regularity and discipline, and in particular, helps us create potentially

releasable solutions;

Page 23
EXIN Agile Scrum
Foundation Workbook

2. It helps increase focus, especially where everything is changing and new things come
up all the time;
3. It helps us focus on the value and the business needs. Because the maximum
duration is always fixed in timeboxes, we cannot extend the time to finish
something, and instead, we have to understand the values and drop some of the
activities that have less value.

Planning Onion
There are different levels of planning related to an Agile project, which can be shown in an
onion shaped diagram such as the one below:

Strategy

Portfolio

Product

Release
Iteration
Day

The strategy and portfolio planning levels are outside the projects, handled by the broader
management systems of the organization. Strategy planning defines the benefits for the
organization (e.g. earning money), and the portfolio level picks and resources the best
possible projects to optimize the benefits.

Inside each Agile project, there are four conceptual levels of planning:

1. Product planning – usually done in the Product Backlog and probably some
additional high-level plans such as the product vision, based on the framework in
use.
2. Release planning – this level plans when increments should become available to the
end users for actual operations. In some frameworks such as Scrum, we do not have
a type of planning specific to releases, because we are always ready to release the
latest increment.
3. Iteration planning – in the case of Scrum, this level of planning is done in the Sprint
Planning meeting, and creates the Sprint Backlog. This is a list of items (user stories)
picked from the top of the Product Backlog to be developed through the current
iteration.

Page 24
EXIN Agile Scrum
Foundation Workbook

4. Day planning – in Scrum, for example, this level is done by breaking down the Sprint
Backlog items into tasks, and it is also discussed after the Daily Scrums.

Agile Practices
There are a number of common practices in Agile environments that really help improve the
way your project is progressing. Some of the practices are not limited to Agile
environments, and you can benefit from them in traditional environments too. Some
essential practices are explained in the previous chapters or will be explained in the Scrum
framework chapters. This section introduces some of the other common practices.

Pair Programming
Pair programming is having two developers working together at one workstation. One of
them is called the driver, who writes code, and the other person is called navigator, who
observes and gives comments. These two people switch their roles frequently (every hour,
for example).

These are the main benefits of pair programming:

 Working is more enjoyable for people, when they are working in pairs. Well, there
are sometimes conflicts, but they are not caused by pair programming; they are
existing problems that have shown themselves because of the pair programming
practice, and otherwise, they would have shown themselves elsewhere;
 People learn more when they see each other working;
 It is a team-building activity and helps create a more collaborative environment,
which is required for all Agile teams;
 The quality of the product is much higher when we are using this practice, which also
results in fewer defects, rework, and cost.

It might seem strange at the beginning to assign two people to do the work of one person
and this might seem wasteful. However, the fact is that in practice, the output of a pair of
programmers, including all the debugging, is more than twice the product that two separate
programmers create. So, it is even economical to use this practice.

Bus Factor
You lose one of your project team members, for any reason (e.g. a bus hits him/her and…),
and you are not able to continue the project anymore, because no one else has the key
information for the project. This is a project with a Bus Factor of 1, which is terrible.

The minimum number of developers you have to lose before losing the ability to continue
the project (even by adding new developers), is called your Bus Factor or Truck Factor.
Higher numbers are certainly desired.

Page 25
EXIN Agile Scrum
Foundation Workbook

A cross-functional and self-organized environment is a great opportunity for increasing the

Bus Factor and consequently, it decreases the negative risks. However, you can have more
mechanisms in place to help with this aspect by Succession planning.

Succession planning is about keeping the information inside the team, instead of certain
individuals, and makes it possible to switch responsibilities, or even add or remove
developers in extreme cases. Pair programming is a great way of succession planning and
increasing the Bus Factor, because everything is well known to at least two people instead
of one.

Maximizing transparency, improving the communications (daily standups, demos,

configuration management systems), and practicing a real co-ownership of code are other
ways of increasing the Bus Factor.

The results of a successful succession plan are not limited to extreme cases of losing people.
It is also very helpful for the natural flow of the project, because team members might get
sick, go on vacation, or simply become distracted every once in a while. These issues can
cause serious problems in a low Bus Factor environment.

Test-Driven Development
Test-driven development is the practice in which test scenarios are prepared before the
program is written. So, the goal for the programmer is to write something that can pass the
exact test.

These are some of the benefits of test-driven development:

 Programmers know exactly what others expect from them and can work more
productively;
 Programmers will be encouraged to create the simplest possible program, just to
pass the test. This is desirable in Agile environments, since we do not want to waste
time creating something perfect, while all we need is a good enough solution to do
the job. However, we usually need to have an eye on refactoring to make sure that
the solution is still “good enough”.

Continuous Integration
The pieces of code are usually integrated at the end of the project or phase in a traditional
environment, while we prefer to have continuous integration in Agile environments. All
programmers are required to upload their latest versions of code into the repository every
hour or so.

This practice enables us to be sure that our previous work is “done” and does not need too
much further adjustment. However, it is required to have a reliable configuration

Page 26
EXIN Agile Scrum
Foundation Workbook

management system to enable this practice without getting into problems, especially when
the output is being used in operations.

Some key benefits of the continuous integration practice are:

 It is easier to have real increments at the end of the iterations; releasing the solution
would be much easier than in traditional environments;
 We see early warnings for the conflicts and less rework in the future code.

Continuous integration is usually used in combination with automated testing

environments.

Continuous Refactoring
Refactoring is the improvement of code without changing its external functions. Continuous
refactoring is spending some of the development time on refactoring to facilitate the future
development and maintainability.

Key benefits of continuous refactoring are:

 Developing the remaining parts of the project is faster and smoother;

 We can build up lots of lessons learned to incorporate in the remaining parts of the
project and in future projects.

Care should be taken not to target perfect code instead of good-enough code. A minimum
continuous refactoring is required in Agile environments, because we are not developing
based on an upfront design.

Continuous refactoring is the Agile strategy for repaying the technical debt. Technical debt is
the eventual consequence of poor development, which should be repaid sometime, and the
sooner, the better.

Collective Code Ownership

No one in the Agile team owns a piece of code; everyone is accountable for everything, and
everyone is allowed to change any piece of code.

The key benefits of collective code ownership are:

 Encouraging collaboration;
 Making everyone focus on the project and its value instead of specialist activities.

This practice is mandatory in most Agile frameworks, including Scrum.

Page 27
EXIN Agile Scrum
Foundation Workbook

Sustainable Pace
Having a sustainable pace, as you might remember from the Agile principles, is required.
Having constant overtime work might seem to increase the speed, but in practice, it actually
slows down everything because of the low quality of the code and morale of the team.

The key benefits of having a sustainable pace are:

 Developers are more focused on producing rather than working; they are focused on
the project as a whole, rather than activities;
 We will have a happier environment;
 At the end of the day, we will have higher productivity.

The use of relative units (story points) for measuring the effort of each Product Backlog item
instead of time-based units helps us keep the pace sustainable.

Page 28