263185194 EXIN Agile Scrum Training Manual (1)

EXIN Agile Scrum Foundation Workbook


By Nader K. Rad, Frank Turley

Page 0


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 1


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


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 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 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 3


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 elearning 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:   

Page 4

The PRINCE2 Foundation Training Manual and video course The PRINCE2 Practitioner Training Manual The PRINCE2 Sample Project

More about the author:

http://mgmtplaza.com/frank-turley

Author’s website:

http://www.mgmtplaza.com

Author’s LinkedIn Profile:

http://linkedin.com/in/frankturley


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

Prerequisites:

none



Type of questions:

multiple choice



Number of questions:

40



Pass mark:

65%



Open book:

no

Since there are no prerequisites for the exam and based on the fact that you can register and take the exam online, it is really accessible for everyone, especially those who prefer to self-study. This book covers almost everything you need to know for the exam. You would easily pass the exam by reading this book entirely and carefully. However, the Agility concept is wide and you can always come across a question on a topic that is not covered in this training manual. This book is approved by EXIN as a resource for the EXIN Agile Scrum Foundation exam. You can find out more about the exam here: https://www.exin.com/NL/en/exams/&exam=exin-agile-scrum-foundation You can take a sample Agile Scrum Foundation exam via the same webpage when you are ready.

Page 5


1 Agility Concept

Page 6


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. Ther e 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

Page 7

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


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

Detailed

project plan

project plan

Analyze

Scope prediction

Design

Construct

Integrate

Test

Architecture

Product

prediction

The first step (Analyze) is to specify the requirements and defi ne the scope of the project. It is very important to have a well-defined scope to avoid further problems in traditional environments. The output is a document that might be called “Requirements Specification” or something similar. The second step (Design) is to design the architecture of the solution, resulting in a document that might be called “Solution Architecture”. The third step (Construct) is to build the software in its entirety. Then, in the fourth step, the code is integrated and finally tested and debugged in the last step. This is the traditional way of developing IT solutions and it is still commonly used in many organizations today. It is often referred to as the Waterfall model . The main characteristic of this lifecycle is that everything is defined before the development starts and there is a clear separation between the processes. There might be some overlap between the processes sometimes, but it would still be a Waterfall lifecycle. This characteristic of defining everything upfront and trying to stick to it is called predictive, so the model that we have just described is a predictive lifecycle. The Waterfall model is a common name for the predictive lifecycles in the IT development world. In a predictive lifecycle, the project is run step by step. Each step is dedicated to a certain concept of the project and everything is designed and planned upfront. This lifecycle is great for many projects, such as building a house, hospital, or airport. However, when it comes to IT projects, it is very hard to use such a system because the customer usually does not know exactly what they want, and therefore, they keep changing the requirements throughout the project. Think of a project to build a hospital: it may face lots of changes, but is it possible that you would end up with a theme park instead of a hospital? Of course not. However, it is quite possible for IT projects to start creating something like a “hospital” and end up with something like a “theme park”!

Page 8


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 e nd of the project). We can use the following lifecycle to avoid this problem: 

Analyze



Analyze



Analyze



Analyze



Analyze



Analyze



Design



Design



Design



Design



Design



Design



Construct



Construct



Construct



Construct



Construct



Construct



Integrate



Integrate



Integrate



Integrate



Integrate



Integrate



Test



Test



Test



Test



Test



Test

Iteration 1

Increment (product)

Iteration 2

Increment (product)

Iteration 3

Increment (product)

Iteration 4

Increment (product)

Iteration 5

Iteration 6

Increment (product)

Increment (product)

We use a number of iterations in this lifecycle, which are called Sprints in Scrum. We run all the development processes on a part of the product in each iteration. The main reason for using iterative lifecycles is to have interim solutions at the end of each iteration, show them to the customer, receive their feedback, apply this feedback to the ne xt 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 f ew 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 miniwaterfall inside each iteration. A mini-waterfall runs all the development processes for all iteration items in the same time: specifies the iteration, then designs it, then builds it, etc. We use mini-agile inside iterations, which focuses on single features at a time, and runs all the development processes for them separately.

Page 9


Each development process is run once to cover all features.

Feature 1 Feature 2 Feature 3 Feature 4 Feature 5

Mini-Waterfall (wrong)

Each development process is run separately for each features.

Feature 1 Feature 2 Feature 3 Feature 4 Feature 5

Mini-Agile (right)

Iteration 1

Iteration 2

Increment roduct

Iteration 3

Increment (product)

Iteration 4

Increment roduct

Iteration 5

Increment (product)

Iteration 6

Increment (product)

Increment roduct

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

Page 10

Ward Cunningham Martin Fowler

Andrew Hunt Ron Jeffries

Robert C. Martin Steve Mellor

Dave Thomas


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 o nly 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 h ave 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:

Page 11

Responding to change over following a plan


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 e ach change is a step closer to what the customer really wants. Principle 3:

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

The customer will have a better understanding of what they want when they see the working software. We will receive feedback and use it for adaptation. Different frameworks have different iterations. In Scrum, for example, we are not allowed to have iterations longer than one month, while some other frameworks accept longer iterations. We always prefer shorter iterations, as long as it is enough for creating a meaningful increment (working software). Principle 4:

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

The involvement of the business/customer is usually limited to specifying the requirements at the beginning of a predictive environment, and again at the end, to approve the final solution. However, we need them to collaborate

Page 12


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-toface 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” backlog 2 items (backlog items must be non-technical). And it is OK; after all, the backlog items are small enough to show our progress by a simple done/not-done measurement. Principle 8:

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

2

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

Page 13


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

Continuous attention to technical excellence and good design enhances agility.

Avoiding upfront design does not mean that you do not need to be worried about the design. Agile projects do have design; it is just done inside each iteration for each backlog item. We should always pay attention to technical excellence and good design to avoid problems; not forgetting that the goal is a “good enough” solution rather than a perfect one. Principle 10: Simplicity – the art of maximizing the amount of work not done – is essential.

An Agile project is managed and delivered in a simple manner. Scope management, for example, is handled simply by putting the essential information on an index card or sticky note. We do not need sophisticated tools to handle the project, and keeping it simple makes it easier to collaborate with the customer. Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.

People usually work better when they are respected and have the authority to decide how they work. It is better if all team members are accountable for everything in the project. For example, designers do not work in isolation; they are in constant contact with the programmers, and can use this information to improve the designs and make them more practical. Principle 12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

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

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

Page 14


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 deve lopment 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 y our organization and you have the required potential, then you will have a much higher chance of success using Agile frameworks. The more uncertainty and change you have in a project, the more useful Agile frameworks will be.

Page 15


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 ex pectation 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 t his action and helps with the interpretation of the story. The reason for some stories is so obvious that you might not need to mention it. There are two essential rules about Product Backlog items:

Page 16


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 on e of the main features of an adaptive lifecycle. The Product Backlog is a dynamic concept for storing the items that we are going to develop. So, 

When we are done with an item, we take it out of the Product Backlog;



When we select a number of items from the Product Backlog to be developed in the next iteration, we take them out of the Product Backlog and put them in the iteration backlog (the Sprint Backlog in case of using Scrum);



If an item is not done until the end of the iteration, we put it back to the Product Backlog; even if it is in progress.

We usually assign a business value to each Product Backlog item and sort the list, so that items with more business value are placed higher. When we want to start a new iteration, we should pick items from the top of the Product Backlog, which means that we always develop items that have the highest business value. This is how we stay focused on the value and the business needs. Some Agile frameworks use methods such as MoSCoW prioritization instead of, or in combination with the quantified business value assignments to sort the backlog items. We will discuss MoSCoW prioritization later in this chapter. The Product Backlog is the main planning tool in most Agile frameworks. It contains the scope of the project, along with a level of time, resource, risk, and quality plan, in the simplest possible way.

Page 17


Functional vs. Non-Functional Features Each item in the Product Backlog explains a feature of the final solution, preferably in the form of a user story. One confusing problem is how to handle non-functional features, since they are technical by nature; user stories should be non-technical. Our previous examples of user stories are all functional features. Other features such as performance and security are examples of non-functional features. Non-functional features are those which should be applied to almost all functional features. Take performance for example: there are performance considerations for every functional feature. E.g. we do not expect a simple search to take two minutes. The solution is to add the non-functional features in the Definition of Done (DoD). The Definition of Done is a concept that contains all the things we should do or consider for every user story. The development processes, quality criteria, coding standards, and non-functional features are all parts of the Definition of Done. So, when we are developing any user story, we would check them against non-functional features mentioned in the Definition of Done, and we would not call them “done”, unless they adhere to all of them. This is what we usually call acceptance criteria in traditional environments and it is a part of quality planning. Some non-functional features might be applicable to only a few user stories and therefore, the Definition of Done would not be an appropriate place for them. In this case, we just add them to the back of the user story card. Yes, we might have some extra information about some user stories, such as special acceptance criteria, descriptions, specific non-functional features, etc. The front of the card belongs to the user story text (e.g. as an administrator, I want to reset passwords), the business value, and the estimate (story points). The back of the card belongs to everything else. For example, how do we inform the user of the changed password, what kinds of passwords do we accept, etc. And yes, it has to be short; we do not have that much space on the back of the card, and that is the whole point: we should keep it simple.↑ ID: 0209

Value: 2842

As an end user, I want to reset my



Only strong passwords are acceptable.



Password reset link should be sent to the registered email address.

password, so that I can have a ccess to 

my account again.

The user should answer the security question correctly before having the

Estimate: 5 SP Front side of a sample backlog item

password reset.

Back side of a sample backlog item

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

Page 18


Bugs We create a working increment of the final solution at the e nd 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 board 3 for the management of bugs in this case.

It is inevitable that we will have some bugs; but how many? If you have lots of bugs, maybe you should improve your Definition of Done by adding more tests, improving the way you develop, etc. It is really important to be proactive. If a defect is not detected by the development team and is found by the end users after a release, it is called an escaped defect . The number of escaped defects is an important metric for measurement of the quality of work.

Spikes Sometimes we are not sure how to develop something from a technical point of view. In this case, we use a “spike” to investigate it; a small development activity to learn the technical elements of the solution. There are two types of spikes: 1. Technical spikes: these are focused on finding the development approach; 2. Functional spikes: these are more about prototyping and finding or understanding the required functionality.

3

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

Page 19


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 e nable the team to give an estimate for the user story. It is not a complete exploration, but rather a quick and fast study, aiming at understanding and estimating.

MoSCoW Prioritization The MoSCoW prioritization is a great technique for scope management and is an essential part of DSDM Atern. It is not very common yet to use it in Scrum frameworks, but it is a good idea to use it anyway. MoSCoW is a combination of the first letters of Must Have, Should Have, Could Have, and Would not Have This Time. In this technique, we assign one of those letters to each feature, based on the following definition: 

M (Must Have) – is a feature that must be in the final product, and the final product would be useless without it. E.g. brakes in a car.



S (Should Have) – is a very important feature for the final product, and we will face problems without it. However, we can find a workaround for that (using another solution in parallel, doing it manually, etc.) and still use the solution that lacks it. E.g. air conditioning in a car.



C (Could Have) – is a really helpful feature that we would really like to have in our solution, but frankly, it would not create a problem if we do not have it. E.g. A camera and display in the car, which can be used to help with reversing.



W (Will not Have This Time) – is a nice feature, but we are not going to invest in it now. Maybe later. E.g. online monitoring of the mechanical status of the car.

When we assign these priorities realistically, we know that the minimum for an acceptable product is the solution containing all the M user stories. Our expected product is the one that contains all the M and S user stories. The ideal product is the one that contains all the M, S, and C user stories. MoSCoW prioritization is a great way of focusing on the business value: focusing on the real needs instead of the fancy features (Could Have items).

Page 20


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 de crease the quality in order to deliver all the features. This is not favorable in Agile frameworks. We focus on the business needs in Agile frameworks, and compromising time and quality is not a good idea, because IT products have a very short operational lifetime. If we spend more time creating a solution just to have all the fancy features included , we are losing value. Some Agile frameworks do not allow changes in duration. The project is guaranteed to be finished on time. If something goes wrong, we will drop some of the unnecessary features (scope) instead. DSDM Atern is one of these frameworks. The following figure shows the classical triple constraints of projects and the different ways in which we can handle them:

Atern Approach Features

Fixed

Time

Cost Quality



Quality?

Time

Cost

Variable

Features

Traditional Approach

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

Page 21


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

Always 7% Often 13%

Never 45% Sometimes 16%

Rarely 19%

The average use of software features (2011) This is the disaster we are trying to avoid in Agile environments: nearly half of the features in an average software are almost never used, which means we are spending twice as much time and money; a real waste. The main reason that Agile projects are faster is that we are incorporating a mechanism that eliminates such outputs. The reason for such waste in traditional environments is that we force the customer to specify everything upfront, and since change is usually followed by time and cost claims later in the project, the customer tries to think about every possible feature they might need. As it turns out, most of those upfront specified features are useless. We do not have this problem in Agile projects due to two reasons: 1. We do not force the customer to specify everything upfront, so they do not need to be over-creative by defining every possible feature. Besides that, they know that we welcome changes at any time, so they can relax. 2. We help the customer understand the business value of each feature and avoid those that do not really help the business, even if they have been defined in the Product Backlog.

Page 22


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 en vironments all the time, and we need to focus to stay productive. So, while everything is changing, we keep short durations frozen and focus on development. The only exception is that if the timebox is of a fixed duration instead of a max duration, we can add extra activities once we are done with all the pre-defined ones. As you might have guessed, each iteration is timeboxed. They are fixed duration timeboxes in most frameworks. We also have lots of meetings either inside or outside the iterations, which are timeboxed as well; e.g. planning timebox. You can see a concrete example of Scrum timeboxing in the next chapters. Using timeboxes is a great strategy for increasing productivity, both in your personal life and in projects. Some of the advantages are: 1. It creates regularity and discipline, and in particular, helps us create potentially releasable solutions;

Page 23


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

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

Strategy

Portfolio Product Release

Iteration Day

The strategy and portfolio planning levels are outside the projects, handled by the broader management systems of the organization. Strategy planning defines the benefits for the organization (e.g. earning money), and the portfolio level picks and resources the best possible projects to optimize the benefits. Inside each Agile project, there are four conceptual levels of planning: 1. Product planning – usually done in the Product Backlog and probably some additional high-level plans such as the product vision, based on the framework in use. 2. Release planning – this level plans when increments should become available to the end users for actual operations. In some frameworks such as Scrum, we do not have a type of planning specific to releases, because we are always ready to release the latest increment. 3. Iteration planning – in the case of Scrum, this level of planning is done in the Sprint Planning meeting, and creates the Sprint Backlog. This is a list of items (user stories)

picked from the top of the Product Backlog to be developed through the current iteration.

Page 24


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

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

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

Working is more enjoyable for people, when they are working in pairs. Well, there are sometimes conflicts, but they are not caused by pair programming; they are existing problems that have shown themselves because of the pair programming practice, and otherwise, they would have shown themselves elsewhere;



People learn more when they see each other working;



It is a team-building activity and helps create a more collaborative environment, which is required for all Agile teams;



The quality of the product is much higher when we are using this practice, which also results in fewer defects, rework, and cost.

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

Bus Factor You lose one of your project team members, for any reason (e.g. a bus hits him /her and…), and you are not able to continue the project anymore, because no one else has the key information for the project. This is a project with a Bus Factor of 1 , which is terrible. The minimum number of developers you have to lose before losing the ability to continue the project (even by adding new developers), is called your Bus Factor or Truck Factor. Higher numbers are certainly desired.

Page 25


A cross-functional and self-organized environment is a great opportunity for increasing the Bus Factor and consequently, it decreases the negative risks. However, you can have more mechanisms in place to help with this aspect by Succession planning. Succession planning is about keeping the information inside the team, instead of certain individuals, and makes it possible to switch responsibilities, or even add or remove developers in extreme cases. Pair programming is a great way of succession planning and increasing the Bus Factor, because everything is well known to at least two people instead of one. Maximizing transparency, improving the communications (daily standups, demos, configuration management systems), and practicing a real co-ownership of code are other ways of increasing the Bus Factor. The results of a successful succession plan are not limited to extreme cases of losing people. It is also very helpful for the natural flow of the project, because team members might get sick, go on vacation, or simply become distracted every once in a while. These issues can cause serious problems in a low Bus Factor environment.

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

Programmers know exactly what others expect from them and can work more productively;



Programmers will be encouraged to create the simplest possible program, just to pass the test. This is desirable in Agile environments, since we do not want to waste time creating something perfect, while all we need is a good enough solution to do the job. However, we usually need to have an eye on refactoring to make sure that the solution is still “good enough”.

Continuous Integration The pieces of code are usually integrated at the end of the project or phase in a traditional environment, while we prefer to have continuous integration in Agile environments. All programmers are required to upload their latest versions of code into the repository every hour or so. This practice enables us to be sure that our previous work is “done” and does not need too much further adjustment. However, it is required to have a reliable configuration

Page 26


management system to enable this practice without getting into problems, especially when the output is being used in operations. Some key benefits of the continuous integration practice are: 

It is easier to have real increments at the end of the iterations; releasing the solution would be much easier than in traditional environments;



We see early warnings for the conflicts and less rework in the future code.

Continuous integration is usually used in combination with automated testing environments.

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

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



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

Care should be taken not to target perfect code instead of good -enough code. A minimum continuous refactoring is required in Agile environments, because we are not developing based on an upfront design. Continuous refactoring is the Agile strategy for repaying the technical debt . Technical debt is the eventual consequence of poor development, which should be repaid sometime, and the sooner, the better.

Collective Code Ownership No one in the Agile team owns a piece of code; everyone is accountable for everything, and everyone is allowed to change any piece of code. The key benefits of collective code ownership are: 

Encouraging collaboration;



Making everyone focus on the project and its value instead of specialist activities.

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

Page 27


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

Developers are more focused on producing rather than working; they are focused on the project as a whole, rather than activities;



We will have a happier environment;



At the end of the day, we will have higher productivity.

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

Page 28


2 Scrum Framework

Page 29


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

Others 34%

Scrum 52%

Scrum+XP 14%

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

Quick Overview of the Scrum Framework Each Scrum project is done in a number of Sprints. “Sprint” is the Scrum term for “iteration”. We use a Product Backlog to define the remaining scope of the product. We pick a number of items from the top of the Product Backlog to be done through the current Sprint. We run Sprints as many times as required, until: 1. the project is finished, because: a. all the items in the Product Backlog are done; b. the customer has realized that the latest iteration is enough, and there is no justification to spend more time and money adding more features; 2. the project is terminated for some reason (e.g. it is not justified any more).

Page 30


The next figure shows an overview of the framework:

Product Backlog

Product Backlog

Sprint Backlog

Sprint #4

Increment #4

Product Backlog

Sprint Backlog

Sprint #5

Sprint Backlog

Sprint #6

Increment #5

Product Backlog

Increment #6

Sprint Backlog

Sprint #7

Sprint #8

“Done”, and Increment #7

potentially releasable

To be applied Feedback

Feedback

Feedback

Feedback

to the Product Backlog

Sprint Planning

Daily Scrum

Sprint Review

Sprint Retrospective

S rint #6

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

Sprint Planning: a short timebox for selecting the user stories from the top of the

Product Backlog and creating the Sprint Backlog; 

Daily Scrum: a 15 minute timebox to collaborate and coordinate on a daily basis ;



Sprint Review: for demonstrating the increment to the customer and receiving

feedback; 

Sprint Retrospective: for reviewing the Sprint and planning for improvements.

There are three roles in Scrum: 

Product Owner – this person is responsible for creating and maintaining the Product

Backlog, which requires constant communication and collaboration with the customer;

Page 31




Scrum Master – this person ensures that the Scrum framework is followed entirely

and correctly, which requires coaching, training, and problem solving; 

Development Team – a set of technical, yet self-organized and cross-functional

experts who develop the solution. Note: “programmers” are called “developers” in some companies. In Agile literature, a “developer” is anyone who contributes to the production of the final solution. The term “developer” can refer to analysts, solution designers, UI designers, programmers, testers, etc. The Scrum framework will be explained in the three following chapters: 

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



Scrum Events, which explains all the timeboxes defined in Scrum, and also the

development and management lifecycle of the framework; 

Scrum Artifacts, which explains the management products/concepts required in

Scrum (e.g. performance monitoring).

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

Page 32


A Scrum Team consists of the following three roles:

Product Owner

1 person Full-time or part-time Business-oriented

Scrum Master

1 person Full-time or part-time Scrum coach and facilitator

Development Team

3 to 9 people Full-time (recommended) Specialists

The term “Scrum Team” refers to all the project team members: everyone internal to the project. Scrum Team members usually have only one of the three standard roles of Scrum: Product Owner, Scrum Master, or Development Team member. It is possible, however, for a single person to be assigned to more than one of the standard roles, but it is not recommended. The Scrum Team is a part of the performing organization (the company which executes the project either for itself or as a contractor for an external customer). Other persons can also be involved in the project, but they are not considered internal to the project and Scrum theory does not have much to say about them. They should have a certain set of behaviors though, to make it possible for a Scrum project to succeed. The customer (either internal or external) should understand and adopt the Scrum framework too, as the relationship between the customer and the Scrum Team and the way we deliver the project completely changes when we switch to the Scrum framework. The Scrum Team has two essential characteristics: 

Self-organized: The Scrum Team manages its own efforts rather than being managed

or directed by others. In traditional methods, management efforts are separated and centralized; a subset of the project team is responsible for project management, and others are only responsible for specialist activities. However, management and specialist efforts are not separated in Scrum.

Page 33




Cross-functional: The Scrum Team has all the expertise and competencies needed to

get the job done without any help from outside the team. These two characteristics are designed to optimize the flexibility, creativity, and productivity needed for the Agile environment of Scrum.

Role 1: The Product Owner Product Owner


Scrum Master


Development Team

3 to 9 people Full-time (recommended) Specialist

Each project needs a business-oriented person, aimed at maximizing the business value of the product and the work of the Development Team. In Scrum, this person is called the Product Owner . Product Owners, like the two other roles, are from the performing

organization, rather than from the client side. There might be one or more people from the client side assigned to manage the product, but they would not be called Product Owners. This role belongs to one person. There can be a committee to handle the responsibilities of this role, but in such a case, there should be one person representing this committee, and we call this one person the Product Owner. They do not need to have application area knowledge of the project; they are focused on the business aspects. In software development projects, for example, Product Owners do not need to be developers themselves; they just need to know a little about development, and a lot about how the business operates. The Product Owner is responsible for the Product Backlog. The Product Backlog is a prioritized list of items (usually user stories) that the client expects from the project; this is the main planning tool in Scrum. It is also the responsibility of the Product Owner to make sure that each item (user story) is easy to understand for the Scrum Team, and other stakeholders.

Page 34


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.

Requirements

Communications

Communications

Performing Organization / Customer

Scrum Team

Product Owners understand the business, so they can rank each Product Backlog item based on its return on investment as well as any other factor they find suitable for the business point of view of the project. The items will be sorted based on their business value (or just “value” for short), so the higher they are on the list, the sooner they will be developed by the Development Team. The entire organization must respect the Product Owner’s decisions for the project to be successful. No one, not even the CEO, should allow themselves to try to override those decisions. No one should tell the Development Team what item to deliver, except for the Product Owner, who sets and orders the items. A Product Owner’s decisions might be influenced by others, but s/he must have the final say. Product Owners might delegate some of their responsibilities (such as preparing the list of items for the Product Backlog) to the Development Team, but they stay accountable for them.

Page 35


Role 2: The Scrum Master Product Owner

1 person Full-time or part-time Business oriented

Scrum Master


Development Team


Scrum Masters are those who fully understand Scrum, and help the Scrum Team by coaching them, and ensuring that all Scrum processes are implemented correctly. The Scrum Master is a management position, whereby the Scrum Master manages the Scrum process, rather than the Scrum Team. S/he is a servant-leader for the Scrum Team. Besides ensuring that the Development Team understands and uses Scrum correctly, the Scrum Master also tries to remove impediments to the Development Team, facilitates their events, and trains and coaches them. Scrum Masters help the Product Owners too, by helping or consulting them on finding techniques, communicating information, and facilitating related events. The responsibilities of Scrum Masters are not limited to the Scrum Team. They should also help those outside the Scrum Team understand the appropriate interactions with the Scrum Team in order to maximize the business value. The Scrum Master usually leads the organization in its effort to adopt Scrum. It is possible for a single person to be both a Scrum Master, and a member of the Development Team, although this is not recommended. Being a Scrum Master of a normal project might not occupy 100% of the time of a person; in this case, the best solution is to assign that same person as the Scrum Master in more than one project, rather than making them a member of the Development Team. Most of the internal and external communications about the Scrum process are done by the Scrum Master, while most of the internal and external communications about the content of the project are done by the Product Owner. Note that the Scrum Master is not involved in

Page 36


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

Role 3: The Development Team Product Owner


Scrum Master


Development Team


Members of the Development Team are application area experts who are responsible for delivering backlog items, and managing 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 ne ed 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. me mbers. For large projects, we can use a scaled model with multiple Scrum Teams.

Page 37


Other Roles You might have the temptation to give Development Deve lopment 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 Master ’s responsibilities 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. management ? So, a better question to ask is: what happens to project management

The project management responsibilities are distributed among 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. 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 re st of the stakeholders, including the customer and senior management are just chickens.

Page 38


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

Scrum Events Introduction to Scrum Events Sprint Planning

Daily Scrum

Sprint Review


Sprint

There are five events in a Scrum Project: 1. Sprint: Each Scrum project is a set of Sprints. A Sprint is a container for the four other events (as represented in the above diagram), development effort, and the maintenance of the Product Backlog. 2. Sprint Planning: Sprint Planning is the first event inside a Sprint. The Scrum Team plans the items they are going to deliver d eliver in the Sprint and the way they will deliver them. 3. Daily Scrum: The Development Team starts working on the objectives of the Sprint as soon as Sprint Planning is completed. During the Sprint, the Development Team holds a daily meeting (15 minutes) to coordinate the work for the next 24 hours. This meeting is called the Daily Scrum. 4. Sprint Review: Before the end of the Sprint, the Development Team presents (demonstrates) the outcome of the Sprint to the customer and receives feedback. This meeting is called Sprint Review (also known as Sprint Demo ). 5. Sprint Retrospective: After the Sprint Review and just before the Sprint is over, the Development Team holds an internal meeting to review the Sprint and use it to improve the process (lessons learned) in the next Sprint. This meeting is called Sprint Retrospective. These events are designed to enable critical transparency, inspection, regularity, and adaptation. We prefer to use these predefined meetings with fixed objectives and maximum durations (timeboxed) instead of ad-hoc meetings, which usually waste our time.

Timeboxing There is an essential concept in Agile methods, called timebox : a predefined maximum duration of time. In order to maximize productivity, all the Scrum events must be timeboxed. The duration of a timebox should be agreed upon and fixed. We are free to change the duration based on lessons learned, but not frequently, and never based on single occasions.

Page 39


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 ti meboxes 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 colocation, 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 Planning

S rint

Page 40

Daily Scrum

Sprint Review



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

Sprint #5

Increment #5

Sprint #6

Increment #6

Sprint #7

Increment #7

Sprint #8

Sprint #9

Increment #8

Sprint is a timeboxed event, which means we should fix its duration at the beginning of the project and not change it. Sprints are usually fixed at one month or less. An important point is that we do not change the items of the Sprint Backlog after the Sprint is started, and the plans are set. The Sprint Goal (discussed further in Sprint Planning) should not change either. The Product Owner and the Development Team might try to clarify and renegotiate the scope as more is learned about the items to be delivered, but they will not change the Sprint Backlog stories. Even the composition of the Development Team should

not change during a Sprint. These constraints are designed to make it possible to focus and get things done. Each item (user story) in the Product Backlog should normally be developed in a single Sprint as this is much easier to manage. The Product Owner and the Development Team select a number of items from the top of the Product Backlog (this has already been prioritized by the Product Owner) and aim to g et them “Done” (100% complete). We want them to be really “Done” when the Sprint is over, and create an Increment. An Increment is the sum of all the completed items created during the current Sprint and all previous Sprints. It is important to agree on a definition of “Done” at the beginning of the project. We will not call something “Done”, unless it fits the definition. A 99.999% completed item is not considered as “Done”, it would not be part of the Increment, and it would not be demonstrated to the customer at the Sprint Review.

Page 41


Setting the Duration of the Sprints Most companies use Sprint timeboxes of 2 to 4 weeks. If we use Sprints longer than one calendar month, it is likely that the unapplied changes will become large enough to create problems. This will increase the complexity and risk. Therefore, we should keep the Sprints to no more than one calendar month. Sprints should not be too short either, because we would not be able to produce complete Backlog items during it. Our goal is to deliver the final product item by item, inside the Sprints; we do not want to split a single Product Backlog item across several Sprints. Another important point about setting the duration of the Sprints is the amount of adaptation needed for the project. A project with two-week Sprints receives almost twice as much feedback and opportunities for adaptation as a project with four week Sprints. We do not change the duration of Sprints on an ad-hoc basis. E.g. we are not allowed to say that we have to develop lots of user stories this time, so let’s have a longer Sprint. However, if we realize that the duration we have chosen is not appropriate for the project, we are free to revise it for the rest of the Sprints. We do not expect to make such changes often.

Overtime Work, Buffers, etc. There are two common questions about managing the Sprints: 

Are we allowed to do overtime work to complete all the Sprint Backlog items? It is not forbidden, but highly discouraged. One of the Agile principles is to have a constant pace, to keep the quality of the product and the morale of the team. So, it is better to avoid overtime work. Note that the Sprint Backlog only contains what we estimate we can get done during the Sprint, and we do our best to deliver all of them, but there is no guarantee. All projects have a high level of uncertainty, especially IT projects.



Is it possible to have a buffer or contingency time for the Sprints to make sure that we can get everything done? Again, you should not be worried about getting everything done. The Sprint is timeboxed and we do not extend it, not even for one

day. There are also no buffers at the end of the Sprints. The team might prefer to only assign a percentage of its capacity (e.g. 80% or 90%) to develop the user stories and the rest for the pet projects, spikes (research on the same project), etc.

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

Page 42


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

Sprint 0 There is no such thing as Sprint 0, and there is no difference between the first Sprint and the rest of the Sprints. We just start delivering potentially releasable increments as soon as the project is started, and do not spend any time designing or preparing before it. Well, we have to spend a few days at the beginning, creating an initial state of the Product Backlog, enough to define the first one or two Sprints before starting the Sprints. However, this duration should be limited, and we do not wait until every user story is defined and estimated, because it is not an adaptive approach.

Event 2: Sprint Planning Sprint Planning

Daily Scrum

Sprint Review


Sprint

The Development Team does not wait until the Product Backlog is 100% planned (all requirements are gathered and cleared) to start developing the project. As soon as the Product Backlog is mature enough (has the necessary number of stories) to provide the information for the first Sprint, the Product Owner and the Development Team can start the first Sprint. The first thing to do in each Sprint is Sprint Planning. Sprint Planning is a timeboxed meeting, usually fixed to 8 hours for a one-month Sprint, or shorter for Sprints of less than a month. All three roles should attend this meeting. The Development Team should estimate the capacity of work it can deliver in a single Sprint. The Product Owner has already ranked and ordered the Product Backlog based on the value of the items. The Product Owner also ensures that the items (stories) are easy to understand. The Development Team then selects an appropriate number of items from the top of the Product Backlog, and puts them in the Sprint Backlog, to deliver in the current Sprint. The amount of work for each item is estimated by the Development Team and the total amount of work of the selected Product Backlog items is close to the estimated capacity of the Development Team. Following the selection of the items, the Scrum Team should draft a Sprint Goal. The Sprint Goal is an objective that should be met within the Sprint by the implementation of the

Page 43


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 f acilitates setting Sprint Goals, and composing the goal is the responsibility of the whole Scrum Team. The scope of the Sprint, which is made up of the items selected from the Product Backlog, might need to have more details added to during the Sprint. These details should be aligned with the Sprint Goal, and in the likely event of renegotiations, they should be done in the presence of the Product Owner. The Sprint Goal is also included in the Sprint Backlog. When the items to deliver are selected and the Sprint Goal is agreed, it is time to plan how to deliver the items into a “Done” product Increment and realize the Sprint Goal. This is the last part of the Sprint Backlog. The Sprint planning is not necessarily completed in this meeting. Having a detailed plan for the first few days is enough; the Development Team can prepare detailed plans for the rest of the work later . A detailed plan is a breakdown of a Product Backlog item into detailed tasks which needs to be done in order to create the item. Each task might have estimates, dependencies, and other similar information to make tracking possible. The Sprint Backlog will be ready at the end of this meeting, and the Development Team should be able to describe what items they will deliver through the Sprint, and how they will do it.

Page 44


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

Sprint Goal

To Do

Doing

Done

The goal of this sprint is to make the purchasing part of the website mature enough to be able to handle the whole process and users can t.2.2

experience a full purchasing process, through which other functionalities of the website will be more meaningful. t.3.1

Yellow sticky notes on the board above are tasks that are created by breaking down each of the blue user stories. These tasks define what the Development Team will do to deliver each item, and they are responsible for preparing them. Some tasks are created at the Sprint Planning meeting, and some others during the Sprint. The Sprint Backlog consists of the following: 1. The Sprint Goal; 2. Selected items from the Product Backlog, to be delivered during the Sprint; 3. A detailed plan for turning the selected items (stories) into “Done” Increments of the product and to realize the Sprint Goal. As you can see, the three Sprint Backlog elements (Sprint Goal, Product Backlog items selected for the Sprint, and the detailed plan) are shown on the sample board. This sample Scrum board also has extra features for tracking the tasks and items in “To Do”, “Doing”, and “Done” columns. The next figure shows the same Sprint after the first item is Done and items #2 and #3 are in progress.

Page 45


Sprint Goal

To Do

Doing

Done

The goal of this sprint is to make the purchasing part of the website mature enough to be able to handle the whole process and users can experience a full purchasing

t.2.2

t.2.4

process, through which other functionalities of the website will be more meaningful. t.3.2

t.3.1

You can also see that extra tasks have been added to the lowe r ranked items (items #3 to #5). This is how the detailed plan of the Sprint evolves while it progresses. Items in the Sprint Backlog usually have the same order they had in the Product Backlog, and therefore, the Development Team should work on the higher ordered items first.

Event 3: Daily Scrum Sprint Planning

Daily Scrum

Sprint Review


Sprint

The Daily Scrum is normally a 15-minute meeting for the Development Team to inspect the work done since the last meeting, and to synchronize their work and plan for the next 24 hours. It must be held on a daily basis. During the Daily Scrum, each member of the Development Team should ans wer these three questions: 1. What has been accomplished since the last meeting? 2. What will be done before the next meeting? 3. What obstacles are in the way? They should assess progress towards the Sprint Goal and forecast the likelihood of completing the items before the Sprint is over.

Page 46


The Daily Scrum meeting should be held at the same time and place throughout the Sprint, in order to minimize the complexity. It is just for the Development Team; it is not a status meeting for all the stakeholders. The Development Team should also monitor Sprint progress each day, and therefore, it is a good idea for the Sprint board to be visible during the Daily Scrum meeting. They can use a burn-down chart to track their remaining work and to check if they are going to complete all items before the end of the Sprint. Sprint Goal

To Do

Doing

Done

The goal of this sprint is to make the purchasing part of the website mature enough to be able to handle the whole process and users can experience a full purchasing

t.2.2

t.2.4

process, through which other functionalities of the website will be more meaningful. t.3.2

t.3.1

Sprint Burn-Down Chart 80 70 60 50 40 30 20 10 0 1 2 3 4 5 6 7 8 9 1011121314

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

Event 4: Sprint Review Sprint Planning

Daily Scrum

Sprint Review


Sprint

The duration of this meeting is normally four hours for a one-month Sprint. If the Sprints are shorter then the meeting will be proportionally shorter. At the end of the Sprint, the Scrum Team and other stakeholders gather and hold a fourhour meeting to present and inspect the “Done” items (the Increment) from the current Sprint. The presentation of the Increment in this meeting is intended to collect feedback and raise change requests as soon as possible.

Page 47


We welcome changes in Scrum and encourage them to be demanded, because it increases the satisfaction of the customer and will create a final product that better matches the needs of the customer. The Development Team does not present an item, unless it is 100% complete based on the agreed definition of “Done”. The Product Owner makes sure (before the Scrum Review) that presented items are “Done”. The Development Team demonstrates and explains the items. Note that 99% progress is just 0% “Done”. It is not even common to calculate any percentage complete values in Agile projects, since the only measure of performance is the “Done” pieces of product. This is nothing to worry about, since the Product Backlog items are usually small. Any user story that is not “Done”, will go back to the Product Backlog and the Product Owner will order it again. If it is still at the top of the Product Backlog, it will be picked to be completed in the next Sprint. The Product Owner discusses the status of the Product Backlog, and the likely completion dates based on the progress.

Project Status

Increment demo

Feedback

Performing Organization Customer

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

Event 5: Sprint Retrospective Sprint Planning

S rint

Page 48

Daily Scrum

Sprint Review



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 doe s 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 on going 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 e stimating. 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 t he framework: 

The Development Team is self-organized, so if they believe that they need to take some days off, they should decide to do so, instead of having it in the framework.



Besides that, having a constant pace is essential, and we do not expect the team members to be under abnormal pressures in any Sprints and need a special rest afterwards.

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

Page 49


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 it ems. 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 50


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 51


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:

Page 52



They are effort-based instead of time-based;



They are relative.


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 tha t 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 y ou 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:

0

½

1

2

3

5

8

13

20

40

100

?

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 e stimating? 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:

Page 53


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:

XXS

XS

S

M

L

XL

XXL

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.

Page 54


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

Item #23 Item #26

Item #28

Item #6

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.

Smaller Stories

Page 55

Larger Stories


When they are done discussing and sorting the items, they group them into buckets of estimated values (story points).

Smaller Stories

Larger Stories

5 SP

1 SP

10 SP

3 SP

20 SP

40 SP

100 SP

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.

Page 56


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 co st 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 maj or 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. a n 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 57


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 e stimate 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 re lease 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 58


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. Sprint Goal

To Do

Doing

Done

The goal of this Sprint is to make the purchasing part of the website mature enough to be able to handle the whole process and users can t.2.2

experience a full purchasing process, through which other functionalities of the website will be more meaningful. t.3.1

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.

Page 59


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 80sp

Sprint 2 70sp

Sprint 3 95sp

Sprint 4 105sp

Sprint 5 130sp

Sprint 6 110sp

Sprint 7 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 p roject. 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 60


So, in practice, velocity is a value that converts the re lative 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.

Product Backlog

Sprint #4

Increment #4

Product Backlog

Sprint #5

Increment #5

Product Backlog

Sprint #6

Increment #6

Product Backlog

Sprint #7

Sprint #8

Increment #7

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 “D one”. 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.

Page 61


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 Tea m 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 r eleasable 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 62


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 63


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! Remai ning Story Points 500

Actual Performance

450 400 350 300 250 200 150 100 50 0 1

2

3

4

5

6

7

8

9

10

11

12

13

14

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 64


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.

Remai ning Story Points 500

Initial Plan

450

Actual Performance

400 350 300 250

Behind

200

Schedule

150 100 50 0 1

2

3

4

5

6

7

8

9

10

11

12

13

14

Time

Remai ning Story Points 500

Initial Plan

450

Actual Performance

400 350 300 250

Ahead of

200

Schedule

150 100 50 0 1

2

3

4

5

6

7

8

9

10

11

12

13

14

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:

Page 65


Remaini ng Story Points 500

Initial Plan

450 Actual Performance

400 350 300

250 200 150

100 50 0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

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 h ave 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 wo uld 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 : 600

500

400

300

200

100

0 1 -100

-200

-300

-400

Page 66

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17


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: 600

500

400

300

200

100

0 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

-100

-200

-300

-400

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 67


900 800 700 600 500 400 300 200 Defined 100 Done 0 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

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: 900 Defined 800 Done 700 600 500 400 300 200 100 0 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

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:

Page 68


1000

1000 Pending

Done

900

900

800

800

700

700

600

600

500

500

400

400

300

300

200

200

100

100

0

0 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

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: 1000

1000 Pending

Done

900

900

800

800

700

700

600

600

500

500

400

400

300

300

200

200

100

100

0

0 1

Page 69

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18


Alternatively, if we know that the Product Backlog will have more changes, we can also take it into consideration: 1000

1000 Pending

Done

900

900

800

800

700

700

600

600

500

500

400

400

300

300

200

200

100

100

0

0 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

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: 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 Dick Harry 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.

Page 70


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.

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

t.2.2

purchasing process, through

t.2.4

which other functionalities of the website will be more

t.3.2

meaningful.

t.3.1

Sprint Burn-Down Chart 80 70 60 50 40 30 20

t.5.5

10 0 1 2 3 4 5 6 7 8 9 1011121314

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

Page 71


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 72


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 higherlevel 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?”

Scrum of Scrums Coordination Among the teams

Daily Scrums Coordination inside the teams

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.

Page 73


Scrum of Scrums of Scrums Coordination for the whole project

Scrum of Scrums Coordination Among the teams

Daily Scrums Coordination inside the teams

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.

Page 74


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 te am 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 leve l 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 75


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 76


3 Kanban and ScrumBan

Page 77


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

Designing

Programming

Testing

Documenting

Done

-

(2)

(3)

(4)

(3)

-

. .

.

Done

N

T

.

Done

.

. . .

.

Done

.

.

Done

.

E

M

Q D

U

Page 78


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 f or 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: To Do

Designing

Programming

Testing

Documenting

Done

-

(2)

(3)

(4)

(3)

-

. .

.

Done

N

T

T

.

Done

.

. . .

.

Done

.

.

Done E

.

M

Q D

1

U N

These are the exact steps: 1. G is done; therefore it goes to the sub column “done” of the documentation.

Page 79


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

Designing

Programming

Testing

Documenting

Done

-

(2)

(3)

(4)

(3)

-

. .

.

Done

.

Done

.

. . . T

.

Done

.

.

Done

.

E

M

Q D

U

N

Page 80


Some items get completed in each column after a while and are moved to the “Done” section in the column: To Do

Designing

Programming

Testing

Documenting

Done

(2)

(3)

(4)

(3)

-

-

. .

.

Done

.

Done

.

. . .

T

.

Done

.

.

Done E

.

Q M

N

D

U

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 -

Designing

Programming

Testing

Documenting

Done

(2)

(3)

(4)

(3)

-

. .

.

Done

.

Done

.

. . .

.

Done

.

.

Done

.

E

Q M

T N D U

Page 81


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. To Do -

Designing

Programming

Testing

Documenting

Done

(2)

(3)

(4)

(3)

-

Done

.

.

Done

.

. . .

. . ..

Done

.

Done

.

E

Q M

T N D U

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.

Page 82


To Do

Designing

Programming

Testing

Documenting

Done

-

(2)

(3)

(4)

(3)

-

Done

Done

Q

. . .. . . M . .

Done

Done E

T N U

.

.

D

.

.

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. To Do

Designing

Programming

Testing

Documenting

Done

-

(2)

(3)

(4)

(3)

-

. .

.

Done

.. .. .

Done

.

Q M

. .

Done

. 1

Done E

2

T D

N U

Q

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

Page 83


specialist areas in certain situations and help their peers seems unacceptable and unproductive to some people. This is because they belie ve 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 test er 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 84


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.



Page 85

Definition of Done: exactly the same as the Scrum DoD.




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 86

263185194 EXIN Agile Scrum Training Manual (1)

Recommend Documents