EXIN Agile Scrum Training Manual

EXIN Agile Scrum Foundation Workbook

Page 0

EXIN Agile Scrum

By Nader K. Rad, Frank Turley

Foundation Workbook

http://mgmtplaza.com/












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.








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







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







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






http://nader.pm/

http://www.mgmtplaza.com/

http://mgmtplaza.com/frank-turley/

http://www.mgmtplaza.com/

http://linkedin.com/in/frankturley




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.






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


Page 6

1

Agility Concept








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.







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








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








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.








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







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







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.







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.







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.







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:







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.







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








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.







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).







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”.







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.







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;







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








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.







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







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.







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.







Page 29

2

Scrum Framework








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).






https://www.scrum.org/Scrum-Guide


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


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








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.







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


Scrum coach and facilitator

3 to 9 people

Full-time (recommended) Specialists








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.


1 person


Business-oriented

1 person



3 to 9 people

Full-time (recommended) Specialist








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








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


1 person


Business oriented

1 person



3 to 9 people









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.


1 person


Business-oriented

1 person



3 to 9 people









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.







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








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








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.


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








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







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









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.







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








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.











t.2.4 t.2.2

t.3.2 t.3.1

Sprint

Retrospective

Daily

Scrum

Sprint

Review

Sprint

Planning

Sprint










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.











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









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









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:







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







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.







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.







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 ?








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








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





































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








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.







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.







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.


The goal of this Sprint is to









t.2.2

t.3.1








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.







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.


Product Backlog Product

Backlog Product Backlog Product

Backlog










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.







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,







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.







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


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


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









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


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








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:







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









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









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









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


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








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.







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








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








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







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.







Page 77

3

Kanban and ScrumBan








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








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




















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













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



















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














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




























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%.







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.







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.







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






mailto:[email protected]

mailto:[email protected]

EXIN Agile Scrum Training Manual

Documents

Transcript of EXIN Agile Scrum Training Manual