exin agile scrum training manual
DESCRIPTION
EXIN Agile Scrum Training Manual 2015TRANSCRIPT
EXIN Agile Scrum Foundation Workbook
Page 0
EXIN Agile Scrum
By Nader K. Rad, Frank Turley
Foundation Workbook
EXIN Agile Scrum Foundation Workbook
Page 1
EXIN Agile Scrum Foundation Workbook By Nader K. Rad, Frank Turley
© 2014, Nader K. Rad and Frank Turley
All rights reserved. Except for brief passages and quotes for
reviewing or commenting purposes, no part of this publication
may be reproduced or transmitted in any form or by any
means without prior consent of the authors.
EXIN Agile Scrum Foundation Workbook
Page 2
Table of Contents
About the Authors ..................................................................................................................... 4
EXIN Agile Scrum Foundation Certification ............................................................................... 5
Agility Concept ........................................................................................................................... 7
Project Delivery Method and Lifecycle .................................................................................. 7
Agile Manifesto .................................................................................................................... 10
Agile Principles ..................................................................................................................... 12
When Can We Use Agile? .................................................................................................... 14
Managing the Scope ............................................................................................................ 16
Type of Scope items ......................................................................................................... 16
Adaptation of the Scope .................................................................................................. 17
Functional vs. Non-Functional Features .......................................................................... 18
Bugs .................................................................................................................................. 19
Spikes ............................................................................................................................... 19
MoSCoW Prioritization..................................................................................................... 20
Keeping the Scope Dynamic ............................................................................................. 21
Product Scope in Agile Environments .............................................................................. 22
The Timebox Concept .......................................................................................................... 23
Planning Onion ..................................................................................................................... 24
Agile Practices ...................................................................................................................... 25
Pair Programming ............................................................................................................ 25
Bus Factor .................................................................................................................... 25
Test-Driven Development ................................................................................................ 26
Continuous Integration .................................................................................................... 26
Continuous Refactoring ................................................................................................... 27
Collective Code Ownership .............................................................................................. 27
Sustainable Pace .............................................................................................................. 28
Scrum Framework .................................................................................................................... 30
Quick Overview of the Scrum Framework ........................................................................... 30
Scrum Roles .......................................................................................................................... 32
Scrum Team ..................................................................................................................... 32
Role 1: The Product Owner .............................................................................................. 34
Role 2: The Scrum Master ................................................................................................ 36
Role 3: The Development Team ....................................................................................... 37
Other Roles ...................................................................................................................... 38
Who Is the Project Manager? .......................................................................................... 38
Pigs and Chickens ............................................................................................................. 38
Scrum Events ........................................................................................................................ 39
Introduction to Scrum Events .......................................................................................... 39
Timeboxing ................................................................................................................... 39
Suitable Workspace ..................................................................................................... 40
Osmotic communication .............................................................................................. 40
Managing Distributed Teams ....................................................................................... 40
Event 1: The Sprint ........................................................................................................... 40
Setting the Duration of the Sprints .............................................................................. 42
Overtime Work, Buffers, etc. ....................................................................................... 42
Canceling Sprints .......................................................................................................... 42
Sprint 0 ......................................................................................................................... 43
EXIN Agile Scrum Foundation Workbook
Page 3
Event 2: Sprint Planning ................................................................................................... 43
Event 3: Daily Scrum ........................................................................................................ 46
Event 4: Sprint Review ..................................................................................................... 47
Event 5: Sprint Retrospective .......................................................................................... 48
Activity: Product Backlog Refinement ............................................................................. 49
Slack ................................................................................................................................. 49
Scrum Artifacts ..................................................................................................................... 49
Artifact 1: Product Backlog .............................................................................................. 50
Product Backlog Items ................................................................................................. 51
User Stories .............................................................................................................. 51
Epic User Stories ...................................................................................................... 52
Themes ..................................................................................................................... 52
Estimating .................................................................................................................... 52
Story Points .............................................................................................................. 52
Planning Poker ......................................................................................................... 53
Triangulation ............................................................................................................ 54 Triangulation Board ................................................................................................. 55
Affinity estimation ................................................................................................... 55
Ideal hours / Ideal days ............................................................................................ 56
Re-estimating ........................................................................................................... 56
Ordering the Product Backlog Items ............................................................................ 57
Release Planning .......................................................................................................... 58
Artifact 2: Sprint Backlog ................................................................................................. 59
Velocity ........................................................................................................................ 60
Artifact 3: Increment ........................................................................................................ 61
Artifact 4: Definition of “Done” ....................................................................................... 61
Agile Documentation ................................................................................................... 62
Agile Testing ................................................................................................................. 63
Artifact 5: Monitoring Progress toward a Goal ................................................................ 63
Information Radiators .................................................................................................. 63
Burn-Down Charts .................................................................................................... 64
Burn-Down Bars ....................................................................................................... 66
Burn-Up Charts ........................................................................................................ 67
Cumulative Flow Diagrams ...................................................................................... 68
Niko-niko calendar ................................................................................................... 70
Artifact 6: Monitoring Sprint Progress ............................................................................. 71
Scaled Scrum ........................................................................................................................ 71
Roles ................................................................................................................................. 72
Product Ownership .......................................................................................................... 72
Scrum of Scrums .............................................................................................................. 73
Synchronization ................................................................................................................ 74
Splitting Teams ................................................................................................................. 74
Contract Types and Scrum ................................................................................................... 75
Scrum Prerequisites ............................................................................................................. 75
Kanban ..................................................................................................................................... 78
ScrumBan ................................................................................................................................. 84 The Journey Starts ................................................................................................................... 87
EXIN Agile Scrum Foundation Workbook
Page 4
About the Authors
Nader K. Rad is a project management consultant, author, and trainer at Management Plaza. His career started in 1997, and he has been involved in many projects in different industries. He has designed a number of project management courses, prepared a number of e-learning materials and written more than 40 books. He has also written many practical articles on project management concepts and standards, planning software, scheduling, etc.
He is certified in PMP®, PRINCE2® Practitioner, MoP® Practitioner, MSP® Foundation, MoV® Foundation, M_o_R® Foundation, P3O® Foundation, AgilePM® Practitioner, CSM®, PSM I, PSPO I, EXIN Agile Scrum Foundation, and ITIL® Foundation.
He is also a certified PRINCE2®, MoP® and Agile Scrum Trainer.
More about the author: http://nader.pm
Author’s website: http://www.mgmtplaza.com
Author’s LinkedIn Profile: be.linkedin.com/in/naderkrad
Frank Turley has been a project manager for more than 15 years. He is a PRINCE2® Practitioner and Scrum Master and also a PRINCE2 and Project Management trainer and coach. He has written a number of PRINCE2® and Project Management related books and is best known in the PRINCE2 world for his work in creating the most popular PRINCE2 Self Study training materials which include:
The PRINCE2 Foundation Training Manual and video course
The PRINCE2 Practitioner Training Manual
The PRINCE2 Sample Project
More about the author: http://mgmtplaza.com/frank-turley
Author’s website: http://www.mgmtplaza.com
Author’s LinkedIn Profile: http://linkedin.com/in/frankturley
EXIN Agile Scrum Foundation Workbook
Page 5
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.
EXIN Agile Scrum Foundation Workbook
Page 6
1
Agility Concept
EXIN Agile Scrum Foundation Workbook
Page 7
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.
EXIN Agile Scrum Foundation Workbook
Page 8
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.
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”!
Analyze Design Construct Integrate Test
Product Scope prediction Architecture
prediction
Detailed
project plan
High-level
project plan
EXIN Agile Scrum Foundation Workbook
Page 9
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:
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.
Analyze
Design
Construct
Integrate
Test
Analyze
Design
Construct
Integrate
Test
Analyze
Design
Construct
Integrate
Test
Analyze
Design
Construct
Integrate
Test
Analyze
Design
Construct
Integrate
Test
Analyze
Design
Construct
Integrate
Test
Increment (product)
Increment (product)
Increment (product)
Increment (product)
Increment (product)
Increment (product)
Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6
EXIN Agile Scrum Foundation Workbook
Page 10
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 Mike Beedle
Ward Cunningham Martin Fowler
Andrew Hunt Ron Jeffries
Robert C. Martin Steve Mellor
Dave Thomas
Increment (product)
Increment (product)
Increment (product)
Increment (product)
Increment (product)
Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5 Iteration 6
Increment (product)
Feature 5 Feature 4 Feature 3 Feature 2 Feature 1
Feature 5 Feature 4 Feature 3 Feature 2 Feature 1
Mini-Waterfall (wrong)
Mini-Agile (right)
Each development process is run once to
cover all features.
Each development process is run separately
for each features.
EXIN Agile Scrum Foundation Workbook
Page 11
Arie van Bennekum Alistair Cockburn
James Grenning Jim Highsmith
Jon Kern Brian Marick
Ken Schwaber 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
EXIN Agile Scrum Foundation Workbook
Page 12
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
EXIN Agile Scrum Foundation Workbook
Page 13
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.
EXIN Agile Scrum Foundation Workbook
Page 14
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.
EXIN Agile Scrum Foundation Workbook
Page 15
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.
EXIN Agile Scrum Foundation Workbook
Page 16
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:
EXIN Agile Scrum Foundation Workbook
Page 17
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.
EXIN Agile Scrum Foundation Workbook
Page 18
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.↑
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.
ID: 0209
As an end user, I want to reset my
password, so that I can have access to
my account again.
Value: 2842
Estimate: 5 SP
Only strong passwords are acceptable.
Password reset link should be sent to
the registered email address.
The user should answer the security
question correctly before having the
password reset.
Front side of a sample backlog item Back side of a sample backlog item
EXIN Agile Scrum Foundation Workbook
Page 19
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.
EXIN Agile Scrum Foundation Workbook
Page 20
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).
EXIN Agile Scrum Foundation Workbook
Page 21
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:
Quality?
Cost
Features
Time Features
CostTime
Quality
Variable
Fixed
Traditional Approach
Atern 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”.
EXIN Agile Scrum Foundation Workbook
Page 22
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.
Always7%
Often13%
Sometimes16%
Rarely19%
Never45%
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.
EXIN Agile Scrum Foundation Workbook
Page 23
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;
EXIN Agile Scrum Foundation Workbook
Page 24
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:
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.
Strategy
Portfolio
Product
Release
Iteration
Day
EXIN Agile Scrum Foundation Workbook
Page 25
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.
EXIN Agile Scrum Foundation Workbook
Page 26
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
EXIN Agile Scrum Foundation Workbook
Page 27
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.
EXIN Agile Scrum Foundation Workbook
Page 28
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.
EXIN Agile Scrum Foundation Workbook
Page 29
2
Scrum Framework
EXIN Agile Scrum Foundation Workbook
Page 30
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:
Scrum52%
Scrum+XP
14%
Others
34%
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).
EXIN Agile Scrum Foundation Workbook
Page 31
The next figure shows an overview of the framework:
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;
Sprint #4 Sprint #5 Sprint #6 Sprint #7 Sprint #8
Product Backlog Product
Backlog Product Backlog Product
Backlog
Increment #7 Increment #6
Increment #5 Increment #4
Sprint
Retrospective
Daily
Scrum
Sprint
Review
Sprint
Planning
Sprint #6
“Done”, and
potentially
releasable
Sprint Backlog Sprint Backlog Sprint Backlog Sprint Backlog
Feedback Feedback Feedback Feedback
To be applied
to the Product
Backlog
EXIN Agile Scrum Foundation Workbook
Page 32
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.
EXIN Agile Scrum Foundation Workbook
Page 33
A Scrum Team consists of the following three roles:
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.
Product Owner Scrum Master Development Team
1 person
Full-time or part-time
Business-oriented
1 person
Full-time or part-time
Scrum coach and facilitator
3 to 9 people
Full-time (recommended) Specialists
EXIN Agile Scrum Foundation Workbook
Page 34
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
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.
Product Owner Scrum Master Development Team
1 person
Full-time or part-time
Business-oriented
1 person
Full-time or part-time
Scrum coach and facilitator
3 to 9 people
Full-time (recommended) Specialist
EXIN Agile Scrum Foundation Workbook
Page 35
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.
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.
Communications
Communications
Customer
Performing Organization /
Scrum Team
Requirements
EXIN Agile Scrum Foundation Workbook
Page 36
Role 2: The Scrum Master
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
Product Owner Scrum Master Development Team
1 person
Full-time or part-time
Business oriented
1 person
Full-time or part-time
Scrum coach and facilitator
3 to 9 people
Full-time (recommended) Specialist
EXIN Agile Scrum Foundation Workbook
Page 37
the content (the meaning, estimation, business value, etc. of the user stories, or the content
of the increments).
Role 3: The Development Team
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.
Product Owner Scrum Master Development Team
1 person
Full-time or part-time
Business-oriented
1 person
Full-time or part-time
Scrum coach and facilitator
3 to 9 people
Full-time (recommended) Specialist
EXIN Agile Scrum Foundation Workbook
Page 38
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.
EXIN Agile Scrum Foundation Workbook
Page 39
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
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.
Sprint
Retrospective
Daily
Scrum
Sprint
Review
Sprint
Planning
Sprint
EXIN Agile Scrum Foundation Workbook
Page 40
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
Retrospective
Daily
Scrum
Sprint
Review
Sprint
Planning
Sprint
EXIN Agile Scrum Foundation Workbook
Page 41
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 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.
Sprint #5 Sprint #6 Sprint #7 Sprint #8 Sprint #9
Increment #5 Increment #6 Increment #7 Increment #8
EXIN Agile Scrum Foundation Workbook
Page 42
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
EXIN Agile Scrum Foundation Workbook
Page 43
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
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
Sprint
Retrospective
Daily
Scrum
Sprint
Review
Sprint
Planning
Sprint
EXIN Agile Scrum Foundation Workbook
Page 44
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.
EXIN Agile Scrum Foundation Workbook
Page 45
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:
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.
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
process, through which other
functionalities of the website
will be more meaningful.
t.2.2
t.3.1
EXIN Agile Scrum Foundation Workbook
Page 46
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
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.
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
process, through which other
functionalities of the website
will be more meaningful.
t.2.4 t.2.2
t.3.2 t.3.1
Sprint
Retrospective
Daily
Scrum
Sprint
Review
Sprint
Planning
Sprint
EXIN Agile Scrum Foundation Workbook
Page 47
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.
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
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.
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
process, through which other
functionalities of the website
will be more meaningful.
t.2.4 t.2.2
t.3.2 t.3.1
0
10
20
30
40
50
60
70
80
1 2 3 4 5 6 7 8 9 1011121314
Sprint Burn-Down Chart
Sprint
Retrospective
Daily
Scrum
Sprint
Review
Sprint
Planning
Sprint
EXIN Agile Scrum Foundation Workbook
Page 48
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.
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
Project Status
Increment demo
Feedback
Customer
Performing Organization
Sprint
Retrospective
Daily
Scrum
Sprint
Review
Sprint
Planning
Sprint
EXIN Agile Scrum Foundation Workbook
Page 49
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:
EXIN Agile Scrum Foundation Workbook
Page 50
1. Product Backlog: An ordered list of everything (usually user stories) that might be
needed in the final product;
2. Sprint Backlog: Selected items from the Product Backlog to be delivered through a
Sprint, along with the Sprint Goal and plans for delivering the items and realizing the
Sprint Goal;
3. Increment: The set of all the Product Backlog items completed so far in the project
(up to the end of a certain Sprint);
4. Definition of “Done”: The shared understanding of what it means for a piece of work
to be considered as complete;
5. Monitoring Progress towards a Goal: The performance measurement and forecast
for the whole project;
6. Monitoring Sprint Progress: The performance measurement and forecast for a single
Sprint.
Items 5 and 6 might look more like activities, but they are considered as artifacts in the
Scrum Guide, and therefore, we will explain them in this context. You can imagine their
output (tracking information, burn-down charts, etc.) as the real artifacts and these two
items as ongoing activities (like Product Backlog grooming) or as part of the Scrum events
(Sprint Review and Daily Scrum).
Artifact 1: Product Backlog
The Product Backlog is an ordered list of everything that might be needed in the final
product of the project. In other words, parts of the expected final product (a wish list). All
items are described in simple, non-technical, business language, and all of them are
presentable to every stakeholder. Every requirement and every change in the project will be
reflected in the Product Backlog.
The Product Backlog is dynamically changing and improving; it is never complete. We do not
wait until the Product Backlog is complete before we start delivering the items. The first
Sprint can be started as soon as the Product Backlog has enough stories defined.
The Product Owner sets a number of factors to determine the value of each item for the
business. Return on investment is usually one of the factors. All of these factors will be
summarized into the business value.
The Product Backlog items will then be ordered based on their business value, in a way that
the higher an item is, the sooner it will be delivered by the Development Team. As the items
located at the top of the Product Backlog will be delivered earlier, they will also be more
detailed and clearer when compared to the lower items.
Each Product Backlog item also has a work estimate. These estimates are solely done by the
Development Team. They are used in comparison to the capacity of the Development Team
in a single Sprint, to determine the number of items that will be selected for that certain
EXIN Agile Scrum Foundation Workbook
Page 51
Sprint. Additional information might be added to each item to help the Scrum Team take
control.
The Scrum Team should add details, estimates, and order to the Product Backlog items all
the way through the project, which is called Product Backlog grooming, or Product Backlog
Refinement. It should not consume more than 10% of the time of the Development Team.
The Product Backlog is created based on discussion rather than documentation. The Product
Backlog items should be easy to understand for non-technical stakeholders.
Sometimes multiple Scrum Teams work on the same project. The Product Backlog is a
representation of the scope of the final product and therefore, there should be only one
Product Backlog, no matter how many Scrum Teams are working on the project.
Product Backlog Items
User Stories
The most common type of Product Backlog items is user stories, which were discussed in
the initial chapters of this book: As a [role], I want to do [something], in order to [purpose].
No matter what type of Product Backlog items you are using, they must be non-technical,
and independent. Some resources suggest following the INVEST guideline for user stories:
Independent: if the Product Backlog items are not independent, you will not be able
to order them based on their business values. It is possible to make them
independent by redefining them in a new way, and if it is not possible, the last
solution is to merge the dependent items into one.
Negotiable: Product Backlog items are also communication tools, and they should
be negotiable.
Valuable: each item should have a business value assigned to it, and this value is the
basis for ordering the items in the backlog.
Estimate-able: we only have to have reliable estimates for the items at the top of
the Product Backlog. We refine the rest of the estimates in the continuous Product
Backlog grooming activity.
Small: only the items at the top of the Product Backlog have to be small; it is OK for
the rest of them to be big or even unclear.
Testable: testing is always a part of the Definition of Done.
New user stories are usually big and unclear. After a while, we can spend more time on
grooming them and turning them into smaller user stories, and finally into clear ones.
EXIN Agile Scrum Foundation Workbook
Page 52
Epic User Stories
User stories that are too big are called epic user stories. It is normal to have epic user stories
at the bottom of the Product Backlog. When the time comes, we should spend time
grooming these items by turning them into multiple smaller, yet independent user stories.
Themes
User stories should be independent, but we usually have groups of related items that create
a capability in the solution. These groups are called themes.
Understanding the themes is useful in planning the releases and assigning business values to
the individual user stories.
Estimating
Story Points
Traditional estimation is based on man-hours or man-days. A time-driven estimate creates a
time commitment for the team and can become the basis for the stakeholders questioning
the team performance. Therefore, we will have two major problems:
1. The team forces itself to commit to the initial estimates, which might lower the
quality. We should never compromise quality in Agile environments;
2. The team learns to add safety margins to every single estimate to avoid future
blame. These contingencies, which are called padding, are not controlled and create
problems. For starters, we have the student syndrome: work expands to fill the
available time.
So, we do not use time-based units for estimating the user stories. Instead, we use
completely relative effort-based units that only show the amount of work required for any
story compared to others or to a simple reference story. This unit is usually called story
point.
We start by setting a reference for the story points; a simple user story that is clear to
everyone, and they have done it multiple times before, so they exactly know how much
effort it needs. We assign 1 story point to this user story, and then compare the other
stories with it. If, for example, we believe that a certain story requires ten times the effort of
the reference story, it will be 10 story points.
So, there are two main characteristics for story points:
They are effort-based instead of time-based;
They are relative.
EXIN Agile Scrum Foundation Workbook
Page 53
Any relative effort-based unit can be converted to absolute time-based units, but this
conversion is all based on statistics. For example, if you could get about 100 story points
done in each of the previous Sprints, you can expect each story point to take one hundredth
of a Sprint to be done. This kind of calculation is called velocity measurement and will be
discussed shortly.
The reference story point does not have to be a real user story from the project; just
something small enough, simple, clear, and familiar for everybody.
Even if you try to use a single reference story for all the projects in the company, the
interpretation of the story points in each project would be different, because the
composition of the team, the capabilities of the customer, and other environmental factors
might be different.
Planning Poker
It is the responsibility of the Development Team to estimate the user stories, but how?
Everyone gathers, and the product owner explains the user story to make sure that
everyone understands the story. Then the team might discuss the development approach or
any other technical aspect, and finally they vote.
The point with the voting mechanism is that if you start getting votes one by one, each
person will hear the opinion of everyone before them, and therefore, their answers might
be biased. We use planning poker to avoid such a bias.
The following figure shows a normal set of planning poker cards:
When using planning poker, each person picks a planning poker card that shows their
estimation, and put it face down. When everyone is ready, they will show the cards at the
same time. If the values proposed by different people are in the same range, the mean or
average of the values will be the estimate for the story. However, if there is a big difference
among the proposed values, it means that not everyone has the same understanding in the
team. Therefore, we discuss it again, learn from each other and vote again until the values
are in the same range.
Is there a difference between 40 story points and 41 story points when we are estimating?
Of course not; that is why we do not have all the values in the planning poker cards. The
best option is to use the Fibonacci series, in which each number is the sum of the previous
two numbers:
0 ½ 1 2 3 5 8 13 20 40 100 ?
EXIN Agile Scrum Foundation Workbook
Page 54
Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, …
The difference between each two number is really appropriate. However, the values
themselves are not rounded; so, we can round them if we like:
A rounded Fibonacci sequence: 1, 2, 3, 5, 10, 15, 20, 35, 50, 100
The reference story is not always the smallest possible story, so we also add ½. Even in this
case, some stories might be smaller than ½ story point, so we also add 0! Yes, zero means
that the story is just too small to be estimated.
On the other hand, even 100 story points or any other big number might not be enough for
some of the epic user stories at the bottom of the Product Backlog, so we also add an ∞
(infinity) card, which shows that the story is just too big to be estimated and that we need
to break it down at some point.
So, this can be a set of planning poker cards:
0, ½, 1, 2, 3, 5, 10, 15, 20, 35, 50, 100, ∞
However, you can use any other well-formed sequence you like.
You do not even have to use numbers for estimating the story points. Some teams just use
T-shirt sizes:
However, you might want to assign numerical values to them at a certain point. It makes the
estimating session easier for some people.
Some Agile teams use mobile apps for planning poker. These simple apps are just a set of
cards: you pick the one you believe in, and show your mobile phone when everyone is ready
to do the same.
Triangulation
When we compare the story points with the reference story and assign story points to
them, we expect them to be comparable with each other. For example, if story A is 5 story
points and story B is 10 story points, we expect B to take about twice as much effort as A to
complete.
No estimation is perfect and sometimes you might find that the estimated values are
incompatible. In order to be sure about it, you can double check them by comparing pairs of
actual user stories to each other and make adjustments.
XXS XS S M L XL XXL
EXIN Agile Scrum Foundation Workbook
Page 55
Another way of improving the estimates is to have multiple reference user stories for
different sizes and use all of them for estimating each user story. For example, you can have
a reference for 1 story point and another one for 10 story points. When you are comparing
the target story with the first reference and say that it takes five times the effort (5 story
points), you should also compare it with the second reference and see if it takes half of its
effort.
Most of these extra previsions for increasing the reliability of the estimates, which involves
comparing them with more than a single user story, are called triangulation.
Triangulation Board
A very good practice for triangulating the estimates is to use a board with columns for each
value and put the user story cards (or sticky notes) in different columns to identify their
estimates. In this case, you will have a complete comparison among all the stories, and you
can easily find the inconsistencies and fix them.
0 ½ 1 2 3 5 8 13 20 40 100
This kind of estimation is very similar to the affinity estimation explained next.
Affinity estimation
Affinity estimation is sometimes a good choice. In this practice, the team starts by sorting
the stories based on their relative required effort.
Larger Stories Smaller Stories
Item #23
Item #6
Item #28
Item #26
EXIN Agile Scrum Foundation Workbook
Page 56
When they are done discussing and sorting the items, they group them into buckets of
estimated values (story points).
Ideal hours / Ideal days
Even though using story points is the preferred method, some Agile teams use “ideal hours”
or “ideal days” instead, because it is simpler to understand and explain. In this case, they
estimate the amount of time required for each user story in an ideal situation.
When we start working, we can measure the velocity and understand how much ideal time
we can deliver in each Sprint. For example, a 7 member team working 20 days in a Sprint
have 140 real days in each Sprint (aka elapsed time), while they might be able to deliver only
100 ideal days’ worth of stories (aka ideal time).
It is a better idea to use story points, because using ideal time still creates some
expectations which, in turn, can lead to the assignment of blame.
Re-estimating
Estimates are not written in stone, and we can re-estimate them to fix our previous
misunderstandings or to reflect our newly increased knowledge of the project. However, we
should take into consideration that all the project environment influence is reflected in the
velocity calculations, so we do not need to apply them to the estimation. For example, if we
understand that the customer is not as collaborative as expected, we do not need to apply it
to the estimate. Most of the estimation errors are fixed by the velocity calculations.
Estimates are just a comparison of the effort of one story point to that of the reference
story point, and therefore, only our new understandings of the amount of relative effort can
be the basis for re-estimating.
In most Agile environments, only the user stories in the Product Backlog are re-estimated,
and as soon as they are moved to the iteration backlog or are done, we do not re-estimate
them anymore.
Larger Stories Smaller Stories
1 SP
3 SP
5 SP 10 SP 20 SP
40 SP 100 SP
EXIN Agile Scrum Foundation Workbook
Page 57
Ordering the Product Backlog Items
It is up to the Product Owner to find the best possible way of ordering the Product Backlog
items, but the usual criteria are related to the following concepts:
Benefits: what are the benefits of the solution? Benefits are defined based on the
organizational strategies and are different in every company. However, monetary
benefits are the most common ones.
Cost: the amount of resources required for the item or the cost of the item is also a
very important point. Something might be valuable if it is possible to develop it with
a little effort, but not valuable if you need to spend a lot of resources on it. In an
Agile environment, the composition of the team is fixed, the cost of each Product
Backlog item will be proportional to its size (e.g. in story points), and since the
business value can be a relative value, you can simply and safely replace the cost
with size.
Risks: ordering the Product Backlog items is one of the major ways of managing risks
in a Scrum project.
In general, business value is the benefits to cost ratio, and that is why we should consider
both of them. There are lots of metrics that are a combination of both of them, such as:
ROI (Return On Investment) – ROI for a specific period shows how much of your
initial investment would be covered by the benefits. E.g. an ROI of 50% in one year
means that you will recover half of your investment cost in one year, by using the
product. Higher values are desirable. This criterion is the main and the most
common for Agile projects.
NPV (Net Present Value) – NPV shows the total amount of investment minus the
earned benefits in a specific period, and all the values are discounted to take the
inflation and returns into account. E.g. an NPV of one million Euros in ten years
means that you will earn one million Euros on top of all the money you have spent
on the project, in ten years. Higher values are desirable.
Payback Period – payback period is the amount of time it takes you to earn as much
money with the product as you have spent for the project to create it. E.g. a payback
period of three years means that you will break even with your investment in three
years. Smaller values are desirable.
IRR (Internal Rate of Return) – IRR is the discount rate in which the NPV becomes
zero. E.g. if the IRR of the project is 20%, and there is a banking system with an
interest rate of 20% or more, you would better off putting your money in that bank
instead of investing it on the project.
EXIN Agile Scrum Foundation Workbook
Page 58
In order to calculate the above metrics, we might need to calculate some other metrics,
which are only focused on the cost, instead of a combination of the cost and benefits. For
example:
TCO (Total Cost of Ownership) – TCO is a combination of both the deployment and
operation cost of the product. The point here is that if you reduce the deployment
cost, you might end up with a higher operation cost, and therefore, you need to
consider them together before assigning a budget to the deployment.
You can consider the risks on all the traditional calculations and get a completely reliable
business value (benefits to cost ratio). However, it is not easy to do so, and therefore, some
product owners prefer to keep the calculations as simple as possible and apply the risks on
top of them.
Note that every business value estimation is a rough estimate and you should not waste
time on unnecessary details that do not make any significant changes.
Release Planning
The main body of Scrum framework is only focused on incrementing, and you already know
that each Increment should be potentially releasable. We may want to have some actual
releases before the end of some projects for the customer to start receiving a return on
their investment. Besides that, a released Increment is used more seriously by the customer
and end users, and therefore, better feedback will be collected.
Planning releases is done by the Product Owner, in collaboration with the customer and
other stakeholders. There is no formal artifact or event for release planning in the Scrum
Guide, and it should be done as a part of the Product Owner’s normal activities.
If you are going to have releases, you can use any of the following options in the Scrum
environment:
Have ad-hoc releases every once in a while. After all, every Increment is potentially
releasable and the Product Owner along with the customer can decide if they want
to release the Increment after the Sprint Review.
Have releases in pre-defined intervals; e.g. every 3 Sprints. In this case, you might
want to make an exception for the first release, to make sure that the Increment has
all the “must have” items. As soon as you have the first release, you can have regular
releases.
Have releases defined by the features needed for each of them. In this case, you can
set a number of user stories for each release, and release the Increment as soon as it
has all of those features. It is preferable to only plan for one or two releases ahead of
time to ensure that the project stays adaptive.
EXIN Agile Scrum Foundation Workbook
Page 59
When you have a release plan, it is a good idea to have progress measurement for the next
release.
Artifact 2: Sprint Backlog
The Sprint Backlog is created during the Sprint Planning event, which is the first event in a
Sprint. During the Sprint Planning event, the Scrum Team collaborates on creating the Sprint
Backlog, which consists of the following:
A number of items selected from the top of the Product Backlog, based on their
estimated work and the estimated capacity of the Development Team;
The Sprint Goal, which will help describe the real meaning of the items and direct the
efforts of the Development Team;
A detailed plan for delivery of the items and realization of the Sprint Goal during the
Sprint. This detailed plan will continue to be updated during the Sprint.
The items in the Sprint Backlog are frozen after the Sprint Planning, and the Development
Team will focus on delivering an Increment of “Done” based on this plan. The items (user
stories) in the Sprint Backlog cannot be added or removed during the Sprint. However, it
might be necessary to get more information, justify, or clear some of the items during the
Sprint, which should be done in the presence of the Product Owner. The detailed plan,
which is normally not complete at the end of the Sprint Planning, will continue to be
updated as the Sprint continues.
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
process, through which other
functionalities of the website
will be more meaningful.
t.2.2
t.3.1
EXIN Agile Scrum Foundation Workbook
Page 60
In exceptional cases, when all items are Done before the end of the Sprint, the Development
Team can pick the next item from the Product Backlog and start working on it for the
remaining duration of the Sprint.
Velocity
The velocity is the number of units of work completed in a certain interval. In the case of a
normal Scrum project, it is the amount of story points the team can get done during a
Sprint.
Velocity is normally calculated by averaging the number of story points that are done in the
previous Sprints. Some teams prefer to keep the first few Sprints out of this calculation,
because they are not usually normal. Some other teams prefer to calculate a weighted
average, with a higher weight for the recent Sprints.
For example:
Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7
80sp 70sp 95sp 105sp 130sp 110sp 120sp
In this case, a simple average is about 100 story points. If we discard the first two Sprints,
the average would be about 110 story points, which is usually a better measurement.
Obviously, the velocity changes after each Sprint. We usually experience big changes in the
velocity at the beginning of the project, but after six or seven Sprints, velocity becomes
more or less constant, because we get a more constant performance, and because of the
nature of averaging.
Note that we only count the story points of the user stories that are Done until the end of
the Sprint. So, if we are almost done with a 10 point story, it would not be counted in
measuring the velocity. The story will be re-estimated for the remaining effort and will be
put back in the Product Backlog.
We use velocity for two reasons:
1. As a guide, to estimate how much work we can do in the next Sprint. If, for example,
the velocity is 100 story points, the team will pick a number of user stories from the
top of the Product Backlog worth about 100 story points.
2. As a guide, to estimate the completion date of the project. If the velocity is 100 story
points, for example, and the remaining story points in the Product Backlog is worth
1000 story points, we can estimate that it takes about 10 Sprints to finish the project
if we do not change the Product Backlog much. However, the Product Owner is
responsible for taking everything into consideration and only uses this calculation as
a guide for determining the completion date.
EXIN Agile Scrum Foundation Workbook
Page 61
So, in practice, velocity is a value that converts the relative effort-based story points into
time. An important point here is that this measurement takes almost everything into
account. For example, the amount of collaboration from the customer really affects the
amount of output we can create. We do not consider it in estimating the story points (they
are just relative effort-based units), but they are contained in the velocity calculation. So,
when we are going to pick stories for the next Sprint using the velocity measurement, the
number of user stories is compatible with the customer capability for collaboration. Velocity
measurements complete the estimations by adding all the environmental factors.
The information about the previous Sprints, which is the basis for the velocity calculation, is
called yesterday’s weather or yesterday’s news.
Artifact 3: Increment
An Increment is a sum of all completed Product Backlog items at the end of a Sprint. Each
Increment must be “Done”, and must be releasable. The Product Owner may or may not
release a certain Increment, but it should, nevertheless, be releasable (shippable).
The next figure shows how the number of stories in the Product Backlog decreases Sprint by
Sprint, as the number of features in the Increments increases.
Note that the Increment concept is cumulative: each Increment also contains the features of
the previous ones.
Artifact 4: Definition of “Done”
There should be a shared understanding of what it means for a piece of work to be “Done”.
This definition of “Done” must be discussed and agreed upon by the Scrum Team at the
beginning of the project so that future Increments can be releasable.
Sprint #4 Sprint #5 Sprint #6 Sprint #7 Sprint #8
Product Backlog Product
Backlog Product Backlog Product
Backlog
Increment #7 Increment #6
Increment #5 Increment #4
EXIN Agile Scrum Foundation Workbook
Page 62
When multiple Scrum Teams are working on a single project, it might not be possible to use
the same definition of “Done” for all teams, because they might be working on items of
different natures. In such a case, each Scrum Team will define its own definition of “Done”
and deliver its items based on that definition. However, the integration of those definitions
of “Done” should be capable of creating a potentially releasable Increment at the project
level.
A Definition of Done usually contains the following:
Development processes (specification, design, programming, integration, test,
documentation);
Organizational processes (what extra things you might have to do based on your
organizational guidelines);
Non-functional requirements (performance, security, scalability, maintainability,
usability, extensibility, etc.);
Quality criteria (e.g. coding standards).
Unless there is a standardized DoD in the company, composing a DoD is the responsibility of
the Development Team. They will also consult the Product Owner for the DoD.
Agile Documentation
One of the four Agile manifesto statements is that we value working software over
comprehensive documentation.
This is the general Agile trend to avoid unnecessary documentation. After all, many of the
project documents are prepared to be used as communication tools with the customer. For
example, a traditional requirements specification is a document used to receive feedback
from the customer. However, we can use the working software for feedback collection,
which works much better, and therefore, we do not need such documentation. Based on
our delivery method, we do not have upfront design and planning and therefore we are not
able to prepare such documents. Requirements, design, and almost everything else evolves
throughout the project.
Besides the delivery-based documentation which is normally absent in Agile projects –
unless we are forced to have them– we also have other documents such as operation
manuals, tracking and configuration documentation, etc. This type of documentation is still
required in Agile projects, and we still prepare them. However, it is not necessary to have
them as documents; an operation manual, for example, can be a simple video.
A minimum of documentation is usually necessary for every user story, and therefore, we
put it in the Definition of Done.
EXIN Agile Scrum Foundation Workbook
Page 63
Agile Testing
There are different types of tests involved in any IT project, and since we use iterative and
incremental development, almost all of them are done as a part of Definition of Done; i.e.
we do not wait for a number of user stories to be done before running any set of tests.
Because we need to run tests more frequently, it is more crucial to have automated tests
and all the tools required for it. Besides that, we should increase the code coverage as much
as it is feasible. Code coverage, or test code coverage, or test coverage, is the percentage of
code involved in the tests. With higher code coverage, it is easier to rely on the code.
On the other hand, imagine the user acceptance testing. Is it possible to consider a story
Done, if we do not have the user acceptance tests? The answer is usually no. In this case,
the user acceptance testing should be a part of the Definition of Done, and be executed
during the Sprint. When everything else is completed, we ask the customer to provide users
for testing, while we are still in the middle of the Sprint. When we pass the test, and
everything else in the DoD, we can call the Product Owner to check the story and if it was
OK based on the DoD, we can call it Done. This is why we say that the customer should
collaborate in Agile projects.
Artifact 5: Monitoring Progress toward a Goal
Up to now, we have used the burn-down chart to visualize the progress of the development
during a Sprint. You can also use a burn-down chart to visualize the progress of the whole
project, and this is called the project burn-down chart.
The Product Owner is responsible for monitoring the progress of the whole project toward
its goal. This should be done at least once per Sprint Review. The Product Owner determines
the amount of remaining work and compares it to the remaining work of the previous
Sprints, and forecasts the completion date of the project. All stakeholders should have
access to this information.
Information Radiators
Any large, highly visible display of information can be called an information radiator. They
can be large-screens or physical boards, though most people involved in Agile projects
prepare physical boards.
Information radiators are put in the common workplace, so that everyone involved can see
it and understand the status of the project or any other message that the display offers. Any
passer-by can also see and understand it; this increases the transparency of the project.
Based on the previous definition, a well-maintained Sprint board can also be considered an
information radiator. It is a combination of multiple concepts (stories, tasks, goal, DoD,
EXIN Agile Scrum Foundation Workbook
Page 64
progress, etc.), while some information radiators are only focused on a single piece of
information.
An alternative term for information radiator is big visible chart.
The most common information radiator diagrams are explained below.
Burn-Down Charts
The project burn-down chart shows the amount of remaining work, instead of the amount
of completed work; therefore, the line for actual performance goes downwards as we
proceed and the faster it goes down, the happier we will be!
0
50
100
150
200
250
300
350
400
450
500
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Actual Performance
Remaining Story Points
Time
The vertical axis (remaining work) shows the amount of work (which is a sum of all the
estimates for each item in the Product Backlog), and the horizontal axis shows the amount
of time passed from the beginning of the project or the number of Sprints passed.
EXIN Agile Scrum Foundation Workbook
Page 65
We usually add another line to present the uniform distribution of the volume of the work
across the initially estimated number of Sprints. This line acts as our planned progress, and
will be used to compare with our actual values.
0
50
100
150
200
250
300
350
400
450
500
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Initial Plan
Actual Performance
Remaining Story Points
Time
0
50
100
150
200
250
300
350
400
450
500
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Initial Plan
Actual Performance
Remaining Story Points
Time
In the above chart, we can expect the project to be completed earlier than initially planned.
A simple calculation is shown in the following diagram:
Behind
Schedule
Ahead of
Schedule
EXIN Agile Scrum Foundation Workbook
Page 66
0
50
100
150
200
250
300
350
400
450
500
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Initial Plan
Actual Performance
Remaining Story Points
Time
So, if we do not have many changes in the Product Backlog, the project will be completed in
8 Sprints (we are at the end of the sixth Sprint now).
Note that all the evaluations are based on:
The total number of story points or volume of stories instead of the number of
stories, because different stories need different amounts of effort, and it is not right
to count them as equal quantities.
The Done user stories. We do not consider the story points of the stories that are
almost complete but not Done until the end of the Sprint. 99% progress is 0% Done.
Burn-Down Bars
The amount of remaining work depends on both the stories we have done, and the changes
we have made in the Product Backlog. If we try to show a simple burn-down chart, it might
go up instead of down in a certain Sprint where we added lots of new stories to the Product
Backlog. This is not “wrong”, but it would not correctly reflect the actual performance.
You can think of multiple ways of visualizing the Product Backlog changes along with the
actual performance, and one of them is to use a type of chart usually called burn-down bar:
-400
-300
-200
-100
0
100
200
300
400
500
600
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
EXIN Agile Scrum Foundation Workbook
Page 67
The line shows the actual performance, and each bar shows the volume of the remaining
stories.
The top of the bars change based on the volume of Done stories only, and therefore, it only
goes down. We usually add a line to the top of the bars to better visualize the actual
performance.
The changes in the volume of the remaining stories in the backlog are applied to the bottom
of the bar; so, if we add new stories to the backlog, the bottom of the bar goes down, and
we will have a longer bar. If we remove some user stories, the bottom of the bar goes up to
make a smaller bar.
The following figure shows a simple calculation of the completion date:
-400
-300
-200
-100
0
100
200
300
400
500
600
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
So, assuming that we will not have lots of changes in the Product Backlog anymore, the
project is likely to be completed in 15 Sprints.
Burn-Up Charts
Any type of diagram that shows the volume of Done stories instead of the volume of the
remaining stories is called a burn-up chart, because the line or the bar that shows your
performance goes up as you work.
The following is a sample burn-up chart:
EXIN Agile Scrum Foundation Workbook
Page 68
The blue line shows the total volume of stories defined in the Product Backlog so far
(including the Done items which are removed from the Product Backlog). The black line
shows the volume of Done stories.
As you can see, the blue line clearly shows the amount of changes in the Product Backlog.
A simple calculation of the completion date can be done as follows:
This calculation is based on the assumption that the volume of the remaining stories in the
Product Backlog will not change much.
Cumulative Flow Diagrams
The following chart shoes a cumulative flow diagram:
0
100
200
300
400
500
600
700
800
900
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Defined
Done
0
100
200
300
400
500
600
700
800
900
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Defined
Done
EXIN Agile Scrum Foundation Workbook
Page 69
This is a very good way of demonstrating the changes in the Product Backlog, along with the
progress of the project. The only downside is that it is a burn-up chart instead of a more
common burn-down chart.
In order to make a simple calculation of the completion date, we can simply use the latest
backlog values as shown in the following figure:
0
100
200
300
400
500
600
700
800
900
1000
0
100
200
300
400
500
600
700
800
900
1000
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Pending Done
0
100
200
300
400
500
600
700
800
900
1000
0
100
200
300
400
500
600
700
800
900
1000
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Pending Done
EXIN Agile Scrum Foundation Workbook
Page 70
Alternatively, if we know that the Product Backlog will have more changes, we can also take
it into consideration:
As you see in the above figure, we have not included the first few Sprints in drawing the
trend line of the Product Backlog, because we always have lots of changes in them that are
usually never experienced in the rest of the Sprints. However, the way we calculate it
completely depends on the judgment of the Product Owner. And finally, remember that the
result is always just a guide, and the Product Owner is not supposed to limit themselves to a
solely mathematical calculation.
Niko-niko calendar
Not all information dashboards are about the performance of the product; they can also
cover other aspects, such as quality results or even team mood and morale. Niko-niko
calendars are used for the latter:
It is any kind of calendar, and each team member expresses their mood by drawing or
attaching an emoticon on the calendar at the end of the day.
This information can be used by the Scrum Master to find root causes of some unseen
problems, or by the whole Scrum Team in the Sprint Retrospective to plan for
improvements.
0
100
200
300
400
500
600
700
800
900
1000
0
100
200
300
400
500
600
700
800
900
1000
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Pending Done
Jul Jul Jul Jul Jul Jul Jul Jul Jul Jul Jul Jul Jul Jul
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Tom J J J K J L J J J J
Dick L L J K J L J J K J
Harry K K K J L J J K K J
EXIN Agile Scrum Foundation Workbook
Page 71
Artifact 6: Monitoring Sprint Progress
Besides the monitoring done for the whole project, we should also monitor the progress of
each single Sprint throughout its life. This is the responsibility of the Development Team and
should be done at least once per Daily Scrum.
This information is used to calculate the likelihood of achieving the Sprint Goal and
completing all items of the Sprint Backlog.
The Sprint progress information can be represented by a burn-down chart, and this chart
can be a part of the Sprint board, which everyone can see.
This performance measurement is usually based on the tasks, rather than user stories,
unless you have a lot of user stories in each Sprint. This more detailed measurement gives a
more precise burn-down chart, which is more useful for controlling the Sprint.
We usually do not estimate the tasks, but rather distribute the estimated effort of the user
story among them. For example, if the user story has 10 story points and five tasks, we give
each task 2 story points on average. This is called top-down estimation.
Scaled Scrum
The Development Team size defined in Scrum is between 3 and 9 people. This is a very
productive and high-performance team equipped with a great framework, able to deliver
the project much better and faster than expected. However, it might not be enough for
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 process, through
which other functionalities of
the website will be more
meaningful.
t.2.4 t.2.2
t.3.2 t.3.1
t.5.5
0
10
20
30
40
50
60
70
80
1 2 3 4 5 6 7 8 9 1011121314
Sprint Burn-Down Chart
EXIN Agile Scrum Foundation Workbook
Page 72
some very large projects or medium-size projects that need to be completed in a short time.
In this case, we can use a scaled version of Scrum with multiple teams.
There is no single definition of the scaled Scrum model and various resources define it
differently. However, the main idea is to have a virtual Scrum team, consisting of actual
Scrum teams instead of people, and to manage the virtual team like a real one (not in every
aspect, however). If we need to have more people in the project, we can have a virtual team
of virtual teams too.
Roles
Each team has its own self-organized, cross-functional development team, and probably a
local Scrum Master. Some resources suggest having local Product Owners, while others
dictate that there should be only one Product Owner for the whole project.
In addition to the standard roles of Scrum, we might also have these roles:
Chief Scrum Master (aka Scrum of Scrums Master): this is a high level Scrum Master
who helps the entire project follow the framework, in collaboration with the local
Scrum Masters. One person can be the local Scrum Master for multiple teams, since
being a Scrum Master is not necessarily a full-time job.
Chief Product Owner: this is the main role responsible for the Product Backlog and
collaborates with local Product Owners to fulfill the product ownership
responsibilities. Some resources are against having more than one Product Owner,
however, it seems unrealistic to expect a single person to collaborate with hundreds
of developers (making user stories clear, for example).
Product Ownership
No matter how many teams are working on the project; it is still one project, and therefore,
we should have only one Product Backlog to plan it.
The tricky part is how to divide the work between multiple teams. Some companies divide it
based on the development processes; for example, have a team for programming, another
team for testing, etc. This is not Agile, because we still need to have cross-functional teams.
A good way of dividing the work is to have, for example, a team for the web-based
functionality, another team for the mobile app, etc. Or in the case of an office suite, we can
have a team for the word processor, a team for the spreadsheet, etc.
Some companies prefer to have teams dedicated to a certain part of the project, while some
others prefer to keep it dynamic. So, in the case of an office suite, we might prefer to be
able to get all the teams to work on the word processor in a single Sprint, because it has the
highest priority.
EXIN Agile Scrum Foundation Workbook
Page 73
As we always keep the user stories in the Product Backlog independent, we can infer that
the work of the teams is also independent; well, to a degree at least.
We do not force all teams to use a single Definition of Done, because of the potential
differences among their products. However, their Definitions of Done should be compatible,
in a way that when we combine their outputs, a potentially releasable Increment will be
produced.
Scrum of Scrums
Teams have Daily Scrums, preferably at the same time as the others. When the team-level
Daily Scrums are done, one ambassador from each team represents the team in a higher-
level daily standup meeting called Scrum of Scrums, to coordinate the teams.
Ambassadors are usually one of the Development Team members who are more involved in
the current Sprint Goal progress; therefore, we may have different ambassadors each time.
Some teams are used to having their Scrum Masters represent them in the Scrum of Scrums,
but having a technical person involved in the development is much preferred.
Each ambassador answers the three standard daily standup questions, plus an extra one:
“Are you going to put something in another team’s way?”
Each team acts like a virtual member in a higher level virtual Scrum team, and therefore, we
cannot have more than 9 multiple teams in a single layer scaled Scrum model. However, we
can add a new scaling layer to the model and have up to 9x9 teams (max 9x9x9 developers).
In this case, we would need to have multiple Scrum of Scrums for each group of teams and
then a Scrum of Scrums of Scrums for the whole project. For the latter, one representative
from each Scrum of Scrums meeting will attend.
Daily ScrumsCoordination
inside the teams
Scrum of ScrumsCoordination
Among the teams
EXIN Agile Scrum Foundation Workbook
Page 74
Some companies hold Scrum of Scrums every day, while some others prefer to have it once
or twice a week.
Synchronization
It is better to synchronize the Scrum event with all the teams, so every team starts their
Sprint at the same time. Their outputs will create a single Increment at the end of their
synchronized Sprint.
Splitting Teams
Sometimes, it is not known at the beginning that the project requires multiple teams.
Maybe a change in strategies, business values, or the market convinces you to spend more
effort on the project and to create more capacity. In this case, there are different ways of
forming the new teams, including:
Forming completely new teams: this is a good option when the organization is
mature in using Agile. However, new teams are not familiar enough with the project
and this solution will have short-term inefficiency.
Splitting teams:
o Using the Split-and-Seed4 model: the original team(s) are split into multiple
teams in this model, and new members are added to make the new teams
cross functional and powerful again. The positive point in this model is that
the knowledge of the project is distributed amongst all teams. The downside
is that we would not have the original team any more, even though we might
have spent a lot of effort on its team building.
o Using the Grow-and-Split model: this is similar to the previous one, but is
more gradual. In this case, new members are added to the existing teams
until they reach their full capacity of 9. Then we split each team into two, let
them grow, and eventually split them.
4 The two team splitting models explained here are borrowed from Succeeding with Agile, by Mike Cohn.
Daily ScrumsCoordination
inside the teams
Scrum of ScrumsCoordination Among
the teams
Scrum of Scrums of ScrumsCoordination
for the whole project
EXIN Agile Scrum Foundation Workbook
Page 75
The Split-and-Seed and Grow-and-Split models are also useful for spreading and adopting
the framework within the organization (for multiple projects): we can start trying Scrum in a
pilot project, and when the team becomes skilled in the Agile way of working, we split them
to create more teams and cover more projects using the Agile framework.
Contract Types and Scrum
You may face two types of contracts in an IT development project:
Time & means or fixed unit – this is our preferred type of contract, which is
compatible with the adaptive nature of the project. In this case we can either charge
the customer based on man-hours, or per Sprint (based on a fixed team composition
and duration for the Sprints of course).
Fixed price – even though most customers like fixed price, fixed scope contracts and
even some of them are required by law to have only fixed price contracts, it is not
really Agile. This is because all fixed price contracts are based on an initial definition
of scope, which is predictive rather than adaptive. The point here is that this type of
contract is considered to have a low-risk and a high level of determinism for the
customers, while in practice, they are not so for IT development projects.
Unfortunately, there is no real solution for this. If you want to be fully Agile, you
cannot have a traditional fixed price contract. Some Agile teams find it hard to reject
such offers and therefore have some workarounds for it, but none of them are
effective enough.
Scrum Prerequisites
So, how can we be Agile? Some people expect that having an Agile team is enough, but it is
not. In order to have a real Agile environment, four elements are required:
1. An Agile team – yes, of course we need to have a real Agile team. In the case of
Scrum, we need to have:
a. An experienced Scrum Master who knows the framework well enough,
knows the common problems and has experienced effective solutions to
them, and is also a great facilitator with high levels of interpersonal skills.
b. An experienced Product Owner who understands adaptive lifecycles and the
business value, and is available to spend enough time with the customer and
the team to solve function-related problems and to maximize the business
value.
c. A well experienced, cross-functional, self-organized Development Team that
knows how to develop incrementally and iteratively.
2. A product that is capable of being produced incrementally and iteratively – not every
product is capable of this; take a building for example, can you imagine working
EXIN Agile Scrum Foundation Workbook
Page 76
Increments for it? If not, it is not possible to use Agile to build it. Some IT-related
projects are also non-incremental by nature, and therefore, you should really
investigate them at the outset.
3. An Agile company – having an Agile team is not enough; the whole organization
should also understand and respect it. If the senior managers, directors, or
department managers are not willing to empower the team, Scrum will not work
properly.
4. An Agile customer – yes, it is not just about the performing organization; the
customer should be Agile too. Some expectations we have of a customer in an Agile
environment are:
a. They should be available and willing to spend time collaborating with us.
Customer feedback is necessary for adaptation.
b. They should understand the difference between an Agile environment and a
traditional one. For example, they cannot expect us to give them upfront
planning or design.
c. They should be ready to have a time and means contract instead of a fixed
price contract.
Unfortunately, it is very common nowadays for the customers to expect the
performing organization to be Agile, even though they are not ready to accept the
consequences themselves.
There is a difference between “Agile” and “agile”. The latter just expresses the wish to have
the product as fast as possible, which has always been an interest in projects. However, the
former is more than that; it is about adopting an adaptive framework and accepting all of its
consequences, which usually turns out to be faster.
Furthermore, note that Agile projects are faster mostly because we help the customer
understand the business value of the features and avoid wasting time creating useless
features. When the customer is forced to tell you all the features upfront or to hold their
peace forever, they will use all of their creativity to think of every possible feature. This
results in the fact mentioned in the initial chapters: on average, about 45% of the features in
a piece of software are almost never used.
EXIN Agile Scrum Foundation Workbook
Page 77
3
Kanban and ScrumBan
EXIN Agile Scrum Foundation Workbook
Page 78
Kanban
Kanban is a management technique that has been popular in manufacturing for a long time,
and has recently been used in IT projects. However, what people mean by Kanban in IT
environments is usually the ScrumBan described next, instead of a real Kanban. Kanban is
just a technic rather than a framework.
There are three rules for Kanban:
1. Work should be visualized
2. Work in progress (WIP) should be limited
3. Work should be pulled instead of pushed
Now let’s see how it works.
Visualizing is really helpful, because:
It creates transparency and therefore, feedback and collaboration
It creates more control
So, we prepare a Kanban board, and visualize the work steps and the work items. The
minimum steps we need are to do, doing, and done. In an IT project, you can have your
Definition of Done visualized on the board; e.g. to do, specifying, designing, programming,
integrating, testing, implementing, documenting. It is more common to have them
simplified as to do, programming, testing, done, or something similar.
The following is a sample Kanban board:
To Do
-
Done
-
Designing
(2)
Programming
(3)
Testing
(4)
Documenting
(3)
Done Done Done Done
T
U
. . . .
. .
. . .
. .
.
Q
M
E
D
N
EXIN Agile Scrum Foundation Workbook
Page 79
In this example, there are 6 main columns:
To Do
Designing, maximum WIP (work in progress) is 2
Programming, maximum WIP is 3
Testing, maximum WIP is 4
Documenting, maximum WIP is 3
Done
The optimum work in progress limit for each step is usually found by trial and error.
Except for the first and last columns, each column has two sub columns: one for the items
that are being processed in that column, and the second one for those that are completed in
that step. The important point here is that items in both columns are counted for the work
in progress. The other point is that this is a pull system rather than a traditional push
system. When a step is done, people cannot push the completed work to the next column
and free up capacity for new work; instead, they should wait for the next column to pick the
work. So, in the above example, all columns are full based on their defined WIP, and no new
actions can be taken.
Now let’s say the documentation team is done with item G, so this happens:
These are the exact steps:
1. G is done; therefore it goes to the sub column “done” of the documentation.
To Do
-
Done
-
Designing
(2)
Programming
(3)
Testing
(4)
Documenting
(3)
Done Done Done Done
T
U
. . . .
. .
. . .
. .
.
Q
M
E
D
N
N
T
1
EXIN Agile Scrum Foundation Workbook
Page 80
2. Since documentation is the last step, G will automatically go to the main Done
column. Note that if we need an approval, it should be included in the existing
column or preferably have a separate column. We have not included such a step in
this example.
3. Now there are only two items in the Documenting column and therefore, one free
capacity. People in this column will pull item J from the previous column, since it was
marked as done for Testing.
4. Now that J is out, we only have three items in the Testing column and since the WIP
is 4, we can pull L from the previous column, which was marked as done for
Programming.
5. Again, there is an open space in the Programming column, so they can pull the item
N.
6. Now the designers also have a free capacity, so they can pull a new item from the To
Do column.
Note that all items in the To Do column should be sorted based on whatever criteria suits
our environment, and we should try to keep this order through the process. It is not always
possible to keep the order in every step, but we still try.
OK, this is the current state:
To Do
-
Done
-
Designing
(2)
Programming
(3)
Testing
(4)
Documenting
(3)
Done Done Done Done
U
. . . .
. .
. . .
. .
.
Q
M
E
D
N
T
EXIN Agile Scrum Foundation Workbook
Page 81
Some items get completed in each column after a while and are moved to the “Done”
section in the column:
We cannot have any changes on the board at this moment. Now let’s say that the designers
are also done with item T:
To Do
-
Done
-
Designing
(2)
Programming
(3)
Testing
(4)
Documenting
(3)
Done Done Done Done
U
. . . .
. .
. . .
. .
.
Q
M
E
D
To Do
-
Done
-
Designing
(2)
Programming
(3)
Testing
(4)
Documenting
(3)
Done Done Done Done
U
. . . .
. .
. . .
. .
.
Q
M
E
D
N
T
N
T
EXIN Agile Scrum Foundation Workbook
Page 82
So, what should happen now? Designers do not have anything else to do, and based on the
Kanban rules they cannot push the completed work to the next column, and since they do
not have a free capacity, they cannot get a new item from the To Do column.
In this case, the designers should move to another column and help their colleagues. Which
column? The bottleneck now is Testing.
This can be the case for everyone in the team, if, for example, the rest of the columns are all
complete and full in capacity, then their members have to move to the Testing column too.
Even the person in the To Do column, whom you can think of as a Product Owner, should
also move on to the Testing column, since it does not matter what items s/he puts in the
column, they are not going to be developed yet.
To Do
-
Done
-
Designing
(2)
Programming
(3)
Testing
(4)
Documenting
(3)
Done Done Done Done
U
. .
.
. .
.
. . .
. .
.
Q
M
E
D N
T
EXIN Agile Scrum Foundation Workbook
Page 83
So, everyone works in the Testing column until we have the first item complete in that
column and have the flow of the process back to normal. Then everyone goes back to their
original columns and focuses on their specialty again.
As you can see, people are focused on getting the product done, instead of their specialist
activities, which is mainly applied by the pull system. This system can be more effective in
terms of productivity, even though it might seem strange to stop working on a column when
you can actually work. In addition, the fact that we expect people to move to other
To Do
-
Done
-
Designing
(2)
Programming
(3)
Testing
(4)
Documenting
(3)
Done Done Done Done
U .
.
.
.
.
.
.
. .
. .
.
Q
M
E
D
To Do
-
Done
-
Designing
(2)
Programming
(3)
Testing
(4)
Documenting
(3)
Done Done Done Done
U
. . . . .
. .
.
. .
. .
Q
M
E
D
N
T
N
T
1 2
Q
EXIN Agile Scrum Foundation Workbook
Page 84
specialist areas in certain situations and help their peers seems unacceptable and
unproductive to some people. This is because they believe that one should have the
expertise to do the job, which is correct in general, but we insist on the fact that even
people who are not specialists in testing can help testers by bringing their different
viewpoints. Let’s take the person in the To Do column for example, who is usually a non-
technical business-oriented person. When s/he goes to the Testing column, s/he might
realize that they can increase the efficiency by buying more powerful equipment, so s/he
calculates the payback time, for example, and sees that it is only 8 months, which is really
good. So, the person goes to whomever they should, to convince them, get the budget, buy
the equipment, and make the testing activities faster. As you can see, this way of working is
all about throughput and team working.
You should realize that this viewpoint is really close to what we have in Agile environments
such as Scrum. In Scrum, for example, everyone is accountable for everything, ownership is
shared amongst everyone, we do not have any titles or extra roles, and therefore we are
required to help each other as much as possible. A tester in an Agile environment is not only
responsible for testing, but responsible for the whole product.
ScrumBan
There are lots of misunderstandings about Agility. For example, most people think they can
just divide their predictive scope into smaller pieces, develop them in non-timeboxed
periods they call Sprints and call it Scrum, which is totally wrong. Being Agile is about being
adaptive, rather than adopting a certain set of terms.
But, how can we be adaptive? There are lots of consequences and requirements involved,
and that is why it is always better to use a predefined framework instead of reinventing the
wheel. Each framework has a certain set of rules, and capacities for tailoring. This tailoring
capacity is extremely low for Scrum, since it is really lightweight. Almost everything is
mandatory in Scrum and you cannot omit any aspects. But some people do! For example:
We use Scrum, but we do not keep the Sprints timeboxed.
We use Scrum, but we set the duration of the Sprint in the Sprint Planning.
We use Scrum, but we do not let the Product Backlog evolve.
We use Scrum, but we do not find it necessary to have Sprint Retrospectives.
All of these cases are called ScrumBut instead of Scrum. The rule is that a ScrumBut is not
Scrum. A ScrumBut is not Scrum, because when you only follow 95% of the Scrum rules, you
cannot expect 95% of its benefits; just expect about 20%.
EXIN Agile Scrum Foundation Workbook
Page 85
It is not wrong to use a non-Agile method; Agile frameworks are good solutions for IT
development and some other kinds of initiatives, but not the only way. You are not required
to limit yourself to Scrum, as other Agile frameworks might work better for you.
In some situations, Scrum does not seem to be the best possible solution. When
maintenance is the only goal or the most important part of the job, you need to respond to
bug fixes or add urgent features as soon as possible, you might want to use ScrumBan
instead of Scrum.
ScrumBan is a combination of a ScrumBut and Kanban. Even though most people say that it
is a combination of Scrum and Kanban, which is not quite right. Lots of people just call it
Kanban, which is not right either, because Kanban is a technique rather than a framework.
ScrumBan is a very simple framework: a ScrumBut, which does not have Sprints, plus a
Kanban system. So, we have a Kanban board similar to the one discussed in the previous
section, and a Product Owner with the standard roles and responsibilities managing the To
Do column (Product Backlog). The Development Team picks the items from the top of the To
Do column whenever they have free capacity, and they let it flow to the next columns based
on the Kanban Rules.
So, the main difference between the type of ScrumBut we use here, and a real Scrum is that
we do not have Sprints. However, when do we have the rest of the events? This is how we
manage it:
Planning meeting (Sprint Planning): we do not need it anymore.
Review meeting (Sprint Review): it is still required and essential, because the
framework is adaptive nevertheless, and we need the customer feedback. The
review meetings are held as follows:
o Either after a certain volume of work (e.g. after developing each 100 story
points), or
o In certain intervals (every three weeks)
Retrospective meeting (Sprint Retrospective): it is still required, and it would be held
after each review meeting.
Daily standup (Daily Scrum): it is still required, and is done daily.
And this is the state of the artifacts:
Product Backlog: exactly the same as the Scrum Product Backlog. It is visualized as
the To Do column in the Kanban board.
Sprint Backlog: we do not have it anymore.
Increment: we still have the same definition for increments and they are the output
we have right before each review meeting.
Definition of Done: exactly the same as the Scrum DoD.
EXIN Agile Scrum Foundation Workbook
Page 86
Monitoring progress toward a goal: this project measurement is done exactly like we
do it in Scrum.
Monitoring Sprint progress: we do not have it anymore.
Some customers and Product Owners might prefer ScrumBan, because it seems easier to
use. However, we usually have a lower productivity rate in this framework because we do
not have the safe and calm environment created by Sprints. Therefore, you should keep
using Scrum, unless you really have to switch to ScrumBan.
EXIN Agile Scrum Foundation Workbook
Page 87
The Journey Starts
We hope you have found the book helpful. We also hope that you will be the next successful
adopter of Agile frameworks. Do not forget that becoming Agile requires a change in your
mindset.
We would be glad to receive your feedback. Our email addresses are
[email protected] and [email protected].
Good Luck
Nader K. Rad, Frank Turley