EXIN Agile Scrum Training Manual

Click here to load reader

  • date post

    20-Dec-2015
  • Category

    Documents

  • view

    573
  • download

    57

Embed Size (px)

description

EXIN Agile Scrum Training Manual 2015

Transcript of EXIN Agile Scrum Training Manual

  • EXIN Agile Scrum Foundation Workbook

    Page 0

    EXIN Agile Scrum

    By Nader K. Rad, Frank Turley

    Foundation Workbook

  • EXIN Agile Scrum Foundation Workbook

    Page 1

    EXIN Agile Scrum Foundation Workbook By Nader K. Rad, Frank Turley

    2014, Nader K. Rad and Frank Turley

    All rights reserved. Except for brief passages and quotes for

    reviewing or commenting purposes, no part of this publication

    may be reproduced or transmitted in any form or by any

    means without prior consent of the authors.

  • EXIN Agile Scrum Foundation Workbook

    Page 2

    Table of Contents

    About the Authors ..................................................................................................................... 4 EXIN Agile Scrum Foundation Certification ............................................................................... 5 Agility Concept ........................................................................................................................... 7

    Project Delivery Method and Lifecycle .................................................................................. 7 Agile Manifesto .................................................................................................................... 10 Agile Principles ..................................................................................................................... 12 When Can We Use Agile? .................................................................................................... 14 Managing the Scope ............................................................................................................ 16

    Type of Scope items ......................................................................................................... 16 Adaptation of the Scope .................................................................................................. 17 Functional vs. Non-Functional Features .......................................................................... 18 Bugs .................................................................................................................................. 19 Spikes ............................................................................................................................... 19 MoSCoW Prioritization..................................................................................................... 20 Keeping the Scope Dynamic ............................................................................................. 21 Product Scope in Agile Environments .............................................................................. 22

    The Timebox Concept .......................................................................................................... 23 Planning Onion ..................................................................................................................... 24 Agile Practices ...................................................................................................................... 25

    Pair Programming ............................................................................................................ 25 Bus Factor .................................................................................................................... 25

    Test-Driven Development ................................................................................................ 26 Continuous Integration .................................................................................................... 26 Continuous Refactoring ................................................................................................... 27 Collective Code Ownership .............................................................................................. 27 Sustainable Pace .............................................................................................................. 28

    Scrum Framework .................................................................................................................... 30 Quick Overview of the Scrum Framework ........................................................................... 30 Scrum Roles .......................................................................................................................... 32

    Scrum Team ..................................................................................................................... 32 Role 1: The Product Owner .............................................................................................. 34 Role 2: The Scrum Master ................................................................................................ 36 Role 3: The Development Team ....................................................................................... 37 Other Roles ...................................................................................................................... 38 Who Is the Project Manager? .......................................................................................... 38 Pigs and Chickens ............................................................................................................. 38

    Scrum Events ........................................................................................................................ 39 Introduction to Scrum Events .......................................................................................... 39

    Timeboxing ................................................................................................................... 39 Suitable Workspace ..................................................................................................... 40 Osmotic communication .............................................................................................. 40 Managing Distributed Teams ....................................................................................... 40

    Event 1: The Sprint ........................................................................................................... 40 Setting the Duration of the Sprints .............................................................................. 42 Overtime Work, Buffers, etc. ....................................................................................... 42 Canceling Sprints .......................................................................................................... 42 Sprint 0 ......................................................................................................................... 43

  • EXIN Agile Scrum Foundation Workbook

    Page 3

    Event 2: Sprint Planning ................................................................................................... 43 Event 3: Daily Scrum ........................................................................................................ 46 Event 4: Sprint Review ..................................................................................................... 47 Event 5: Sprint Retrospective .......................................................................................... 48 Activity: Product Backlog Refinement ............................................................................. 49 Slack ................................................................................................................................. 49

    Scrum Artifacts ..................................................................................................................... 49 Artifact 1: Product Backlog .............................................................................................. 50

    Product Backlog Items ................................................................................................. 51 User Stories .............................................................................................................. 51 Epic User Stories ...................................................................................................... 52 Themes ..................................................................................................................... 52

    Estimating .................................................................................................................... 52 Story Points .............................................................................................................. 52 Planning Poker ......................................................................................................... 53 Triangulation ............................................................................................................ 54 Triangulation Board ................................................................................................. 55 Affinity estimation ................................................................................................... 55 Ideal hours / Ideal days ............................................................................................ 56 Re-estimating ........................................................................................................... 56

    Ordering the Product Backlog Items ............................................................................ 57 Release Planning .......................................................................................................... 58

    Artifact 2: Sprint Backlog ................................................................................................. 59 Velocity ........................................................................................................................ 60

    Artifact 3: Increment ........................................................................................................ 61 Artifact 4: Definition of Done ....................................................................................... 61

    Agile Documentation ................................................................................................... 62 Agile Testing ................................................................................................................. 63

    Artifact 5: Monitoring Progress toward a Goal ................................................................ 63 Information Radiators .................................................................................................. 63

    Burn-Down Charts .................................................................................................... 64 Burn-Down Bars ....................................................................................................... 66 Burn-Up Charts ........................................................................................................ 67 Cumulative Flow Diagrams ...................................................................................... 68 Niko-niko calendar ................................................................................................... 70

    Artifact 6: Monitoring Sprint Progress ............................................................................. 71 Scaled Scrum ........................................................................................................................ 71

    Roles ................................................................................................................................. 72 Product Ownership .......................................................................................................... 72 Scrum of Scrums .............................................................................................................. 73 Synchronization ................................................................................................................ 74 Splitting Teams ................................................................................................................. 74

    Contract Types and Scrum ................................................................................................... 75 Scrum Prerequisites ............................................................................................................. 75

    Kanban ..................................................................................................................................... 78 ScrumBan ................................................................................................................................. 84 The Journey Starts ................................................................................................................... 87

  • EXIN Agile Scrum Foundation Workbook

    Page 4

    About the Authors

    Nader K. Rad is a project management consultant, author, and trainer at Management Plaza. His career started in 1997, and he has been involved in many projects in different industries. He has designed a number of project management courses, prepared a number of e-learning materials and written more than 40 books. He has also written many practical articles on project management concepts and standards, planning software, scheduling, etc.

    He is certified in PMP, PRINCE2 Practitioner, MoP Practitioner, MSP Foundation, MoV Foundation, M_o_R Foundation, P3O Foundation, AgilePM Practitioner, CSM, PSM I, PSPO I, EXIN Agile Scrum Foundation, and ITIL Foundation.

    He is also a certified PRINCE2, MoP and Agile Scrum Trainer.

    More about the author: http://nader.pm

    Authors website: http://www.mgmtplaza.com

    Authors LinkedIn Profile: be.linkedin.com/in/naderkrad

    Frank Turley has been a project manager for more than 15 years. He is a PRINCE2 Practitioner and Scrum Master and also a PRINCE2 and Project Management trainer and coach. He has written a number of PRINCE2 and Project Management related books and is best known in the PRINCE2 world for his work in creating the most popular PRINCE2 Self Study training materials which include:

    The PRINCE2 Foundation Training Manual and video course

    The PRINCE2 Practitioner Training Manual

    The PRINCE2 Sample Project

    More about the author: http://mgmtplaza.com/frank-turley

    Authors website: http://www.mgmtplaza.com

    Authors LinkedIn Profile: http://linkedin.com/in/frankturley

  • EXIN Agile Scrum Foundation Workbook

    Page 5

    EXIN Agile Scrum Foundation Certification

    EXIN Agile Scrum Foundation is a professional certification focused on the Agility concept

    and the Scrum framework which is useful for those involved in Agile environments or those

    planning to migrate to one and wanting to prove their knowledge. The certification program

    is defined and provided by EXIN, a world-leading provider of independent information

    management certification and accreditation.

    General information about the exam:

    Prerequisites: none

    Type of questions: multiple choice

    Number of questions: 40

    Pass mark: 65%

    Open book: no

    Since there are no prerequisites for the exam and based on the fact that you can register

    and take the exam online, it is really accessible for everyone, especially those who prefer to

    self-study.

    This book covers almost everything you need to know for the exam. You would easily pass

    the exam by reading this book entirely and carefully. However, the Agility concept is wide

    and you can always come across a question on a topic that is not covered in this training

    manual.

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

    You can find out more about the exam here:

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

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

    ready.

  • EXIN Agile Scrum Foundation Workbook

    Page 6

    1 Agility Concept

  • EXIN Agile Scrum Foundation Workbook

    Page 7

    Agility Concept

    The word agile is an adjective, meaning: to move quickly and easily, or to think quickly and

    in an intelligent way (Oxford Advanced Learners dictionary). However, Agile (with a

    capital A) is used to refer to a group of frameworks used for the development and

    management of initiatives1. The main goal of Agile frameworks is to make the development

    quicker and smoother, and to create an output that is more satisfying for the customer.

    Almost everyone in the IT business has heard of Agile and is willing to try it; whether or not

    they and their customers are ready for such a change. There are even customers out there

    that expect you to be Agile, while they do not accept some of its consequences (e.g. lack of

    upfront documentation).

    So, lets 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, lets take a look at the different ways we can design the development lifecycle based on

    the standard development processes.

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

    next figure.

    1 Initiative is the term used to refer to both projects and programs. A program is an initiative which is

    focused on creating a result instead of a product. Programs are done with multiple related projects.

  • EXIN Agile Scrum Foundation Workbook

    Page 8

    In this lifecycle, we start with the first process and spend enough time on it until it is

    completed. Then we close the process and move to the next one. Each process creates an

    output: a document, some code, or a new state in the code.

    The first step (Analyze) is to specify the requirements and define the scope of the project. It

    is very important to have a well-defined scope to avoid further problems in traditional

    environments. The output is a document that might be called Requirements Specification

    or something similar.

    The second step (Design) is to design the architecture of the solution, resulting in a

    document that might be called Solution Architecture.

    The third step (Construct) is to build the software in its entirety. Then, in the fourth step, the

    code is integrated and finally tested and debugged in the last step.

    This is the traditional way of developing IT solutions and it is still commonly used in many

    organizations today. It is often referred to as the Waterfall model. The main characteristic of

    this lifecycle is that everything is defined before the development starts and there is a clear

    separation between the processes. There might be some overlap between the processes

    sometimes, but it would still be a Waterfall lifecycle.

    This characteristic of defining everything upfront and trying to stick to it is called predictive,

    so the model that we have just described is a predictive lifecycle. The Waterfall model is a

    common name for the predictive lifecycles in the IT development world.

    In a predictive lifecycle, the project is run step by step. Each step is dedicated to a certain

    concept of the project and everything is designed and planned upfront. This lifecycle is great

    for many projects, such as building a house, hospital, or airport. However, when it comes to

    IT projects, it is very hard to use such a system because the customer usually does not know

    exactly what they want, and therefore, they keep changing the requirements throughout

    the project. Think of a project to build a hospital: it may face lots of changes, but is it

    possible that you would end up with a theme park instead of a hospital? Of course not.

    However, it is quite possible for IT projects to start creating something like a hospital and

    end up with something like a theme park!

    Analyze Design Construct Integrate Test

    Product Scope prediction Architecture

    prediction

    Detailed

    project plan

    High-level

    project plan

  • EXIN Agile Scrum Foundation Workbook

    Page 9

    The problem is that the customer does not know what they want, until they see the working

    software, which is provided too late in predictive lifecycles (at the end of the project). We

    can use the following lifecycle to avoid this problem:

    We use a number of iterations in this lifecycle, which are called Sprints in Scrum. We run all

    the development processes on a part of the product in each iteration. The main reason for

    using iterative lifecycles is to have interim solutions at the end of each iteration, show them

    to the customer, receive their feedback, apply this feedback to the next iterations and thus

    reduce the amount of rework in later iterations.

    So, we have interim solutions (Increments) along the way and we can receive useful

    feedback after each iteration. We want to receive feedback as soon as possible so that we

    apply them in the next iterations of the project. A consequence is that the number and

    content of the building parts are dynamic. So, instead of creating a full requirements

    specification before designing and building everything, we start incrementing and iterating

    with a limited number of building parts and let the other parts of the scope form as the

    project goes on. This is called an adaptive lifecycle; a lifecycle that develops the final

    solution in an iteratively and incremental way, by adaptation.

    What we call Agile, is technically equivalent to using adaptive lifecycles. The Waterfall or

    traditional methods use a predictive lifecycle as mentioned earlier in this chapter.

    Note that an adaptive lifecycle is not just the process of dividing the development of the

    features into multiple stages; it focuses on limiting the plan to a few iterations in the near

    future, and using the output of each iteration to plan a little further toward the future.

    Another important point concerning adaptive lifecycles is that we do not run a mini-

    waterfall inside each iteration. A mini-waterfall runs all the development processes for all

    iteration items in the same time: specifies the iteration, then designs it, then builds it, etc.

    We use mini-agile inside iterations, which focuses on single features at a time, and runs all

    the development processes for them separately.

    Analyze

    Design

    Construct

    Integrate

    Test

    Analyze

    Design

    Construct

    Integrate

    Test

    Analyze

    Design

    Construct

    Integrate

    Test

    Analyze

    Design

    Construct

    Integrate

    Test

    Analyze

    Design

    Construct

    Integrate

    Test

    Analyze

    Design

    Construct

    Integrate

    Test

    Increment (product)

    Increment (product)

    Increment (product)

    Increment (product)

    Increment (product)

    Increment (product)

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

  • EXIN Agile Scrum Foundation Workbook

    Page 10

    There are many frameworks using this adaptive lifecycle; all known as Agile frameworks.

    Scrum is the best-known Agile framework, though there are other Agile frameworks such as

    XP, DSDM Atern, and Crystal. The second half of this book is mostly focused on Scrum, while

    the first part on the Agility concept is applicable to all Agile frameworks.

    Agile Manifesto

    So far, you know that an Agile framework is one that uses an adaptive development lifecycle

    instead of a predictive one. Agility was around back in the 50s, where it was considered a

    strange and sometimes anarchistic viewpoint; in a time when the traditional method did not

    even have a name such as Waterfall, because it was the de-facto way of working.

    The term Agile has become more and more established and was formalized by a group

    that prepared and signed a statement of values for Agile projects back in 2001, known as the

    Agile Manifesto:

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

    Individuals and interactions Over processes and tools

    Working software Over comprehensive documentation

    Customer collaboration Over contract negotiation

    Responding to change Over following a plan

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

    Kent Beck Mike Beedle

    Ward Cunningham Martin Fowler

    Andrew Hunt Ron Jeffries

    Robert C. Martin Steve Mellor

    Dave Thomas

    Increment (product)

    Increment (product)

    Increment (product)

    Increment (product)

    Increment (product)

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

    Increment (product)

    Feature 5 Feature 4 Feature 3 Feature 2 Feature 1

    Feature 5 Feature 4 Feature 3 Feature 2 Feature 1

    Mini-Waterfall (wrong)

    Mini-Agile (right)

    Each development process is run once to

    cover all features.

    Each development process is run separately

    for each features.

  • EXIN Agile Scrum Foundation Workbook

    Page 11

    Arie van Bennekum Alistair Cockburn

    James Grenning Jim Highsmith

    Jon Kern Brian Marick

    Ken Schwaber Jeff Sutherland

    2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice.

    This short manifesto explains the whole Agile idea in the simplest way. Take some time and

    see how you can match it with the idea of adaptive lifecycles.

    Value 1: Individuals and interactions over processes and tools

    Most management systems are focused on the processes and tools. We have

    been trying to improve without paying enough attention to the human part of

    the projects. In extreme cases, some managers consider team members as the

    simple pieces of a complex machine, which can be easily replaced, without

    interrupting the work. However, we have realized that we cannot have such a

    perfect machine in projects, because of all the uncertainties involved and the

    creativity required. Therefore, focusing on the processes and tools is not enough.

    The best way to improve the performance is to focus on the human aspects.

    Value 2: Working software over comprehensive documentation

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

    order to communicate with the customer and to create a foundation for the

    solution that is supposed to satisfy the customer. However, the fact is that the

    customer does not know what they want, until they see the working software,

    and no documentation can replace the working software for this purpose.

    It does not mean that we do not have any documentation in Agile projects, as

    some people falsely believe. For example, we still need operation manuals, which

    can be documents, even though we might prefer to have them as videos instead.

    We also have lots of tracking information in our configuration management

    system to help us support the development process. However, documents such

    as requirements specification and solution architecture are not used in an

    Agile environment.

    Value 3: Customer collaboration over contract negotiation

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

    adaptation is the customer collaboration. We are not dependent on any upfront

    design, and we are open to any changes requested from the customer at any

    time during the project. Late changes do not create lots of rework for us,

    because we do not have an upfront design to revise for each change.

    Value 4: Responding to change over following a plan

  • EXIN Agile Scrum Foundation Workbook

    Page 12

    We do not plan the whole project upfront, because we know that our customer

    does not know what they want. Instead of following a forced plan, we use an

    adaptive lifecycle, which is based on responding to change.

    Agile Principles

    There are twelve principles accompanying the Agile Manifesto, which describe the Agility

    concept even further:

    Principle 1: Our highest priority is to satisfy the customer through early and continuous

    delivery of valuable software.

    The goal is to have a satisfied customer, because they will return and they will

    also recommend us to other potential customers. But how? By delivering the

    solution that they really want and we know that it is not quite possible

    without being adaptive and delivering frequent, early, and continuous working

    software. Such flexibility is still possible in predictive lifecycles, but it is too

    expensive.

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

    harness change for the customer's competitive advantage.

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

    big upfront design to be fixed each time we want to change something.

    Besides that, we are happy to receive change requests, because each change

    is a step closer to what the customer really wants.

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

    months, with a preference to the shorter timescale.

    The customer will have a better understanding of what they want when they

    see the working software. We will receive feedback and use it for adaptation.

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

    not allowed to have iterations longer than one month, while some other

    frameworks accept longer iterations. We always prefer shorter iterations, as

    long as it is enough for creating a meaningful increment (working software).

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

    project.

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

    requirements at the beginning of a predictive environment, and again at the

    end, to approve the final solution. However, we need them to collaborate

  • EXIN Agile Scrum Foundation Workbook

    Page 13

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

    input is the source of the adaptation.

    Principle 5: Build projects around motivated individuals. Give them the environment and

    support they need, and trust them to get the job done.

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

    that manages itself and finds its way instead of receiving orders. This is a big

    responsibility for developers and not all developers are capable of working in

    this way. When we have suitable team members, we should trust them,

    motivate them and empower them to enable Agility.

    Principle 6: The most efficient and effective method of conveying information to and

    within a development team is face-to-face conversation.

    Team members in a traditional environment are focused on their specialist

    activities and might even be located in different places (usually in their

    organizational departments). We cannot even call them a team sometimes;

    they are just a number of individuals working on the same project. In contrast,

    in an Agile environment, we need a real team, and the members should ideally

    be co-located to enable continuous communication. After all, nothing can

    replace face-to-face conversations.

    It is a big advantage to have co-located teams, but it does not mean that we

    cannot have an Agile project with a distributed team. However, we should

    make the best use of the modern technology to minimize any lack of face-to-

    face communications, and expect a lower level of productivity at the end of

    the day.

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

    A 99% progressed item is still 0% done. How can we know the progress of a

    quantum of work, unless we go deep into technical matters? We do not do it,

    because we want to have a common language with the non-technical

    customer and keep them engaged. The solution to this is that we only have

    done or not done backlog2 items (backlog items must be non-technical).

    And it is OK; after all, the backlog items are small enough to show our progress

    by a simple done/not-done measurement.

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

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

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

  • EXIN Agile Scrum Foundation Workbook

    Page 14

    Working is not the goal. Realizing the product is the goal. Working overtime

    might seem to make things go faster, while, in reality, it reduces the output by

    decreasing the productivity and increasing defects. We prefer to have a

    sustainable pace.

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

    Avoiding upfront design does not mean that you do not need to be worried

    about the design. Agile projects do have design; it is just done inside each

    iteration for each backlog item.

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

    avoid problems; not forgetting that the goal is a good enough solution

    rather than a perfect one.

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

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

    management, for example, is handled simply by putting the essential

    information on an index card or sticky note. We do not need sophisticated

    tools to handle the project, and keeping it simple makes it easier to

    collaborate with the customer.

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

    teams.

    People usually work better when they are respected and have the authority to

    decide how they work. It is better if all team members are accountable for

    everything in the project. For example, designers do not work in isolation;

    they are in constant contact with the programmers, and can use this

    information to improve the designs and make them more practical.

    Principle 12: At regular intervals, the team reflects on how to become more effective, then

    tunes and adjusts its behavior accordingly.

    We believe that there is always room for improvement, no matter how well

    we are working. So, we spend some time investigating the previous iteration

    and find opportunities for small improvements. The goal is to improve every

    iteration at least a little bit.

    When Can We Use Agile?

    Unfortunately, Agile frameworks are not applicable in every project. They are known to be

    applicable in IT projects, which is correct, but they are also very helpful in organizational

    change initiatives and research projects.

  • EXIN Agile Scrum Foundation Workbook

    Page 15

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

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

    You remember from the previous section that having an incremental and iterative lifecycle

    is the common characteristic of Agile frameworks. The point is that it is not possible to

    develop everything like that. In the case of a house for example:

    1. We cannot produce (develop) the house iteratively, because the interim outputs are

    not working solutions (the customer cannot live in a house that is 50% done). What

    is the use of a building foundation without the other parts of the house? It is not

    possible to stop this project in the middle and start using the product. What is the

    use of a house without utilities? Besides that, all the development processes should

    be run separately inside the iterations in contrast to a complete upfront design,

    which means we should be able to design the foundation without knowing the

    design of the other parts of the structure it is going to support, which is not possible

    when building a house.

    2. We cannot develop it incrementally. For example, we cannot build a simple building

    foundation to enable work on the rest of the structure and then go back and

    improve it before the end of the project.

    Besides, why do we need an adaptive lifecycle when building a house? The customer for a

    house knows what they want and we do not need to show them interim solutions to receive

    feedback and constantly adapt the structure of the house.

    As an exercise, consider the writing of this book as a project. Can it be done iteratively and

    incrementally? If your answer is yes, do we need to create it adaptively?

    Another point worth mentioning here is the difference between projects and programs. A

    project is used to create an output, such as a piece of software. A program is used to create

    an outcome, such as a business capability, and is done through a number of related projects

    or other work. A project can be done predictively (traditional) or adaptively (Agile), but a

    program should always be adaptive. It is so, because a program is focused on an outcome

    rather than an output. We might be able to define the output upfront, but that is not

    possible for outcomes. We will have the outcome in mind and try to find the means with

    which to achieve it, and we should be open to changing the means as we progress.

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

    change, research, or similar project, you can use Agile frameworks; but you do not have to!

    There are lots of IT projects developed in traditional environments which are successful. The

    point is that if you can manage the change in your organization and you have the required

    potential, then you will have a much higher chance of success using Agile frameworks. The

    more uncertainty and change you have in a project, the more useful Agile frameworks will

    be.

  • EXIN Agile Scrum Foundation Workbook

    Page 16

    Managing the Scope

    Type of Scope items

    We usually define the scope in a simple or structured document or concept. This concept is

    usually called Product Backlog in Agile projects. A Product Backlog contains a number of

    items, and each item describes a building block of the final solution.

    We have three alternatives for defining Product Backlog items:

    1. Requirement specification this is the most traditional way of defining the scope. It

    is formed by technical terms that are clear to the development team, and are usually

    based on architectural relations between items.

    2. Use case this is based on the users 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 users needs and purpose.

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

    environments in order to receive feedback and adapt accordingly. After all, an adaptive

    lifecycle is not useful when we do not adapt! Therefore, we need to have a common

    language with the customer. A technical definition of a feature is not useful, so we prefer to

    use the non-technical way of defining the scope, which is use cases and user stories.

    Between these two, the user stories are preferred, because they are easier to understand.

    This is a sample user story: As an end user, I want to receive a list of my last transactions. Or,

    as a system administrator, I want to reset passwords. Everyone can understand them.

    A user story has three parts:

    As a , I want to , [so that ]

    1. As a , defines the role that is going to interact in the story; e.g. end user,

    administrator, or manager.

    2. I want to , defines the expectation of the role; e.g. search apartments, calculate

    the tax, grant permission to someone and sign-up on the website. Please note that it

    is only about actions and a sentence like as an administrator, I want to have my

    system to use SQL Server is not a user story! A user story is about doing something,

    rather than having something.

    3. so that , this optional part of the user story explains the reason behind this action

    and helps with the interpretation of the story. The reason for some stories is so

    obvious that you might not need to mention it.

    There are two essential rules about Product Backlog items:

  • EXIN Agile Scrum Foundation Workbook

    Page 17

    1. They should be non-technical. This is because the Product Backlog is our tool for

    communicating with the non-technical customer. Normally, a ten year old child

    should be able to understand each user story.

    2. They should be independent of each other, so that we can freely develop them in

    any order.

    We usually write down the Product Backlog items on index cards or sticky notes and put it

    on a physical board. This approach is preferred to using an application, unless you have

    distributed teams.

    Adaptation of the Scope

    The main difference with Agile scope management is that the full scope of a traditional

    project is defined and agreed upon upfront, before starting the design and build. In Agile

    projects, only part of the scope is defined at the outset (as much as is needed for the first

    few iterations) and we start designing and building the solution with the incomplete scope.

    While we are involved in the iteration, we continuously add new items to the Product

    Backlog and refine the existing ones based on the feedback we receive from the customer

    and the better understanding we all gain from the project. This is one of the main features

    of an adaptive lifecycle.

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

    develop. So,

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

    When we select a number of items from the Product Backlog to be developed in the

    next iteration, we take them out of the Product Backlog and put them in the

    iteration backlog (the Sprint Backlog in case of using Scrum);

    If an item is not done until the end of the iteration, we put it back to the Product

    Backlog; even if it is in progress.

    We usually assign a business value to each Product Backlog item and sort the list, so that

    items with more business value are placed higher. When we want to start a new iteration,

    we should pick items from the top of the Product Backlog, which means that we always

    develop items that have the highest business value. This is how we stay focused on the

    value and the business needs. Some Agile frameworks use methods such as MoSCoW

    prioritization instead of, or in combination with the quantified business value assignments

    to sort the backlog items. We will discuss MoSCoW prioritization later in this chapter.

    The Product Backlog is the main planning tool in most Agile frameworks. It contains the

    scope of the project, along with a level of time, resource, risk, and quality plan, in the

    simplest possible way.

  • EXIN Agile Scrum Foundation Workbook

    Page 18

    Functional vs. Non-Functional Features

    Each item in the Product Backlog explains a feature of the final solution, preferably in the

    form of a user story. One confusing problem is how to handle non-functional features, since

    they are technical by nature; user stories should be non-technical.

    Our previous examples of user stories are all functional features. Other features such as

    performance and security are examples of non-functional features.

    Non-functional features are those which should be applied to almost all functional features.

    Take performance for example: there are performance considerations for every functional

    feature. E.g. we do not expect a simple search to take two minutes. The solution is to add

    the non-functional features in the Definition of Done (DoD). The Definition of Done is a

    concept that contains all the things we should do or consider for every user story. The

    development processes, quality criteria, coding standards, and non-functional features are

    all parts of the Definition of Done.

    So, when we are developing any user story, we would check them against non-functional

    features mentioned in the Definition of Done, and we would not call them done, unless

    they adhere to all of them. This is what we usually call acceptance criteria in traditional

    environments and it is a part of quality planning.

    Some non-functional features might be applicable to only a few user stories and therefore,

    the Definition of Done would not be an appropriate place for them. In this case, we just add

    them to the back of the user story card. Yes, we might have some extra information about

    some user stories, such as special acceptance criteria, descriptions, specific non-functional

    features, etc. The front of the card belongs to the user story text (e.g. as an administrator, I

    want to reset passwords), the business value, and the estimate (story points). The back of

    the card belongs to everything else. For example, how do we inform the user of the changed

    password, what kinds of passwords do we accept, etc. And yes, it has to be short; we do not

    have that much space on the back of the card, and that is the whole point: we should keep it

    simple.

    So, do not forget this: every user story should be understandable and demonstrable to the

    non-technical customer. Avoid jargon, unless you are talking within the development team.

    ID: 0209

    As an end user, I want to reset my

    password, so that I can have access to

    my account again.

    Value: 2842

    Estimate: 5 SP

    Only strong passwords are acceptable.

    Password reset link should be sent to

    the registered email address.

    The user should answer the security

    question correctly before having the

    password reset.

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

  • EXIN Agile Scrum Foundation Workbook

    Page 19

    Bugs

    We create a working increment of the final solution at the end of each iteration, which

    should be potentially releasable. We keep them potentially releasable, so that it would be

    easier for the customer to try it and give us feedback. Some of the iterations might actually

    be released and used by the end users.

    It is very common to discover bugs after the demonstration of the potentially releasable

    increment or even during the use of the released product. In this case, there are different

    ways of handling them:

    It is preferable to create stories for the bugs and add them to the Product Backlog.

    We never add new items to the current iteration backlog, as we have to focus on the

    preselected ones. So, in this case, we need to wait until the next iteration to pick the

    bug from the Product Backlog and add it to the backlog of the next iteration to be

    fixed. Of course, bugs should be sorted like other user stories, and if they do not

    have a high value, we will have to wait for a later iteration before fixing them.

    If it is not acceptable to wait too long to fix the bugs (if the product is being used at

    that moment), we can keep them outside the Product Backlog and assign a

    predefined maximum effort of the team (5%, for example) to work on bugs instead

    of developing new items. We usually use a separate backlog and a Kanban board3 for

    the management of bugs in this case.

    It is inevitable that we will have some bugs; but how many? If you have lots of bugs, maybe

    you should improve your Definition of Done by adding more tests, improving the way you

    develop, etc. It is really important to be proactive.

    If a defect is not detected by the development team and is found by the end users after a

    release, it is called an escaped defect. The number of escaped defects is an important metric

    for measurement of the quality of work.

    Spikes

    Sometimes we are not sure how to develop something from a technical point of view. In this

    case, we use a spike to investigate it; a small development activity to learn the technical

    elements of the solution.

    There are two types of spikes:

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

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

    the required functionality.

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

  • EXIN Agile Scrum Foundation Workbook

    Page 20

    Spikes should be timeboxed (e.g. one or two days). Some teams have the spikes outside the

    normal iterations, while the more common way is to have them inside the development

    iterations.

    A spike sometimes refers to a task within multiple tasks required for a Product Backlog item.

    They are usually separate items. For example, we can have a spike for a normal user story in

    the current iteration, and the actual story in the next iteration.

    One of the main reasons for having spikes is to enable the team to give an estimate for the

    user story. It is not a complete exploration, but rather a quick and fast study, aiming at

    understanding and estimating.

    MoSCoW Prioritization

    The MoSCoW prioritization is a great technique for scope management and is an essential

    part of DSDM Atern. It is not very common yet to use it in Scrum frameworks, but it is a

    good idea to use it anyway.

    MoSCoW is a combination of the first letters of Must Have, Should Have, Could Have, and

    Would not Have This Time. In this technique, we assign one of those letters to each feature,

    based on the following definition:

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

    S (Should Have) is a very important feature for the final product, and we will face problems without it. However, we can find a workaround for that (using another

    solution in parallel, doing it manually, etc.) and still use the solution that lacks it. E.g.

    air conditioning in a car.

    C (Could Have) is a really helpful feature that we would really like to have in our solution, but frankly, it would not create a problem if we do not have it. E.g. A

    camera and display in the car, which can be used to help with reversing.

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

    When we assign these priorities realistically, we know that the minimum for an acceptable

    product is the solution containing all the M user stories. Our expected product is the one

    that contains all the M and S user stories. The ideal product is the one that contains all the

    M, S, and C user stories.

    MoSCoW prioritization is a great way of focusing on the business value: focusing on the real

    needs instead of the fancy features (Could Have items).

  • EXIN Agile Scrum Foundation Workbook

    Page 21

    Keeping the Scope Dynamic

    The scope of a project is fixed in traditional methods. We have a precisely defined set of

    requirements, and we try to get them done within a predefined budget, time, and quality.

    However, we are not always on track; in this case, we do not want to compromise the

    scope, and rather increase the time or budget or decrease the quality in order to deliver all

    the features. This is not favorable in Agile frameworks.

    We focus on the business needs in Agile frameworks, and compromising time and quality is

    not a good idea, because IT products have a very short operational lifetime. If we spend

    more time creating a solution just to have all the fancy features included, we are losing

    value.

    Some Agile frameworks do not allow changes in duration. The project is guaranteed to be

    finished on time. If something goes wrong, we will drop some of the unnecessary features

    (scope) instead. DSDM Atern is one of these frameworks.

    The following figure shows the classical triple constraints of projects and the different ways

    in which we can handle them:

    Quality?

    Cost

    Features

    Time Features

    CostTime

    Quality

    Variable

    Fixed

    Traditional Approach

    Atern Approach

    It is not necessary to follow the Atern principle of delivering on time in Scrum. However, we

    still develop higher-value user stories first. So the increase in the value of each iteration will

    be less and less as we progress though the project. We help the customer realize this, and

    we should therefore be ready to stop the project after each iteration. When the customer

    realizes that the current iteration has enough value, they may not want or need to spend

    extra time and money to receive the remaining small value features, so they may choose to

    close the project. This is another reason why we must keep the iterations potentially

    releasable.

  • EXIN Agile Scrum Foundation Workbook

    Page 22

    Product Scope in Agile Environments

    To understand the difference between the scope of the final product in an Agile

    environment and the difference it has with the traditional one, take a look at the next

    diagram which shows the result of a research done by the Standish Group in 2011,

    concerning the average use of software features.

    Always7%

    Often13%

    Sometimes16%

    Rarely19%

    Never45%

    The average use of software features (2011)

    This is the disaster we are trying to avoid in Agile environments: nearly half of the features

    in an average software are almost never used, which means we are spending twice as much

    time and money; a real waste. The main reason that Agile projects are faster is that we are

    incorporating a mechanism that eliminates such outputs.

    The reason for such waste in traditional environments is that we force the customer to

    specify everything upfront, and since change is usually followed by time and cost claims

    later in the project, the customer tries to think about every possible feature they might

    need. As it turns out, most of those upfront specified features are useless. We do not have

    this problem in Agile projects due to two reasons:

    1. We do not force the customer to specify everything upfront, so they do not need to

    be over-creative by defining every possible feature. Besides that, they know that we

    welcome changes at any time, so they can relax.

    2. We help the customer understand the business value of each feature and avoid

    those that do not really help the business, even if they have been defined in the

    Product Backlog.

  • EXIN Agile Scrum Foundation Workbook

    Page 23

    The Timebox Concept

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

    Each timebox has two major characteristics:

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

    timebox just because we need to finish something. We adapt ourselves to finish

    everything inside the timebox, and if it is not possible, we drop activities that have

    the least importance. So, each timebox has a maximum time, however, there are

    two types of timebox regarding the minimum time:

    a. Fixed duration: some of the timeboxes are completely fixed, and not only is

    the maximum time not extendable, but also the minimum is fixed. So, if we

    have done everything, and we still have some time left, we either pick new

    activities based on the rules defined in the framework, or just take some time

    off! This type of timebox is used to create regularity and is usually used for

    the major events.

    b. Max duration: some other timeboxes have a maximum duration, which is not

    extendable, but does not have a minimum duration. So if we are done with

    all the activities and have extra time, the timebox will be considered closed,

    and we will start another timebox. This type is used to maximize flexibility,

    along with regularity, and is usually used for smaller events or those that

    cannot have extra activities.

    2. Timeboxes have a predefined and usually frozen set of items to be completed. We

    define the items upfront and do not change them. We can refine the items (e.g. user

    stories), but we do not completely change them. We do not add new items or

    remove items. Of course, this is only the case until the next timebox, when all new

    changes are applied. This is so, because everything is changing in Agile environments

    all the time, and we need to focus to stay productive. So, while everything is

    changing, we keep short durations frozen and focus on development. The only

    exception is that if the timebox is of a fixed duration instead of a max duration, we

    can add extra activities once we are done with all the pre-defined ones.

    As you might have guessed, each iteration is timeboxed. They are fixed duration timeboxes

    in most frameworks. We also have lots of meetings either inside or outside the iterations,

    which are timeboxed as well; e.g. planning timebox. You can see a concrete example of

    Scrum timeboxing in the next chapters.

    Using timeboxes is a great strategy for increasing productivity, both in your personal life and

    in projects. Some of the advantages are:

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

    releasable solutions;

  • EXIN Agile Scrum Foundation Workbook

    Page 24

    2. It helps increase focus, especially where everything is changing and new things come

    up all the time;

    3. It helps us focus on the value and the business needs. Because the maximum

    duration is always fixed in timeboxes, we cannot extend the time to finish

    something, and instead, we have to understand the values and drop some of the

    activities that have less value.

    Planning Onion

    There are different levels of planning related to an Agile project, which can be shown in an

    onion shaped diagram such as the one below:

    The strategy and portfolio planning levels are outside the projects, handled by the broader

    management systems of the organization. Strategy planning defines the benefits for the

    organization (e.g. earning money), and the portfolio level picks and resources the best

    possible projects to optimize the benefits.

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

    1. Product planning usually done in the Product Backlog and probably some

    additional high-level plans such as the product vision, based on the framework in

    use.

    2. Release planning this level plans when increments should become available to the

    end users for actual operations. In some frameworks such as Scrum, we do not have

    a type of planning specific to releases, because we are always ready to release the

    latest increment.

    3. Iteration planning in the case of Scrum, this level of planning is done in the Sprint

    Planning meeting, and creates the Sprint Backlog. This is a list of items (user stories)

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

    iteration.

    Strategy

    Portfolio

    Product

    Release

    Iteration

    Day

  • EXIN Agile Scrum Foundation Workbook

    Page 25

    4. Day planning in Scrum, for example, this level is done by breaking down the Sprint

    Backlog items into tasks, and it is also discussed after the Daily Scrums.

    Agile Practices

    There are a number of common practices in Agile environments that really help improve the

    way your project is progressing. Some of the practices are not limited to Agile

    environments, and you can benefit from them in traditional environments too. Some

    essential practices are explained in the previous chapters or will be explained in the Scrum

    framework chapters. This section introduces some of the other common practices.

    Pair Programming

    Pair programming is having two developers working together at one workstation. One of

    them is called the driver, who writes code, and the other person is called navigator, who

    observes and gives comments. These two people switch their roles frequently (every hour,

    for example).

    These are the main benefits of pair programming:

    Working is more enjoyable for people, when they are working in pairs. Well, there

    are sometimes conflicts, but they are not caused by pair programming; they are

    existing problems that have shown themselves because of the pair programming

    practice, and otherwise, they would have shown themselves elsewhere;

    People learn more when they see each other working;

    It is a team-building activity and helps create a more collaborative environment,

    which is required for all Agile teams;

    The quality of the product is much higher when we are using this practice, which also

    results in fewer defects, rework, and cost.

    It might seem strange at the beginning to assign two people to do the work of one person

    and this might seem wasteful. However, the fact is that in practice, the output of a pair of

    programmers, including all the debugging, is more than twice the product that two separate

    programmers create. So, it is even economical to use this practice.

    Bus Factor

    You lose one of your project team members, for any reason (e.g. a bus hits him/her and),

    and you are not able to continue the project anymore, because no one else has the key

    information for the project. This is a project with a Bus Factor of 1, which is terrible.

    The minimum number of developers you have to lose before losing the ability to continue

    the project (even by adding new developers), is called your Bus Factor or Truck Factor.

    Higher numbers are certainly desired.

  • EXIN Agile Scrum Foundation Workbook

    Page 26

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

    Bus Factor and consequently, it decreases the negative risks. However, you can have more

    mechanisms in place to help with this aspect by Succession planning.

    Succession planning is about keeping the information inside the team, instead of certain

    individuals, and makes it possible to switch responsibilities, or even add or remove

    developers in extreme cases. Pair programming is a great way of succession planning and

    increasing the Bus Factor, because everything is well known to at least two people instead

    of one.

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

    configuration management systems), and practicing a real co-ownership of code are other

    ways of increasing the Bus Factor.

    The results of a successful succession plan are not limited to extreme cases of losing people.

    It is also very helpful for the natural flow of the project, because team members might get

    sick, go on vacation, or simply become distracted every once in a while. These issues can

    cause serious problems in a low Bus Factor environment.

    Test-Driven Development

    Test-driven development is the practice in which test scenarios are prepared before the

    program is written. So, the goal for the programmer is to write something that can pass the

    exact test.

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

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

    productively;

    Programmers will be encouraged to create the simplest possible program, just to

    pass the test. This is desirable in Agile environments, since we do not want to waste

    time creating something perfect, while all we need is a good enough solution to do

    the job. However, we usually need to have an eye on refactoring to make sure that

    the solution is still good enough.

    Continuous Integration

    The pieces of code are usually integrated at the end of the project or phase in a traditional

    environment, while we prefer to have continuous integration in Agile environments. All

    programmers are required to upload their latest versions of code into the repository every

    hour or so.

    This practice enables us to be sure that our previous work is done and does not need too

    much further adjustment. However, it is required to have a reliable configuration

  • EXIN Agile Scrum Foundation Workbook

    Page 27

    management system to enable this practice without getting into problems, especially when

    the output is being used in operations.

    Some key benefits of the continuous integration practice are:

    It is easier to have real increments at the end of the iterations; releasing the solution

    would be much easier than in traditional environments;

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

    Continuous integration is usually used in combination with automated testing

    environments.

    Continuous Refactoring

    Refactoring is the improvement of code without changing its external functions. Continuous

    refactoring is spending some of the development time on refactoring to facilitate the future

    development and maintainability.

    Key benefits of continuous refactoring are:

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

    We can build up lots of lessons learned to incorporate in the remaining parts of the

    project and in future projects.

    Care should be taken not to target perfect code instead of good-enough code. A minimum

    continuous refactoring is required in Agile environments, because we are not developing

    based on an upfront design.

    Continuous refactoring is the Agile strategy for repaying the technical debt. Technical debt is

    the eventual consequence of poor development, which should be repaid sometime, and the

    sooner, the better.

    Collective Code Ownership

    No one in the Agile team owns a piece of code; everyone is accountable for everything, and

    everyone is allowed to change any piece of code.

    The key benefits of collective code ownership are:

    Encouraging collaboration;

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

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

  • EXIN Agile Scrum Foundation Workbook

    Page 28

    Sustainable Pace

    Having a sustainable pace, as you might remember from the Agile principles, is required.

    Having constant overtime work might seem to increase the speed, but in practice, it actually

    slows down everything because of the low quality of the code and morale of the team.

    The key benefits of having a sustainable pace are:

    Developers are more focused on producing rather than working; they are focused on

    the project as a whole, rather than activities;

    We will have a happier environment;

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

    The use of relative units (story points) for measuring the effort of each Product Backlog item

    instead of time-based units helps us keep the pace sustainable.

  • EXIN Agile Scrum Foundation Workbook

    Page 29

    2 Scrum Framework

  • EXIN Agile Scrum Foundation Workbook

    Page 30

    Scrum Framework

    You now have an abstract understanding of Agility, and you might have wondered how it is

    possible to make it work. Well, Scrum is one of the answers to such a question; one of the

    best answers actually. Most of the Agile companies use Scrum nowadays:

    Scrum52%

    Scrum+XP

    14%

    Others

    34%

    Scrum does not belong to a certain organization, in the way that PRINCE2 or PMBOK Guide

    do, so there are different interpretations of it available in various resources. The most

    credited resource amongst all of them is scrum.org, defined in a very short guide called

    Scrum Guide. This guide is a very good reference, but it is not a self-study material. We have

    kept this part of the book compatible with Scrum Guide.

    Quick Overview of the Scrum Framework

    Each Scrum project is done in a number of Sprints. Sprint is the Scrum term for iteration.

    We use a Product Backlog to define the remaining scope of the product. We pick a number

    of items from the top of the Product Backlog to be done through the current Sprint. We run

    Sprints as many times as required, until:

    1. the project is finished, because:

    a. all the items in the Product Backlog are done;

    b. the customer has realized that the latest iteration is enough, and there is no

    justification to spend more time and money adding more features;

    2. the project is terminated for some reason (e.g. it is not justified any more).

  • EXIN Agile Scrum Foundation Workbook

    Page 31

    The next figure shows an overview of the framework:

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

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

    Product Backlog and creating the Sprint Backlog;

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

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

    feedback;

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

    There are three roles in Scrum:

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

    Backlog, which requires constant communication and collaboration with the

    customer;

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

    Product Backlog Product

    Backlog Product Backlog Product

    Backlog

    Increment #7 Increment #6

    Increment #5 Increment #4

    Sprint

    Retrospective

    Daily

    Scrum

    Sprint

    Review

    Sprint

    Planning

    Sprint #6

    Done, and

    potentially

    releasable

    Sprint Backlog Sprint Backlog Sprint Backlog Sprint Backlog

    Feedback Feedback Feedback Feedback

    To be applied

    to the Product

    Backlog

  • EXIN Agile Scrum Foundation Workbook

    Page 32

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

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

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

    experts who develop the solution.

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

    developer is anyone who contributes to the production of the final solution. The term

    developer can refer to analysts, solution designers, UI designers, programmers, testers,

    etc.

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

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

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

    development and management lifecycle of the framework;

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

    Scrum (e.g. performance monitoring).

    Scrum Roles

    Scrum Team

    There are three roles in a Scrum project; no less, and no more. We are not allowed to define

    any other roles, because it is harmful to the unity of the team, and it is not compatible with

    the philosophy of Scrum.

  • EXIN Agile Scrum Foundation Workbook

    Page 33

    A Scrum Team consists of the following three roles:

    The term Scrum Team refers to all the project team members: everyone internal to the

    project. Scrum Team members usually have only one of the three standard roles of Scrum:

    Product Owner, Scrum Master, or Development Team member. It is possible, however, for a

    single person to be assigned to more than one of the standard roles, but it is not

    recommended.

    The Scrum Team is a part of the performing organization (the company which executes the

    project either for itself or as a contractor for an external customer).

    Other persons can also be involved in the project, but they are not considered internal to

    the project and Scrum theory does not have much to say about them. They should have a

    certain set of behaviors though, to make it possible for a Scrum project to succeed.

    The customer (either internal or external) should understand and adopt the Scrum

    framework too, as the relationship between the customer and the Scrum Team and the way

    we deliver the project completely changes when we switch to the Scrum framework.

    The Scrum Team has two essential characteristics:

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

    or directed by others. In traditional methods, management efforts are separated and

    centralized; a subset of the project team is responsible for project management, and

    others are only responsible for specialist activities. However, management and

    specialist efforts are not separated in Scrum.

    Product Owner Scrum Master Development Team

    1 person Full-time or part-time

    Business-oriented

    1 person Full-time or part-time

    Scrum coach and facilitator

    3 to 9 people Full-time (recommended)

    Specialists

  • EXIN Agile Scrum Foundation Workbook

    Page 34

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

    get the job done without any help from outside the team.

    These two characteristics are designed to optimize the flexibility, creativity, and productivity

    needed for the Agile environment of Scrum.

    Role 1: The Product Owner

    Each project needs a business-oriented person, aimed at maximizing the business value of

    the product and the work of the Development Team. In Scrum, this person is called the

    Product Owner. Product Owners, like the two other roles, are from the performing

    organization, rather than from the client side. There might be one or more people from the

    client side assigned to manage the product, but they would not be called Product Owners.

    This role belongs to one person. There can be a committee to handle the responsibilities of

    this role, but in such a case, there should be one person representing this committee, and

    we call this one person the Product Owner.

    They do not need to have application area knowledge of the project; they are focused on

    the business aspects. In software development projects, for example, Product Owners do

    not need to be developers themselves; they just need to know a little about development,

    and a lot about how the business operates.

    The Product Owner is responsible for the Product Backlog. The Product Backlog is a

    prioritized list of items (usually user stories) that the client expects from the project; this is

    the main planning tool in Scrum. It is also the responsibility of the Product Owner to make

    sure that each item (user story) is easy to understand for the Scrum Team, and other

    stakeholders.

    Product Owner Scrum Master Development Team

    1 person Full-time or part-time

    Business-oriented

    1 person Full-time or part-time

    Scrum coach and facilitator

    3 to 9 people Full-time (recommended)

    Specialist

  • EXIN Agile Scrum Foundation Workbook

    Page 35

    Product Owners should communicate effectively with the customer (the inevitable success

    factor in every project management method), and use the information to keep the Product

    Backlog updated with all the changes. They also measure the performance of the project,

    forecast the completion date, and make this information transparent to all stakeholders.

    Product Owners understand the business, so they can rank each Product Backlog item based

    on its return on investment as well as any other factor they find suitable for the business

    point of view of the project. The items will be sorted based on their business value (or just

    value for short), so the higher they are on the list, the sooner they will be developed by

    the Development Team.

    The entire organization must respect the Product Owners 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 Owners decisions might be

    influenced by others, but s/he must have the final say.

    Product Owners might delegate some of their responsibilities (such as preparing the list of

    items for the Product Backlog) to the Development Team, but they stay accountable for

    them.

    Communications

    Communications

    Customer

    Performing Organization /

    Scrum Team

    Requirements

  • EXIN Agile Scrum Foundation Workbook

    Page 36

    Role 2: The Scrum Master

    Scrum Masters are those who fully understand Scrum, and help the Scrum Team by

    coaching them, and ensuring that all Scrum processes are implemented correctly. The

    Scrum Master is a management position, whereby the Scrum Master manages the Scrum

    process, rather than the Scrum Team. S/he is a servant-leader for the Scrum Team.

    Besides ensuring that the Development Team understands and uses Scrum correctly, the

    Scrum Master also tries to remove impediments to the Development Team, facilitates their

    events, and trains and coaches them.

    Scrum Masters help the Product Owners too, by helping or consulting them on finding

    techniques, communicating information, and facilitating related events.

    The responsibilities of Scrum Masters are not limited to the Scrum Team. They should also

    help those outside the Scrum Team understand the appropriate interactions with the Scrum

    Team in order to maximize the business value. The Scrum Master usually leads the

    organization in its effort to adopt Scrum.

    It is possible for a single person to be both a Scrum Master, and a member of the

    Development Team, although this is not recommended. Being a Scrum Master of a normal

    project might not occupy 100% of the time of a person; in this case, the best solution is to

    assign that same person as the Scrum Master in more than one project, rather than making

    them a member of the Development Team.

    Most of the internal and external communications about the Scrum process are done by the

    Scrum Master, while most of the internal and external communications about the content

    of the project are done by the Product Owner. Note that the Scrum Master is not involved in

    Product Owner Scrum Master Development Team

    1 person Full-time or part-time

    Business oriented

    1 person Full-time or part-time

    Scrum coach and facilitator

    3 to 9 people Full-time (recommended)

    Specialist

  • EXIN Agile Scrum Foundation Workbook

    Page 37

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

    of the increments).

    Role 3: The Development Team

    Members of the Development Team are application area experts who are responsible for

    delivering backlog items, and managing their own efforts.

    They should be cross-functional: being capable of doing the A to Z of each Product Backlog

    item. They should be self-organized: find their own way instead of receiving orders. They

    should be aligned with the goal of the project instead of working blindly. A task might be

    assigned to a single member during the Sprint, but the whole Development Team will stay

    accountable for that task; no individual owns any task.

    The Development Team delivers the final product of the project in step by step Increments.

    They always work in a product-based way.

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

    single project, to stay focused and agile. The composition of the Development Team should

    not change frequently. If there is a need to change team members, then this change should

    not happen during a Sprint. At any time, there will be a short-term decrease in productivity

    when the composition of the team changes.

    Scrum is mostly effective when there are 3 to 9 Development Team members. For large

    projects, we can use a scaled model with multiple Scrum Teams.

    Product Owner Scrum Master Development Team

    1 person Full-time or part-time

    Business-oriented

    1 person Full-time or part-time

    Scrum coach and facilitator

    3 to 9 people Full-time (recommended)

    Specialist

  • EXIN Agile Scrum Foundation Workbook

    Page 38

    Other Roles

    You might have the temptation to give Development Team members more specific titles,

    such as designer, tester, quality inspector, and team leader; but Scrum does not allow this!

    All members should have the same role, and the same title: Development Team member.

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

    should be united and completely aligned with the goal of the project. If you give them

    different titles or roles, they will focus on their own particular role in the project instead,

    and they might not pay enough attention to the final product. Each Development Team

    member is responsible for all the outputs created in the Development Team, even though

    each of them might be focused on a specific set of tasks.

    Who Is the Project Manager?

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

    manager?

    The answer is simple: there is no such role in Scrum; and none of the three roles of Scrum

    act as a traditional project manager.

    Some people consider the Scrum Master to be the equivalent to a traditional project

    manager; but this is not true, because the Scrum Masters responsibilities are very different

    than those of a traditional project manager. Scrum Masters are not responsible for planning,

    for example.

    Others might consider the Product Owner to be the equivalent to a traditional project

    manager which is also not correct. Even though they are responsible for parts of the

    planning and monitoring of the project, for example, planning and monitoring is also

    partially done by the Development Team. Besides that, managing the framework is also a

    project management responsibility, which is done by the Scrum Master.

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

    The project management responsibilities are distributed among the three roles of Scrum

    and there is no centralized project management in Scrum.

    Pigs and Chickens

    A pig and a chicken were hanging out, when the chicken suggests they open a restaurant.

    What should we serve? the pig asks enthusiastically. The chicken replies Ham and eggs.

    The pig does not accept, claiming that I would be committed, while you would be only

    involved.

    The whole Scrum Team are the pigs in this analogy, while the rest of the stakeholders,

    including the customer and senior management are just chickens.

  • EXIN Agile Scrum Foundation Workbook

    Page 39

    It is essential to differentiate the pigs and chickens in any project, to increase productivity.

    Chickens do not have a direct authority in the project execution.

    Scrum Events

    Introduction to Scrum Events

    There are five events in a Scrum Project:

    1. Sprint: Each Scrum project is a set of Sprints. A Sprint is a container for the four

    other events (as represented in the above diagram), development effort, and the

    maintenance of the Product Backlog.

    2. Sprint Planning: Sprint Planning is the first event inside a Sprint. The Scrum Team

    plans the items they are going to deliver in the Sprint and the way they will deliver

    them.

    3. Daily Scrum: The Development Team starts working on the objectives of the Sprint

    as soon as Sprint Planning is completed. During the Sprint, the Development Team

    holds a daily meeting (15 minutes) to coordinate the work for the next 24 hours. This

    meeting is called the Daily Scrum.

    4