Professional Scrum Developer - 1 Workbook

Student Workbook
Applying Professional Scrum

For SOFTWARE DEVELOPMENT
@ScrumDotOrg
vv7.5.5 © 1993 – 2022 Scrum.org All Rights Reserved
INTELLECTUAL PROPERTY
This training material is the intellectual property of Scrum.org and Accentient Inc. Accentient Inc.
develops and maintains this training in cooperation with Scrum.org.
www.accentient.com
Visual Studio ALM Experts
Accentient, Inc.
Boise, Idaho USA
info@accentient.com
No part of this manual may be reproduced or transmitted in any form or by any means, electronic
or mechanical, including photocopying and recording, for any purpose without the express written
permission of Scrum.org and Accentient Inc. Unauthorized duplication or usage of the material
violates existing copyright agreements and will be enforced by law.
IMAGES AND ARTWORK

Images and artwork in this book were obtained through Flickr and are licensed under a Creative
Commons 3.0 license. Visit http://creativecommons.org/licenses/by/3.0 for more information.
All trademarks referenced are the property of their respective owners.
DISCLAIMER
While Scrum.org and Accentient Inc take great care to ensure the accuracy and quality of these
materials, all material is provided without any warranty whatsoever, including, but not limited to,
the implied warranties of merchantability or fitness for a particular purpose.
This page must not be removed from the training material.

Copyright © 2009-2022 Accentient Inc.
Contents
Welcome to the Applying Professional Scrum for Software Development Class ..............................7
Course Introduction............................................................................................................................8
Activity: How do you want to work together .....................................................................................9
Activity: Form Your Collocated Scrum Team ....................................................................................10
Introductions ....................................................................................................................................11
Course Forecast ................................................................................................................................12
It’s Your Experience, Own It .............................................................................................................14
Prerequisites for Happiness..............................................................................................................15
Scrum.org Mission ............................................................................................................................16
Professional Scrum at Scrum.org......................................................................................................17
Purpose.............................................................................................................................................19
Audience...........................................................................................................................................19
What is your personal take-away from this module?.......................................................................20
The Scrum Framework ..................................................................................................................21
Activity: Define Scrum ......................................................................................................................22
Scrum Defined ..................................................................................................................................23
Complexity and Scrum......................................................................................................................24
Scrum Employs Empiricism...............................................................................................................26
Activity: What is Needed for Scrum?................................................................................................27
Each Role Has a Specific Accountability............................................................................................28
Activity: Scrum Values ......................................................................................................................29
Scrum in a Nutshell...........................................................................................................................30
Scrum Roles, Artifacts, and Events ...................................................................................................31
Complementary Practices.................................................................................................................43
Assessing progress............................................................................................................................44
Assessing progress during a Sprint ...................................................................................................44
Assessing progress beyond the Sprint ..............................................................................................44
Resources to learn more about this subject.....................................................................................47
Case Study ....................................................................................................................................48
Defining Quality ................................................................................................................................49
Activity: What Quality Attributes Do You Value? .............................................................................50
Case Study Kickoff ............................................................................................................................51
Done Means Releasable ...................................................................................................................53
Activity: What Is Your Definition of Done?.......................................................................................55
Updating the Definition of Done ......................................................................................................57
Activity: What Is Your Definition of a Bug?.......................................................................................58
Dealing With Bugs in Scrum..............................................................................................................59
Reporting a Bug ................................................................................................................................61
Product Backlog Refinement .........................................................................................................63
Refining the Product Backlog............................................................................................................64
The Evolution of a PBI.......................................................................................................................65
Copyright © 2022 Scrum.org Version v7.5.5 Page 3

Spikes................................................................................................................................................67
How We Estimate Best .....................................................................................................................68
Activity: What is the Size of My House? ...........................................................................................69
Estimation in Hours is Not Required.................................................................................................70
Estimation Technique: Wall Estimation............................................................................................71
Activity: Refine the Product Backlog ................................................................................................72
Estimation Technique: Planning Poker .............................................................................................73
Anchoring .........................................................................................................................................74
Activity: Refine the Product Backlog ................................................................................................75
Activity: When to use what ..............................................................................................................76
To Be More Accurate, Be Less Precise..............................................................................................77
Estimation Technique: #NoEstimates...............................................................................................78
Flow/Metrics Based Release Planning..............................................................................................80
Resources to learn more about this subject.....................................................................................83
Sprint 1 .........................................................................................................................................84
Activity: Sprint Planning ...................................................................................................................85
Activity: Development ......................................................................................................................86
Activity: Sprint Review......................................................................................................................87
Activity: Sprint Retrospective ...........................................................................................................88
DevOps .........................................................................................................................................89
Activity: Define DevOps ....................................................................................................................90
Activity: The Three Ways ..................................................................................................................91
DevOps and Scrum ...........................................................................................................................92
Activity: DevOps Practices ................................................................................................................94
The Three Ways are About Flow.......................................................................................................98
Activity: Flow ..................................................................................................................................100
Azure DevOps .................................................................................................................................101
On Premises and Cloud Solutions...................................................................................................101
Release Pipelines in Azure DevOps.................................................................................................102
What is your personal take-away from this module?.....................................................................103
Resources to learn more about this subject...................................................................................104
Quality Software .........................................................................................................................105
Activity: More than testing.............................................................................................................106
How to Improve Quality .................................................................................................................107
Activity: Quality Metrics .................................................................................................................109
Separating Testing From Development ..........................................................................................110
Test in Parallel With Coding............................................................................................................111
Anti-pattern: Using different Sprint types ......................................................................................113
Acceptance Test Driven Development ...........................................................................................114
Three Types of Testing....................................................................................................................115
Unit Tests are Development Tests..................................................................................................117
Integrated Testing Tools in Visual Studio .......................................................................................118
DEMO: Unit Testing in Visual Studio...............................................................................................119
Code coverage ................................................................................................................................121

DEMO: Analyzing Code Coverage in Visual Studio .........................................................................122
Good Unit Testing Practices ...........................................................................................................123
Acceptance Tests ............................................................................................................................125
Azure DevOps Test Plans ................................................................................................................126
Exploratory Testing.........................................................................................................................127
Demo: Test Planning and Exploratory Testing................................................................................128
Pair Programming...........................................................................................................................129
Mob Programming..........................................................................................................................130
Activity: Quality is a Mindset ..........................................................................................................131
Sprint 2 .......................................................................................................................................134
Activity: Sprint Planning .................................................................................................................135
Activity: Development ....................................................................................................................136
Activity: Sprint Review....................................................................................................................137
Activity: Sprint Retrospective .........................................................................................................138
Emergent Architecture ................................................................................................................139
An Anti-Pattern for Emergent Architecture....................................................................................140
Software Architecture vs. Software Design ....................................................................................141
Emergent Architecture ...................................................................................................................142
Activity: Emergent Architecture in action ......................................................................................144
The Right Amount of Up-Front Work .............................................................................................145
Software Architecture in a Scrum Context .....................................................................................146
Who – There is no Architect-Role in Scrum....................................................................................147
Activity: How to Decide ..................................................................................................................149
How – Deciding and Validating Software Architecture ..................................................................150
How – Architecture and Quality Goals - Deciding ..........................................................................152
How – Architecture and Quality Goals - Validating ........................................................................153
How – Visualizing Quality Goals .....................................................................................................154
Activity: How – Planning and Documentation................................................................................155
Activity: When – Architecture in Scrum Events ..............................................................................156
When – No Big Design Up Front .....................................................................................................157
Think in Slices Not Layers ...............................................................................................................159
Activity: How Would You Slice This?...............................................................................................161
Quality Code ...............................................................................................................................164
Developing vs. Coding ....................................................................................................................165
Yes, we do Scrum. And….................................................................................................................166
Quality Code == Quality Software ..................................................................................................167
SOLID ..............................................................................................................................................169
Activity: Questions About Code Quality .........................................................................................175
Clean Code......................................................................................................................................176
Code Quality Support in Visual Studio............................................................................................179
Code Analysis..................................................................................................................................180

Code Metrics ..................................................................................................................................181
Code Clone Analysis........................................................................................................................182
Demo: Code Quality Support in Visual Studio ................................................................................183
Test-Driven Development (TDD) ....................................................................................................184
DEMO: Practicing TDD in Visual Studio ..........................................................................................186
Build Automation............................................................................................................................189
Azure Pipelines ...............................................................................................................................190
Continuous Integration...................................................................................................................191
Continuous Feedback .....................................................................................................................192
Communication Tools.....................................................................................................................193
Refactoring .....................................................................................................................................194
Refactoring Tools............................................................................................................................197
Demo: Refactoring..........................................................................................................................198
Technical Debt ................................................................................................................................199
Sprint 3 .......................................................................................................................................203
Activity: Sprint Planning .................................................................................................................204
Activity: Development ....................................................................................................................205
Activity: Sprint Review....................................................................................................................206
Activity: Sprint Retrospective .........................................................................................................207
Scrum Challenges ........................................................................................................................208
Common Scrum Challenges............................................................................................................209
Common Developers Dysfunctions ................................................................................................230
Working As a Team.........................................................................................................................234
Becoming a High-Performance Scrum Team ..................................................................................248
Next Steps...................................................................................................................................261
Activity: Review Your Questions.....................................................................................................262
Activity: What’s Your Next Move?..................................................................................................264
PSD-I Assessment ...........................................................................................................................265
APS-SD Subject Areas .....................................................................................................................266
Inspect Your Knowledge – Feedback in 14 Days or Less! ...............................................................267
Scrum Guide 2020 ..........................................................................................................................268
Continue Your Learning Online.......................................................................................................269
What Happens Next?......................................................................................................................270
Keep Calm and Scrum On! ..............................................................................................................271

Welcome to the Applying Professional Scrum for Software
Development Class
Welcome to this class for Scrum Teams working in a software development environment.
What will you learn from this course?

The short answer: a repeatable process for turning a Product Backlog item into something that is
“Done” and releasable. You will learn how to do this using Scrum and contemporary agile software
development practices while working in a team using the tools you regularly use.
What will a team learn from this course?

Individuals will learn how to form themselves into a self-organizing, cross-functional Scrum Team to
develop an increment of software. They will also learn how to optimize their individual skills, self-
manage their own work during a Sprint, and resolve conflicts more effectively, in order to better
operate as a team. Teams will work on a common product in a shared development environment.

Course Introduction
In this course, a Scrum Team will learn how to self-organize and turn
Product Backlog items into a “Done” product Increment using Scrum
and contemporary Agile software development practices. The coverage
of these topics is fairly balanced as shown on the right.

Activity: How do you want to work together
For effective team work some aspects of collaboration are important. These include
 Team size
 Knowledge and competencies
 Co-located vs. distributed
 Sympathy and who wants to work with each other
 Diversity
Do you find more?

Activity: Form Your Collocated Scrum Team
In Scrum, Developers are cross-functional. This means that there is at least one member on the team
who has the necessary skill set to execute some type of work required to develop the software
product. Put a different way, it means that the Developers have all the skills needed to complete
their work. It’s important to learn about cross-functional teams and learning through experience is
best.
Scrum Teams also need a Scrum Master, so make sure that you select one within your team. Your
trainer will be your Product Owner during this course, so there is no need to worry about that role.
For those of you reading this in a black and white book, here are the colors mentioned on the slide …
Quality/Test Red
Architecture/Design Green
Coding Blue
ALM/Automation/DevOps Silver
Scrum Gold

Introductions
The instructor for this course wears several hats:
• Teacher – leading the training, presenting the material, answering your questions
• Product Owner – playing the case study’s Product Owner as needed
• Coach – helping with specific questions and concerns during activities and Sprints
Please write down the names and email addresses of your instructor and any assistants:

Course Forecast
This course is a mixture of lecture, demonstration, group discussion, simulation, and hands-on
software delivery. A large portion of the course will be spent working as a team on a case study
application delivering increments of new functionality in mini-Sprints. You will be using Scrum,
development practices, and relevant tools. As you work, your instructor will be assessing your
behavior and approaches to solving problems while working in a team on a common case study
project.
This course will have both technical and team-oriented operational components. One minute you
may be working individually on a task, and the next minute you may be defending your team’s
approach to prioritizing and ordering its work.
This course is three days in duration.

The Sprints
Timeboxing is a critical concept in Scrum as well as in this course. We expect each team and student
to understand and obey the timebox. The timebox duration will always be clearly displayed during
an activity. The instructor will enforce it.
Each of the Sprints will follow this schedule:
Component Description Timebox

Product Owner presents a refined Product Backlog and
Sprint Planning Developers forecast and plan the functionality that they can 15
deliver
The Developers self-organize to complete their work, develop
Development 75
their PBIs, and deliver a “Done” Increment of functionality
Each team presents their increment of functionality to the
Sprint Review 15
entire room for feedback
A group retrospective meeting will be held to inspect and
Sprint Retrospective 15
adapt the process
Each Scrum Team is expected to self-organize and manage their own work during each Sprint.
Pairing is highly encouraged. Your instructor will be available if there are questions or impediments,
but will be hands-off by default. You should be prepared to communicate and work with your fellow
team members in order to achieve your Sprint Goal. If you have development-related questions or
get stuck, your partner or team should be your first level of support.

It’s Your Experience, Own It
You are responsible for the success of your team. We recommend that you turn your cell phones off
and avoid browsing the Internet or checking your email. While they may be relevant, side
conversations should be avoided during lecture or while other teams are presenting or asking
questions. You will have time publicly to be heard by the instructor, or privately to be helped. Please
ask questions always, but allow the trainer to defer longer or more complex questions for breaks.
Record the relevant start time, end time, break times, lunch time, and other logistical details below:

Prerequisites for Happiness
You should attend the entire course, from beginning to end. There are no days or modules that are
“okay to skip”. You need to see the course in its entirety and participate with your team in all of the
activities. This course is designed to be taken as a whole. Students who miss modules will miss key
parts of the message. You should also be able to inspect and adapt at all times. This includes your
ability to improve on trouble areas, reflect on your ability to usefully consume constructive criticism,
and process and utilize information under pressure.
Remember the movie "The Karate Kid" (http://imdb.to/iWaz)? In the

movie, the ‘kid did not understand the value of "wax on, wax off" until he
saw it applied in a different context. The simplicity of the physical motions
obscured the value of developing the muscle memory needed for actual
combat.
The same goes for this course. The planning, execution, review, and
retrospective cycle are your “wax on, wax off” movements. Later, when your
actual team gets into software “combat”, these memorized motions will
serve you well.

Scrum.org Mission
Scrum.org is the home of Scrum, and is leading the evolution and maturity of Scrum to help people
and teams solve complex problems.
Scrum.org strives to provide all of the tools and resources needed by Scrum practitioners to deliver
value using Scrum. Scrum.org provides Scrum assessments to allow people to evaluate themselves
and improve, host community forums and webcasts to foster discussion and knowledge transfer,
and define industry-leading Scrum training for practitioners at all levels.
Scrum.org was founded in 2009 by Ken Schwaber, the co-creator of Scrum, out of extreme
dissatisfaction with the state of the art. For more information about the origins of Scrum.org visit
https://www.scrum.org/about.
Mission, Vision, and Goals

The mission for Scrum.org is “Helping people and teams solve complex problems” and this drives
everything that we do.
With everything that we do as an organization, Ken Schwaber, our founder, chairman and the co-
creator of Scrum asks: “How does this fit into our mission of helping people and teams solve
complex problems?” and if it doesn’t, we often revisit the intent of doing it. So, as we move through
this class, this mission will be at the heart of the materials and a major part of the goals we have
coming out of the class.

Professional Scrum at Scrum.org
Scrum.org Trainings
Applying Professional Scrum

These courses are targeted at Scrum Teams who want to learn how to use Scrum professionally and
successfully. Different courses exist for different domains, like the Applying Professional Scrum for
Software Development with its focus on teams working in a software centric environment.
Professional Scrum Master

The Professional Scrum Master courses target the work of a Scrum Master. Tools are provided to
enable students to relate to behavioral shifts, work with people and teams, coach and facilitate
techniques, and address the organization.
Professional Scrum Product Owner

The Professional Scrum Product Owner courses focus on how to maximize the value of products and
systems. Product Owners need to have a concrete understanding of everything that drives value
from their products where students learn through instruction and team-based exercises.
Other Professional Scrum Courses

Further Professional Scrum courses exist to target specific questions around Agile, Scrum, and their
implementation. Those special topics cover Scrum with Kanban, Scrum with UX, Scaling Scrum, Agile
Leadership, and possibly more.
Assessment and Certification

Scrum.org provides tools you can use to examine and enhance your knowledge of Scrum. The
primary aim of these assessments is to provide information about an individual's or a group's level of
knowledge and to thereby enable improvement.
Scrum.org assessments are grounded in the Scrum Body of Knowledge, the Scrum Guide, which is
written and maintained by Scrum's founders, Ken Schwaber and Jeff Sutherland. The Scrum Guide
can be found in 30 different languages at http://scrumguides.org.

Each of Scrum.org's assessments is developed by Scrum thought leaders with formal input from a
wide range of industry experts, and then enhanced with input from the larger Scrum community.
They are then monitored on an ongoing basis to ensure their continued integrity and relevance. You
can find the assessments at https://www.scrum.org/professional-scrum-
certifications.
Open Assessments
Before attempting an assessment, it is recommended that you take and pass an Open assessment,
such as the Scrum Open or others. These assessments are shorter than the proper ones, but will
familiarize you with the types of questions that will be asked. Think of the Open assessments as
another learning tool that you can use.

Purpose
The Applying Professional Scrum for Software Development course gives answers to the question on
how to create potentially releasable product Increments in every Sprint. To do this it shares ideas on
which tools and practices can help a Scrum Team to deliver working software.
Audience
This course assumes you are familiar with Scrum and have hands-on experience in a Software
Development environment. You should also have passed the Scrum Open and Scrum Developer
Open assessments.

What is your personal take-away from this module?
Record your take-away here:

The Scrum Framework
In this module we want to do a little recapitulation on the Scrum framework. We will talk about the
types of problems where Scrum is applicable with the highest degree of success, before we talk
about the principles of empirical process control.
We will also introduce the elements of the Scrum framework, its roles and accountabilities, events
and artifacts and how they work together.
At the end of the module we will look at how complementary practices can make Scrum more
successful in a given context. These practices are not mandatory and finding the right practices for
the right team, organization and context is difficult and a constant improvement cycle.

Activity: Define Scrum
Scrum is simply a framework, with rules, like chess. Scrum may be used poorly or well, as chess may
be played poorly or well, with or without a strategy. Your success will vary accordingly. Scrum is not
a silver bullet and will not solve your problems for you. Scrum is a tool you can use to find out what
you need to do to build quality software with a better return on investment.
This class teaches the rules of the game, and only a little strategy of how to play well. It’s up to you
to play the game well and succeed. For a great analogy of how Scrum is like the game of chess, read
Ken Schwaber’s blog post on the subject: http://bit.ly/1p1KsHR.
Write your team’s definition of Scrum here:

Scrum Defined
Scrum is an empirical management and control process with multiple points (events) at which to
inspect and adapt the software product being developed and how the team is developing it. Scrum
has been successfully used to manage complex projects since 1990 by delivering releasable
functionality in 2 to 4 weeks. Scrum is scalable to large product delivery.
Scrum is not an acronym. It is a term from the game of Rugby.
The Scrum Guide

The Scrum Guide provides THE definition by the co-creators of Scrum (Ken Schwaber and Jeff
Sutherland). The guide is the authoritative explanation of what Scrum is. It is updated frequently as
Scrum evolves to recognize contemporary software delivery. It contains just the rules, not the
strategy of how to play the game as per the chess analogy.
For more information, download the official Scrum guide: http://scrumguides.org.

Complexity and Scrum
Scrum is a lightweight framework that helps people, teams and organizations generate value
through adaptive solutions for complex problems. Software is a complex product. In other words,
more is unknown than is known about the fusion of domain and technology. What will happen is
largely unknown. Only what has happened may be used for forward-looking decision-making.
This chart has two axes: “Agreement on what we make” which represent the requirements and
“Certainty on how we do it” which represents the technology used. Values in both axes can range
from simple to chaos. In a simple environment, everything is known up front. Complicated
environments are where more is known than unknown. Complex environments are just the
opposite, and more is unknown than known. In chaotic environments, very little is known. This may
be the situation for some startups.
Comparing Scrum and Plan-Driven Models

In a process control model like waterfall, an effort is made to understand all work before execution.
The belief is that given a well-defined set of inputs, the same outputs are generated every time. One
can follow the pre-determined steps to get known results. Complex problems, such as software
delivery, lend themselves better to an empirical approach where frequent inspection and adaptation
are performed as work proceeds. Everyone involved understands that these processes are accepted
as imperfectly defined, and essentially just “experiments”, the outputs of which are often
unpredictable and unrepeatable. An empirical model is required when:
 We don’t know the exact outcomes at the time we begin

 We want to control the results and keep quality high
 Steps aren’t always repeatable

With Scrum, delivery is performed frequently. Visibility is fairly constant with regular inspections
during each Sprint. The ability to change still declines, but at a slower rate, allowing more change
later in the process. Business value is realized early because we are actually releasing software. Risk
goes down sooner by actually shipping software early and tackling high-risk features as early as
possible.
Scrum vs. Waterfall

In waterfall visibility is greatest at the beginning and the end of a project. The ability to change goes
down early in the project, locking in decisions like: features, architecture, and dependent
technologies. Business value goes up dramatically at the end because nothing is really valuable until
it’s released. Risk goes down all at the end, because risk isn’t truly mitigated until it’s released.

Scrum Employs Empiricism
Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that
knowledge comes from experience and making decisions based on what is known. Scrum employs
an iterative and incremental approach to optimize predictability and control risk. Three pillars
uphold every implementation of empirical process control: transparency, inspection, and
adaptation:
1. Transparency – The aspects of the process that affect the outcome are visible, as well as what is
being seen must be known in its realistic state.
2. Inspection – Frequent enough inspection allows the detection of unacceptable variances. The
frequency of inspection should not exceed the tolerance to inspection.
3. Adaptation – If inspection reveals elements outside acceptable limits, the process or the
materials being processed are adapted as quickly as possible to minimize further deviation.
The Scrum Framework offers four formal opportunities for inspection and adaptation during these
events:
 Sprint Planning
 Daily Scrum
 Sprint Review
 Sprint Retrospective

Activity: What is Needed for Scrum?
Write down your answers here:

Each Role Has a Specific Accountability
The Scrum Framework defines specific responsibilities for each role it defines.
Product Owner
The Product Owner is responsible to optimize the value of the product. She is doing so by managing
the Product Backlog, deciding what goes on the Product Backlog and what is removed and how it is
ordered. To understand value, the Product Owner must understand the needs and the environments
of the users of the product as well as the needs of other stakeholders.
Developers
The responsibility of the Developers is to create and deliver a Done Increment. It is responsible for
its technical quality and its sustainability. Finding ways how this can be achieved best is also part of
the responsibility of the Developers as they are self-managing.
Scrum Master
In Scrum the Scrum Master ensures that the Scrum Framework is understood correctly by the Scrum
Team as well as by other parts of the organization. The Scrum Master coaches people to help them
finding and applying improvements and helps by removing impediments.
Note
While the Scrum Framework defines specific accountabilities, one should not misinterpret this as
working on those topics alone. Collaboration and providing different perspectives and expertise to
open discussions is a way to get a broader picture. For example, the Product Owner should consult
with the Developers about ordering the Product Backlog. But in the end, there is always one role
which is in charge to decide if no consensus can be achieved.

Activity: Scrum Values
Put these values as large placeholders on the wall. Refer to them when appropriate during the class.
Courage – Show courage in not developing what nobody wants. Show courage to not deliver undone
software. Show courage in sharing all relevant information (transparency). Show courage in
admitting you are not perfect (nobody is). Show courage to change direction. Show courage in asking
for help.
Focus – Focus on what you know (think: YAGNI – You Ain’t Gonna Need It). Focus on what’s most
important. Focus on what’s most nearby in time. Focus on your work. Focus on the simplest thing
that might possibly work. Focus on getting to Done.
Commitment – Commit to the team. Commit to quality. Commit to collaborate. Commit to learn.
Commit to do the best you can, every day. Commit to the Sprint Goal. Commit to be professional.
Commit to self-organize. Commit to excellence. Commit to the agile principles
(http://agilemanifesto.org/principles.html). Commit to deliver working software. Commit to look for
improvements. Commit to your team’s Definition of Done. Commit to following the rules of Scrum.
Commit to deliver value. Commit to finish work (before starting new work or multi-tasking). Commit
to continuously inspect and adapt. Commit to transparency.
Respect – Respect people for their experience and personal background. Respect diversity (it makes
you stronger). Respect different opinions (you can learn from them). Respect each other’s
accountabilities.
Openness – Be transparent. Be open about your work status. Be open for people. Be open to
collaborate across disciplines and skills. Be open to collaborate with stakeholders and the
organization. Be open in sharing feedback. Be open to receive feedback. Be open for change. Be
open to working outside your comfort zone.

Scrum in a Nutshell
Scrum is a lightweight framework that helps people, teams and organizations generate value
through adaptive solutions for complex problems.
In a nutshell, Scrum requires a Scrum Master to foster an environment where:
1. A Product Owner orders the work for a complex problem into a Product Backlog.
2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
4. Repeat
Scrum makes clear the relative efficacy of your product management and development practices so
that you can improve. The Scrum framework consists of a Scrum Team and its associated
accountabilities, events, artifacts, and rules. Each component within the framework serves a specific
purpose and is essential to Scrum’s success and usage.
In Scrum, time is divided into something called Sprints. A Sprint lasts one month or less and all
Sprints have the same duration. A Sprint is timeboxed; that means that it is never extended (even by
one or two days). Every Sprint has a time scheduled at its end to inspect the software being
developed in that Sprint. This is called the Sprint Review. It is important to define the date and time
of the Sprint Review and to invite the interested stakeholders.
The team creates software during the Sprint. At the Sprint Review, the stakeholders provide
feedback and the plan for the next Sprint is adapted according this feedback.

Scrum Roles, Artifacts, and Events
The Scrum Team consists of a Product Owner, the Developers, and a Scrum Master. Effective Scrum
Teams collaborate and work well together. Scrum Teams deliver products iteratively and
incrementally, maximizing opportunities for feedback. Incremental deliveries of Done product
ensure a potentially useful version of working product is always available.
Scrum’s artifacts represent work or value in various ways that are useful in providing transparency
and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed
to maximize transparency of key information needed to ensure Scrum Teams are successful in
delivering a Done Increment.
Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not
defined in Scrum. Scrum uses time-boxed events, such that every event has a maximum duration.
This ensures an appropriate amount of time is spent planning without allowing waste in the planning
process. Other than the Sprint itself, which is a container for all other events, each event in Scrum is
a formal opportunity to inspect and adapt something. These events are specifically designed to
enable critical transparency and inspection. Failure to include any of these events results in reduced
transparency and is a lost opportunity to inspect and adapt.

Product Owner
The Product Owner is responsible for maximizing the value of the product and the work of the
Developers. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is one person, not a committee. The Product Owner may represent the desires
of a committee in the Product Backlog, but those wanting to change a backlog item’s priority must
convince the Product Owner.
The Product Owner optimizes value of the product:
 Responsible for the product success and ROI

 Is the voice of the user and customer
 Manages the vision of the product
 Decides on release date, content and budget
 Defines value-added and key features of the product
 Manages the stakeholders
The Product Owner maintains the Product Backlog:
 Is accountable for the management of Product Backlog items

 Collaborates with the Developers and stakeholders to refine requirements
 Orders the Product Backlog
 Works with Developers to estimate items in the Product Backlog
 Creates and updates the release plan and reports

Developers
The Developers are professionals who do the work of delivering a releasable Increment of a Done
product at the end of each Sprint. Everybody who contributes to the Increment is a Developer.
Developers are cross-functional, which is to say the entire team must collect all of the skills
necessary to create an increment of work. Individual Developers often have specialized skills, such as
analysis, design, programming, testing, etc. A Scrum Team should work on overlapping skills. If more
than one Developer is able to do a task, planning gets simpler and the team has more options. This is
the reason why the team should strive to overlap in their skills to some degree. This is not to say that
a team of generalists is preferred. Some team members will still be “rock stars” in certain areas, but
they should strive to teach as well as pick up new skills, especially if they are needed but not
available.
The Developers:
 Are part of the Scrum Team

 Are cross-functional (can do analysis, design, programming, testing, etc.)
 Are self-organizing
 Should contain full-time members
 Should be co-located
 Membership should not change during the Sprint
 Culture should be one of learning and collaboration

Scrum Master
The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do
this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum
Master is a leader who serves the Scrum Team and the larger organization.
The Scrum Master helps those outside the Scrum Team understand which of their interactions with
the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these
interactions to maximize the value created by the Scrum Team. The Scrum Master helps the team
and the organization adopt Scrum. The Scrum Master teaches the team by coaching and by leading it
to be more productive and produce higher quality products. The Scrum Master helps the team
understand and use self-management and cross-functionality. The Scrum Master does not manage
the team because the team is self-managing.
The Scrum Master:
 Does not enforce solutions, but enables the Scrum Team to find its own solutions to problems
 Does not direct, but enables the Scrum Team to become self-organizing
 Does not organize the Scrum events but enables the Scrum Team to do so
 Is responsible for establishing Scrum practices and rules
 Ensures the process is followed
 Shields the Scrum Team from distractions and helps remove obstacles
 Ensures the Scrum Team is fully functional, productive, and improving its quality
 Enables close cooperation across all roles and functions and removes barriers
 Educates everyone on the Scrum process
 Facilitates rather than directs
 Helps the Product Owner understand how to best utilize the capabilities of the Developers
 Removes impediments in the organization (but not necessarily within the Scrum Team)

Product Backlog
The Product Backlog is an ordered list of everything that might be needed in the product and is the
single source of work for any changes to be made to the product. The Product Owner is responsible
for the Product Backlog, including its content, availability, and ordering.
The Product Backlog lists all features, functions, requirements, enhancements, experiments, and
fixes that constitute the changes to be made to the product in future releases. Each item in the
Product Backlog is known as a Product Backlog item (PBI). A PBI typically has the attributes of a
description, order, and size.
Product Backlog items:
 Are clearly expressed in business language

 Have a business value to the user/customer
 Can be created/contributed by anyone
 Are owned/managed by the Product Owner
 Are ordered in a way to best achieve goals and optimize value
 Are estimated by the Developers
 Should not be a specification
 Should express the “what”, but not the “how”

Sprint Backlog
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for
delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by
the Developers about what functionality will be in the next Increment and the work needed to
deliver that functionality into a Done Increment.
The Sprint Backlog makes visible all the work that the Developers identify as necessary to meet the
Sprint Goal. To ensure continuous improvement, it may include high priority process improvement
items identified during Sprint Retrospective.
The Sprint Backlog is a plan with enough detail so that changes in progress can be understood in the
Daily Scrum. The Developers modify the Sprint Backlog throughout the Sprint, and the Sprint Backlog
emerges during the Sprint. This emergence occurs as the Developers work through the plan and
learn more about the work needed to achieve the Sprint Goal.

Increment
Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback.
Incremental deliveries of Done software features ensure a potentially useful version of working
product is always available. The Increment is the sum of all the Product Backlog items completed
during the Sprint and all previous Sprints. The Increment must work, be usable, and releasable. In
other words, it must be Done.
The Scrum Team demonstrates the Increment at Sprint Review. The Increment is inspected by
stakeholders (customer, marketing, sales, etc.) who are encouraged to provide feedback and to
collaborate on making the best product possible. This feedback may be captured in the Product
Backlog as new, updated, or removed items.
“A Scrum project is only one Sprint long. A release of software is the sum of multiple
increments (and previously developed software, if any). A Scrum project cannot fail, only
deliver unacceptable return on investment.” – Ken Schwaber.

Sprint
The heart of Scrum is a Sprint, a fixed-length event of one month or less during which a Done,
useable, and releasable product Increment is created. Sprints have consistent durations throughout
a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.
Sprints contain and consist of Sprint Planning, the development work, Daily Scrums, the Sprint
Review, and the Sprint Retrospective.
During the Sprint:
 No changes are made that would contradict the Sprint Goal

 Team composition remains constant
 Quality goals do not decrease
 The Definition of Done does not change
 Scope may be clarified and re-negotiated between the Product Owner and Developers as more
is learned
Each Sprint may be considered a project with no more than a one-month horizon. Like projects,
Sprints are used to accomplish something. Each Sprint has a definition of what is to be built, a
flexible plan that will guide building it, the work, and the resultant product.
Sprints are limited to one calendar month. When a Sprint’s horizon is too long the definition of what
is being built may change, complexity may rise, and risk may increase. Sprints enable predictability
by ensuring inspection and adaptation of progress toward a goal at least every calendar month.
Sprints also limit risk to one calendar month of cost.
A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the
authority to cancel the Sprint.

Sprint Planning
The work to be performed in the Sprint is planned at Sprint Planning. This plan is created by the
collaborative work of the entire Scrum Team. Sprint Planning is time-boxed to eight hours for a one-
month Sprint. For shorter Sprints, the event is usually shorter.
Sprint Planning answers the following questions:
• What will be delivered in the Increment resulting from this Sprint?

• How will the work needed to deliver the Increment be achieved?
Sprint Goal
While the Developers forecast the Product Backlog items they will deliver in the Sprint, the Scrum
Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through
the implementation of the Sprint Backlog, and it provides guidance to the Developers on why they
are building the Increment. The Sprint Goal gives the Developers some flexibility regarding the
functionality implemented within the Sprint. The Sprint Goal can be any other coherence that causes
the Developers to work together rather than on separate initiatives.
Here are some examples Sprint Goals:
 Make the application more secure

 Deliver a minimal set of administration features
 Improve usability for mobile users
 Increase accuracy of the report data

Daily Scrum
The Daily Scrum is a 15-minute time-boxed event for the Developers to synchronize activities and
create a plan for the next 24 hours with regards to the Sprint Goal. This is done by inspecting the
work since the last Daily Scrum and forecasting the work that could be done before the next Daily
Scrum. The Daily Scrum should be held at the same time and place each day to reduce complexity.
Daily Scrums can improve communication, eliminate the need for other meetings, highlight and
promote quick decision-making, and improve everyone’s level of knowledge. Daily Scrums can also
be used to identify and remove impediments to productive development. Follow-up meetings can
occur to make adaptations to the upcoming work in the Sprint. The intent is to optimize the
probability that the team will meet its goal.
Note: It is called the Daily Scrum not the Daily Standup. If the Developers decide to stand, they may.

Sprint Review
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product
Backlog as needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about
what was done in the Sprint. Based on that and any changes to the Product Backlog during the
Sprint, attendees collaborate on the next things that could be done. This is an informal meeting, and
the presentation of the Increment is intended to elicit feedback and foster collaboration. This is a
four-hour time-boxed meeting for one-month Sprints. For shorter Sprint the time needed is usually
shorter.
Here are some ideas for running a Sprint Review:
 The Product Owner identifies what forecasted work is Done and what work is not Done
 The Developers demonstrate the work that they have Done and answer questions about the
Increment
 The Product Owner discusses the Product Backlog as it stands and forecasts likely completion
dates based on progress to date
 The entire group collaborates on what to do next, so that the Sprint Review provides valuable
input to subsequent Sprint Plannings
The result of the Sprint Review is a refined Product Backlog that defines the probable Product
Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new
opportunities.

Sprint Retrospective
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and the way it works
and create a plan for improvements to be enacted during the next Sprint. The Sprint Retrospective
occurs after the Sprint Review and prior to the next Sprint Planning. This is a three-hour time-boxed
meeting for one-month Sprints. Shorter Sprints usually need less time.
The purpose of the Sprint Retrospective is to:
 Inspect how the last Sprint went with regards to people, relationships, process, and tools
 Identify and order the major items that went well and potential improvements
 Create a plan for implementing improvements to the way the Scrum Team does its work
The Scrum Master encourages the Scrum Team to improve its development process and practices to
make them more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the
Scrum Team may also plan ways to increase product quality by adapting the Definition of Done as
appropriate.
By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it
will implement in the next Sprint. To ensure continuous improvement, they may include high priority
process improvements identified to the Sprint Backlog of the next Sprint. Implementing these
improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself.
Although improvements may be implemented at any time, the Sprint Retrospective provides a
formal opportunity to focus on inspection and adaptation.
Tip: Keep retrospectives simple and consider sharing improvements with other teams.

Complementary Practices
The Scrum framework is very open to a variety of development practices and techniques. It is
deliberately vague on what the Developers should do “for the other 7 hours and 45 minutes of the
day”.
This diagram illustrates some of the many popular people-centric and engineering-centric
complementary practices and techniques a Scrum Teams can benefit from. It is part of self-
management of the team to decide which practices will be helpful in their situation and this
continuously should be inspected and adapted.
Are there any practices missing?

Assessing progress
There are various ways of assessing the progress for a Scrum Team. Which one to choose depends
mostly on how work is sized and what is the time horizon we have in mind.
Assessing progress during a Sprint

Burndown Charts
A burndown chart is a graphical representation of remaining work over time. The remaining work
(PBIs, tasks or failing tests) are often on the vertical axis, with time along the horizontal. That is, it is
a run chart of outstanding work. However, the burndown chart do not replace the importance of
empiricism. In complex environments, what will happen is always unknown. Only what has
happened may be used for forward-looking decision-making.
If the burndown chart is used with tasks, one must be careful that finishing all tasks does not equal
to achieving the Sprint Goal which should be the primary desire of the Scrum Team.
Sprint Backlog
On the Sprint Backlog it should be visible how many items are already finished and how many are
still open. Updating the Sprint Backlog frequently creates transparency about the current state and
let the Develops raise the right questions early.
Assessing progress beyond the Sprint

The progress towards a Product Goal or any other overarching goal should also be transparent to the
Scrum Team and Stakeholders. There are some visualizations available that are based on number of
items or size of items.
When using Velocity (number of story points finished per Sprint) it should be made absolutely clear
that this will not allow to calculate a forecast with a high precision but that the Cone of Uncertainty
applies. This refers to best-case, worst-case and most likely case scenarios.
Another option is to use Probabilistic Forecasting based on statistical methods like the Monte Carlo
Simulation. You can read more about Monte Carlo Simulation here: https://bit.ly/3szO4JM

Still in a complex environment we have to accept uncertainty and each of these methods can just
create transparency to trigger discussions early. They should not become a commitment because
otherwise the Scrum Team will have to cope with the ingrained uncertainty in other ways like
sacrificing quality.


Resources to learn more about this subject
The Scrum Guide

Ken Schwaber, Jeff Sutherland
http://scrumguides.org
Scrum – A Pocket Guide

Gunther Verheyen
https://amzn.to/2HpP1cJ
The New New Product Development Game

Hirotaka Takeuchi, Ikojiro Nonaka
http://bit.ly/2nP2eYX

Case Study
This module will introduce you to the case study reference application and related software
repositories and artifacts. This will be the product that your team will be working on throughout the
rest of this course.

Defining Quality
There are many potential meanings of the term quality. Even if we scope the conversation to
software development, there still is no single definition that wins over the others. Keep in mind that
“quality” is a very subjective thing and every stakeholder may define it differently.

Activity: What Quality Attributes Do You Value?
Within software development, quality attributes are non-functional requirements used to evaluate
the performance of a system. They are sometimes named "ilities" after the suffix many of the words
share.
For a complete list, visit http://bit.ly/4sYDC7.
Record your observations here:

Case Study Kickoff
The instructor will assume the role of Product Owner, delivering a narrative overview of the case
study. Please use active listening skills to maximize the value of the conversation. Also, feel free to
question and challenge as needed. This is a role-playing activity, so have fun participating. The
second part of this activity will be to work as a team to obtain the source code, build, run, and
evaluate the case study application.
What is the case study?
Record your observations here:
The primary goal of the case study is to let students experience great Scrum and what
differentiates Professional Scrum from mechanical Scrum
The case study offers plenty of opportunities to experiment with technical practices discussed during
the training. It shows enough examples of Inspect & Adapt for a Scrum team. The case study covers
the following learning objectives.

Learning Objectives
 Importance of the Product Backlog Refinement to provide a shared understanding of PBIs

and to reduce risks from hidden assumptions.
 Splitting PBIs, examples / methods students can apply.
 When splitting PBIs, architectural decisions might be involved.
 Ambiguity and misunderstandings in PBIs cannot be fully eliminated with extensive Product
Backlog Refinement.
 Students experience the negative impact of technical debt on the performance of the team,
for example merge conflicts caused by badly structured code (too much code in one file).
 How to use Sprint Goals and the value they provide.
 The importance of the Definition of Done and why the Developers should not sacrifice it just
for being able to claim to have a Done Increment for the Sprint Review.
 Students have an opportunity to practice TDD.
 Actively practice slicing in order to be able to deliver a usable solution even if not the full
requirement has been implemented.
 How not doing a Backlog Backlog Refinement might impact the ability to plan the next
Sprint, for example by not being able to create a plan for the Sprint during the timebox.
 Experiencing the value of CI/CD pipelines to automate the deployment process and
therefore make deployment painless and effortless.
 Practice swarming and/or mob-programming.
 Understand how important it is to have clear agreements before starting implementation,
for example during Sprint Planning or as a first activity in the Sprint defining interfaces to
allow the whole team working together.
 Demonstrate the importance that the Product Owner contributes to the Sprint outcome
even without coding or testing.
 Non-coders are contributing to the Sprint Goal and are active Developers.
 Actively experience the value and effect of Scrum elements.

Done Means Releasable
When the Product Backlog item or an Increment is described as Done, everyone must understand
what that means. Although this varies significantly per Scrum Team, members must have a shared
understanding of what it means for work to be complete, to ensure transparency. This is the
Definition of Done for the Scrum Team and is used to assess when work is complete on the product
Increment. The same definition guides the Developers in knowing how many Product Backlog items
they can select during Sprint Planning. The purpose of each Sprint is to deliver Increments of
releasable functionality that adhere to the Scrum Team’s current Definition of Done.
An explicit and concrete Definition of Done may seem small but it can be the most critical checkpoint
of work in Scrum. Without a consistent meaning of Done, velocity cannot be estimated. Conversely,
a common Definition of Done ensures that the increment produced at the end of Sprint is of high
quality, with minimal defects. The Definition of Done is the soul of Scrum and mature Developers
will resist demonstrating at the Sprint Review (let alone deploying) any increment that is not Done.

Releasable
A releasable product is one that has been designed, developed and tested and is therefore ready for
distribution to anyone in the organization for review or even to any external stakeholder. This isn’t a
prototype or a demo-only release. This is ready for production. Adhering to a list of acceptance
criteria ensures that the Increment is truly releasable, meaning:
• All aspects of quality are ready

• No corners were cut during development
• All acceptance criteria were met and verified
• The Product Owner accepts it
The Product Owner can accept the work at any time during the Sprint. The Sprint Review should not
be an “acceptance meeting”, but rather an opportunity to inspect the Increment and adapt the
Product Backlog.
Don’t Generate “Undone” Work

It's cheaper to improve development practices so Done is completely Done, rather than continue
working on Product Backlog items with an unknown amount of work left over at the end. The
problem is Done is inherent in the word "undone". If a Product Owner looks at an Increment and
doesn't know how much work is still left open she can’t really know when results can be delivered to
customers. She can’t know how many stabilization work is necessary to do all the accumulated
undone work.
What’s worse is that “undone” work from the first Sprint gets piled on by “undone” work from the
2nd, 3rd, etc. Sprints require even more work to reach done. That is, “undone” work accumulates
logarithmically not linearly. This introduces a new degree of uncertainty or unpredictability into a
process that is supposed to promote transparency and predictability.
Note: There is no such thing as “done-done”. If there was, it would imply that Done wasn’t really
Done.

Activity: What Is Your Definition of Done?
In this activity each team will brainstorm and define their own Definition of Done (DoD). This will
then be posted and reported by each team, so other teams can get a feel for the variety of items in
every team’s definition. Capture each individual item in your definition on a separate sticky note or
card.
Plan on revisiting your DoD during each Sprint Retrospective in this course.
You can also record your definitions here:

Example Definitions of Done
Here are a few fictitious Scrum Teams using real-world Definitions of Done:
FABRIKAM TEAM TAILSPIN TEAM
 A new feature is driven by one or more  Documentation has been created/updated

tests  Documentation has been peer reviewed
 No known duplication  Code has been checked-in to version control
 No known bugs  Code/solution has been reviewed by peer
 Continuous build between DEV and STAGE  Code is written according to guidelines
 All available data in the system has been  Code has sufficient comments
imported into STAGE database  Code runs without errors in DEV
 No errors are detected in TEST during normal test
CONTOSO TEAM operations
 New functionality has been tested
 Coding is complete  Sample/test data has been created
 Code review performed  Ad-hoc, exploratory testing has been performed
 Coding standards met  Best-effort unit tests have been created,
 All tests pass executed, and return no warnings or errors
 Release notes created  Best-effort integration tests have been created,
 User manual updated executed, and return no warnings or errors
 Developers OK with work  Best-effort user Acceptance tests have been
 Product Owner OK with work created, executed, and return no warnings or
errors
NORTHWIND TEAM  Best-effort regression testing has been
performed and returns no warnings or errors
 Peer reviewed  All rework and retest work has been completed
 All test cases pass (including security and  Functionality has been promoted from DEV/TEST
performance tests) to STAGE
 No open blocking, critical, high or medium  Functionality has been approved by the Product
bugs Owner
 Automated tests have been created (unit
or integration depending on what is more
relevant).
 Documentation updated
 Included in the installer
 Reviewed by the Product Owner
 Deployed to the DEMO environment

Updating the Definition of Done
The Definition of Done creates transparency around what Developers need to do in order to create
releasable software. The DoD is a tool for Developers to better meet quality expectations from
stakeholders. Therefore, new insights and learnings, e.g. from Sprint Reviews might result in
updating the DoD if the Developers think these changes might better support them in achieving their
quality goals.
The Developers have to be careful how they formulate their Definition of Done. The criteria stated in
the DoD must reflect what is actually done by the Developers. For example, they might precisely
state if a new criterion applies to all the existing codebase or only to added or modified code.
In the end, the Definition of Done always applies to the Increment.

Activity: What Is Your Definition of a Bug?
In this activity each team will brainstorm and define their own definition of a bug as well as what’s
not a bug. This will then be posted and reported by each team, so other teams can get a feel for the
different perspectives in the room. Capture the definition on the whiteboard or a sticky note.
You can also record your definitions here:
Note: You should use this definition throughout this class as you identify and report bugs.

Dealing With Bugs in Scrum
Not all bugs are equal - so they shouldn't be treated equally. Bugs found in code running in
production, or in a Done Increment waiting to be released to production, are out of the scope of the
team's forecasted work for the Sprint. As such, they should be handled the same as any feature
request. The bug should be added to the Product Backlog, refined by the Scrum Team, and
forecasted in a later Sprint.
If the Product Owner deems the bug as being critical and requiring an immediate fix then the
Developers should drop what they are doing and fix the bug. The hotfix may or may not require all
Developers’ capacity. Regardless, everyone must realize that the Sprint's forecast may be missed and
achieving the Sprint Goal might even be in jeopardy. The Product Owner weighs these risks and,
after collaborating with the Developers, makes the decision.
Note
Failing tests are not bugs that can then be put on the Product Backlog and fixed later. Failing tests
are a signal that something has been destroyed and that the increment is not Done yet. If the
Definition of Done does not require passing tests, it is strongly recommended to reconsider this.

In-Sprint Bugs
Bugs found in the code the Developers are working on during the Sprint are called “in-Sprint” bugs.
These may not be bugs according to the classic definition, but rather the code is just not quite there
yet. Most teams' definitions of done include "code compiles", "no errors", or "no bugs found in new
code". In these cases, it's not really a bug - the Developers just aren't done yet. The goal for in-Sprint
bugs is to fix them, not manage them. Ideally you want to fix all bugs discovered during the Sprint. If
you don't, they could impact the Developers’ ability to achieve their forecast or Sprint Goal. Here is
the guidance I give the Scrum Team for handling in-Sprint bugs:
• If it’s a small bug (< n hours to fix) and won’t impact the burndown, then just fix it. The
Developers decide what "n" equals. A value of 2 is commonly used.
• If it’s a larger bug (> n hours to fix) and won’t impact the ability to achieve the Sprint Goal or
forecast, then create a bug work item, associate a task work item, and have a Developer code
the fix during the Sprint. The work items will explain the reason behind the hiccup in the
burndown.
• If it’s a larger bug (> n hours to fix) and will impact the ability to achieve the Sprint Goal or
forecast, then create a bug work item and discuss the situation with the Product Owner. She
may value the bug fix over another PBI in the forecast. If not, then the bug will be left in the
code this Sprint and the bug work item will be refined and fixed in a future Sprint.
• If another team member finds a small bug and it's not possible to collaborate on an immediate
fix, then a bug work item should be created and assigned to the current Sprint. The Developers
must decide if it can be fixed in the current Sprint or in a later one. If the bug is left in the code,
the Product Owner should be consulted, and everyone needs to realize that the Sprint's forecast
may be missed and achieving the Sprint Goal might be in jeopardy. What's worse is that you
have now added technical debt to your software product.
Out-of-Sprint Bugs
Bugs found in production code, or in a Done Increment waiting to be released to production, are
referred to as “out-of-Sprint” bugs. Typically, these bugs don't impact the code associated with the
forecasted work the Developers are working on at the moment. If code is impacted, then treat them
as in-Sprint bugs. Otherwise, consider the guidance I give a Scrum Team for handling out-of-Sprint
bugs:
• If the Product Owner determines the bug is critical, the Developers should do whatever needs to
be done to get a fix into production. Everyone must realize that the Sprint's forecast may be
missed and achieving the Sprint Goal might be in jeopardy.
• If the bug is not critical, then create a bug work item. The Product Owner will decide if and when
the bug is refined and forecasted in a future Sprint.
• If the number of critical bug occurrences increase, consider adjusting the Developers’ capacity or
dedicating a Developer to supporting maintenance issues like these. The Scrum Team should
also look for the root cause of these critical bugs and a solution during the next Sprint
Retrospective.
Note: Fellow Professional Scrum Developer Charles Bradley has created the Bradley Bug Chart,
which is a flowchart that encapsulates the above workflow. Check it out at http://bit.ly/2P8qIb2.

Reporting a Bug
A bug report is just that - it’s the reporting of a bug or other unwanted behavior in the software
product. In order to write a good bug report, it must contain enough information for the Scrum
Team to understand it, gauge its impact on the business, and estimate the effort to fix it.
A good, clear title is a must. A Developer should be able to grasp the essence of the bug from the
title alone. If there are many bug reports, having a clear title will help the team as they refine the
bug, forecast it, and develop the fix.
You should only report one bug per report. If you document more than one bug, some of them may
be overlooked. Atomic bug tracking like this helps in the same way atomic testing does – it provides
a very precise understanding of what’s working and what isn’t.
A picture is worth a thousand words. Sometimes words just can’t demonstrate the issue like a
screenshot or mockup can. Developers will appreciate these extra efforts because they need to find
the problem in the shortest amount of time. Any helpful documentation like this can be attached to
the bug report.
Bug reports should always contain the observed as well as the expected results. This is a good
practice because sometimes Developers don't think that the bug is a real bug. The variance between
expected and observed should prove the case.
Tip: Avoid blaming and politics when reporting a bug. Be professional.


Product Backlog Refinement
This module introduces you to the practice of refining the Product Backlog and related estimation
techniques.

Refining the Product Backlog
Items in a Product Backlog are of different granularity:
 Items on top are fine grained and sized. They are ready to be implemented in one of the next
Sprints. When refining the Product Backlog, you should strive to get more items into this state
 Not all items are sized. At a minimum, the items that are part of the current release should be
refined, sized by the Developers, and ordered by the Product Owner
 There are new items coming into the Product Backlog at any order – even at high order. While
refining the Product Backlog, those new items are discussed, detailed and sized.
 At the bottom of the Product Backlog there might be ideas for future release never discussed.
Keep a Rolling Backlog Projection
PBIs are sized and ordered for the next few Sprints. The current Sprint is detailed, meaning that it is
broken into Sprint Backlog tasks with very granular detail. The next one or two Sprints should be
understood by the entire Scrum Team, which means they are sized, valued, and ordered. Beyond
that, the items are loosely planned.

The Evolution of a PBI
A Product Backlog is never complete. The earliest development of it only lays out the initially known
and best-understood requirements. The Product Backlog evolves as the product and the
environment in which it will be used emerge. The Product Backlog is dynamic; it constantly changes
to identify what the product needs to be appropriate, competitive, and useful. As long as a product
exists, a Product Backlog also exists. As a product is used and gains value, and the customer provides
feedback, the Product Backlog becomes a larger and more exhaustive list. Requirements never stop
changing, which means the Product Backlog is a living artifact. Changes in business requirements,
market conditions, or technology may cause changes in the Product Backlog.
Refining the Product Backlog includes the acts of adding detail, estimate sizes, and order items in the
Product Backlog. This is an ongoing process in which the Product Owner and the Developers
collaborate on the details of Product Backlog items. While refining the Product Backlog, items are
reviewed and revised. However, they can be updated at any time by the Product Owner or at the
Product Owner’s discretion.
Refining the Product Backlog is a part-time activity between the Product Owner and the Developers.
How and when refining is done is decided by the Scrum Team. There was a suggestion in previous
versions of the Scrum Guide that Product Backlog refinement usually not takes more than 10% of
the Developers’ capacity. But this has been removed now as there might be specific situations that
would need much more or less of Product Backlog refinement. The Developers are responsible for
sizing Product Backlog items. The Product Owner may help the Developers understand and select
trade-offs, but the people who will perform the work estimate the size.
Note: Some Scrum Teams will refer to refinement sessions as “story-time” or “requirements
workshop”.

The 3Cs (Card, Conversation, Confirmation)
Traditionally, Product Backlog items (user stories, features, etc.) have been written on cards. The
card is the first C. It does not contain all the information that makes up the Product Backlog item.
Instead, the card has just enough text to identify the item, and to remind everyone what the item is
about. The card is a token representing the requirement. It’s used in planning. Notes are written on
it, reflecting priority and cost. It’s often handed to the Developers when the item is forecasted to be
developed, and given back to the Product Owner when the item is Done.
The requirement itself is communicated from the Product Owner to the Developers through the
second C, which is conversation: an exchange of thoughts, opinions, and feelings. This conversation
takes place over time, particularly when the Product Backlog item is being refined and estimated.
The conversation is largely verbal but can be supplemented with documents. The best supplements
are examples; the best examples are executable; we call these examples confirmation.
No matter how much discussion or how much documentation is produced, the Scrum Team can’t be
certain about what is to be done. The third C adds confirmation that is sorely need. This component
is implemented by the acceptance tests. During Product Backlog refinement, during various bilateral
discussions and at the beginning of the Sprint, the Product Owner communicates to the Developers
what she wants. She is telling that not only in form of what she wants, but also by telling them how
she will confirm that they’ve done what is needed. She defines the acceptance tests that will be used
to show that the item has been implemented correctly.
For more information read Ron Jeffries blog post here http://bit.ly/1PqFBuS.

Spikes
There will be times that the Developers will be required to develop something that they haven't
done before. Needless to say, they cannot estimate with any confidence either. This could include
developing new capability using a new product, component, framework, system, or language. The
Developers will need to learn and practice in order to successfully develop the feature. They also
need this experience sooner, in order to be able to estimate the size of the PBI.
Organizations can't expect their Developers to gain this knowledge on their own, although some
Developers will. I know many Developers who consider their profession as their hobby. For these
geeks, learning new things is just fun. For the rest of the world, this learning will have to come during
company time on the company dime. But how does this fit with Scrum? The answer is to perform a
spike, which is another word for a technical investigation, proof of concept (POC), or an experiment.
The outcome of a spike is just enough knowledge to be able to give the Developers some confidence
in their estimate. Ultimately, Scrum is about learning from data derived from experiments, so the
spike concept fits right in.
Most spikes are small and executed as needed throughout the Sprint. In fact, I wouldn't even call
them a spike. They are just part of development. Some Scrum practitioners call them spike tasks (as
opposed to the larger spike stories). If a Developer needs to clarify a technical issue, and another
team member cannot help, the Developer can create a quick spike instead. Timeboxing should
always be used to keep spikes as small as is necessary. The Developers can decide on the criteria for
when to track the task in the Sprint Backlog, such as by creating a work item.
Tip: Timebox all spikes, no matter how large they are.

How We Estimate Best
The Developers are responsible for all estimates of size. It makes sense that the people who will
perform the work (i.e. the Developers) make the final estimate. For smaller teams where the
Product Owner and/or Scrum Master are also supporting by taking on Developer work, they will
have input on the estimates as well. Never underestimate how long good estimation takes, but also
realize that too much analysis and estimation can have a diminished return on the time invested.
Estimation should be performed as late as possible. Early estimates are less accurate than later ones.
You always know more today than you did yesterday. You also don't want to waste the Developers’
time estimating items that are "way down the list". Proper ordering of the Product Backlog can
reduce waste when estimating. The Product Owner should know what's coming up next or soon
thereafter and focus on those items. He or she should wait until larger PBIs are decomposed.
Agile estimation is not a silver bullet. In fact, it's the worst form of estimation except all the others
that have been tried. Agile estimation techniques won't remove uncertainty from early estimates,
but they also won't waste unnecessary time. Estimates will become more accurate over time. This is
due to the empirical nature of Agile estimation techniques where actual work is taken into account.

Activity: What is the Size of My House?
Remember, estimation is not about the effort, but about understanding the context. Regardless of
the actual size of my house, you have learned a lot about me and my family.

Estimation in Hours is Not Required
Estimates are often made in hours, days, weeks, etc. It is not required to do so. In fact, estimating in
any kind of temporal unit of measure might indirectly imply a plan or a promise.
Estimating in Hours is Expensive

 Is the task’s effort 8 or 10 hours? As you have learned from the cone of uncertainty the 20%
difference does not matter. Estimates at Sprint Planning are accurate only within a factor of 2.
Using hours may give a wrong feeling of being accurate.
 Does the estimate include informative meetings, personal education, coffee breaks, etc. (real
hours) or only the time spent on task progress (ideal hours)? What is the factor between real
and ideal hours?
 Estimating in hours tends to include budget forecast. In other words, it is relatively simple for a
Developer to calculate the total costs of this task when the effort in hours is known. Knowing
this, a Developer’s estimate tends to be lower.
 And last but not least, the estimate becomes measurable and your inaccurate estimate becomes
a commitment: You will be measured how good your estimate is by reporting the actual hours
spent on this task. What do you do in this case? Adding a buffer to the estimate and filling the
remaining time after you have finished the task with some private work? That was not the
original idea of actual hours reporting.
Furthermore, when estimating in hours (or days) and then measuring actual work, Developers add
automatic buffers to make the estimates more accurate. They also tend to ensure their work fills
those estimates. This is often referenced as Parkinson’s law which describes that work expands so as
to fill the time available for its completion. This cannot happen if you are using abstract units of
measure since there is no absolute end date. For more information on Parkinson’s law visit
http://bit.ly/kM8DXs.

Estimation Technique: Wall Estimation
Wall Estimation is designed to allow Scrum Teams to quickly group PBIs in a purely relative manner
along a continuum, at least initially. It also allows stakeholders to give a general prioritization to a
large group of PBIs without getting hung up on whether one PBI is slightly more important than
another.
Everyone should have laser focus and actively listen to the estimator's reasons. Everyone else should
remain silent. There should be no discussion or judgment. If the Developer does not stick the card to
the board within one minute, the card is placed in a default, medium-sized column. The player then
restarts the timer for the next player. After a few rounds, there should be an assortment of cards
stuck to the whiteboard. Team members can now, on their turn, choose to move one of the cards to
a different column instead of selecting a new card from the deck. The player should read the item
out loud as well as the reason supporting the decision to change the estimate.
Eventually all of the cards will be stuck to the whiteboard and estimated. Each player, on their turn,
can either move a card between columns or simply pass. Passing means that they are satisfied with
the current estimates. If a Developer does not make a decision within one-minute, it will be
generally understood to be a pass. The estimation game ends when the pile of cards is now on the
whiteboard and every Developer signals pass.
Note: This technique is similar to the Affinity and White Elephant estimation techniques.

Activity: Refine the Product Backlog
In this activity, you will use what you have learned thus far to refine the items in the Product
Backlog.

Estimation Technique: Planning Poker
Planning Poker is a very popular tool for estimating Product Backlog items. It is a technique that
minimizes anchoring by asking each Developer to play an estimate card such that it cannot be seen
by the other players. After each player has selected a card, all cards are exposed at once. The Scrum
Master won’t participate in the estimation game. Instead, the Product Owner together with the
Scrum Master can facilitate the meeting.
The units represented are typically story points in a limited Fibonacci sequence. There may also be
question mark, infinity, and coffee break cards. The cards are numbered in this sequence to account
for the fact that the larger an estimate is, the more uncertainty it contains. Thus, if a developer
wants to play an 8 he is forced to reconsider that some of the perceived uncertainty does not exist
and play a 5, or accept a conservative estimate accounting for the uncertainty and play a 13.
Typically, the most knowledgeable team member for a given PBI provides a short overview. The
team is given an opportunity to ask questions and to discuss and clarify assumptions and risks. A
summary of the discussion should be recorded. Estimation commences and team members with
high estimates and low estimates are given an opportunity to justify their estimate and then
discussion continues. The team should repeat the process until a consensus is reached. If consensus
is not reached after 2-3 rounds, estimation should be tabled. More will be known later.
Note: Planning Poker® is a registered trademark of Mountain Goat Software.

Anchoring
Anchoring occurs when a team openly discusses their estimates prior to the playing of the cards. A
team normally has a mix of conservative and impulsive estimators and there may be people who
have agendas. Developers are likely to want as much time as they can have to do the job and the
Product Owner or customer is likely to want it as quickly as possible.
The estimate becomes anchored when the Product Owner, or an experienced Developer, says
something like, "I think this is an easy fix, I can't see it taking longer than a couple of days", or when
another Developer says, "I think we need to be very careful, clearing up the issues we've had in the
database could take months". Whoever starts the estimating conversation with, “I think it's 13
points” immediately has an impact on the thinking of the other team members; their estimates have
been anchored. In other words, they are all now likely to make at least a subconscious reference to
the number 13 in their own estimates.
Those who were thinking 21 points are likely to reduce and those who thought 5 are likely to
increase. This becomes a particular problem if the 13 is spoken by an influential member of the team
when the rest of the team are predominantly thinking higher or lower. Because the remainder of the
team has been anchored, they may consciously or otherwise fail to express their original unity; in
fact, they may fail to even discover that they were thinking the same thing. This can be dangerous,
resulting in estimates that are influenced by agendas or individual opinions that are not focused on
getting the job done right.

Activity: Refine the Product Backlog
In this activity, you will use what you have learned thus far to refine the items in the Product
Backlog.

Activity: When to use what
There is not a single preferred sizing technique. Different techniques have different advantages and
the team should decide when to use which one.
Usually Wall Estimation should be much faster than Planning Poker as we have less discussions. This
is an advantage and a disadvantage as well. Some teams use Wall Estimation to estimate a bigger
number of new PBIs and then refining them in smaller batches by using Planning Poker. This is part
of the refinement process we have for the evolution of a PBI.
Another valuable combination is that Wall Estimation visualizes the relation in a great way so you
could have a wall with some reference PBIs while doing Planning Poker. This can help to prevent a
slip of your references over time.
There are other good estimation techniques available. Find out which one fits your team and your
situation best.

To Be More Accurate, Be Less Precise
This was stated by Steve McConnell said in his Software Estimation book and is true. If the estimator
is constrained to estimating a piece of work as either Small, Medium, or Large, it will be very
accurate, but only because the measurements are not very precise. Contrast this with something
very precise, such as hours or days. Those estimates are never accurate. Also, if the estimator uses a
temporal unit of measure, it can imply a plan, or a commitment, or something that pertains to a
schedule. Using an abstract unit of measure, such as story points, increase accuracy while removing
implied misunderstanding. They still enable a team to track progress and estimate completion. Here
are some examples of abstract units of measure used in estimation:
 T-shirt sizes (S, M, L, XL, XXL)

 Fibonacci (1, 2, 3, 5, 8, 13, 21, 34, …)
 Count PBIs
The Scrum Team decides which estimation unit and technique fits their needs best, also considering
the needs of the Product Owner. The minimum of estimation the Scrum Guide is requesting is the
ability to craft a forecast for the next Sprint.

Estimation Technique: #NoEstimates
Estimation is not the only option to come up with a plan.
More and more Scrum Teams don’t work with estimates any more. This has become popular under
the Twitter Hashtag #NoEstimates, which is misleading: it doesn’t mean that a team is not
estimating anymore; it just means that they don’t use estimation values.
#NoEstimates expects Product Backlog items to be right-sized, which means they are small enough
to fit into a Sprint. The search for an estimation value (hours, sizes or Story Points) is replaced with
more clarification and slicing of big items into smaller ones. To achieve right-sizing, teams can use
techniques like Planning Poker®, Wall Estimation or others with just 2 options: size 1 or “too big”.
That way the Developers can spend more of their valuable time working on the items instead of
thinking about their size. Since every estimate is a guess this reduces waste.
As with the other estimation techniques #NoEstimates is not by itself a goal or the only way of
working. It is one possible way of working with the Product Backlog.
A question that can’t be answered by #NoEstimates alone (which can’t be answered by Story Point
estimates as well, BTW), is the valid question of “When will it be done?”. This question needs more
tools, which we will talk about in the next section.
To predict based on #NoEstimates, flow and throughput are important. Improving these might also
help improving the process. For deeper insights into these topics you might consider looking at the
Professional Scrum with Kanban (PSK) training by scrum.org (http://www.scrum.org/psk).
For more information on predictability based on flow metrics, consider reading Daniel Vacanti’s
book:

Actionable Agile Metrics for Predictability
Publisher: ActionableAgilePress
https://amzn.to/2ITEquv

Flow/Metrics Based Release Planning
If stakeholders ask a Scrum Team using #NoEstimates “when will it be done?”, they expect –
rightfully - to get an answer. Just because we choose not to size our Product Backlog items doesn’t
mean we can ignore our stakeholder’s need for some planning into the future.
With Story Points we can use the Scrum Team’s velocity. In a #NoEstimates context we can use the
throughput of our past Sprints and simulate probable outcomes based upon this data. A commonly
used technique to do this is the Monte Carlo simulation. It uses the past throughput data (e.g.
number of items finished per day) and runs simulations on that. It simulates a certain number of
Sprints (e.g. 10,000) and uses a random distribution of our possible throughputs from the past.
These simulations create a bell curve distribution of probable outcomes.
In a second step we add the percentiles we are interested in, by asking: if we simulate 10,000 times,
what date will we be done with a certain number of items (e.g. 100 for the next release) in 85% of
the cases? The number of items is related to right-sized items. So, you can either limit your forecast
horizon to this part of your Product Backlog or you could estimate bigger items based on how many
right-sized items they might contain. But then there is no big difference to estimating with Story
Points. Be careful, there are some downsides if you right-size PBIs too far into the future.
The results of the Monte Carlo simulation can then be translated into a calendar view. In the above
example we have a 50% probability to finish the desired set of PBIs by February 3rd or later, a 70%
probability to finish February 7th or later and so on. The later in the calendar, the higher the
probability that we will be finished by then. But there is no 100% probability.
Monte Carlo simulation gives you probabilities and confidence levels. It does not give you release
dates. Based on this simulated data and the confidence levels they represent you can then discuss
possible release dates and scopes with your stakeholders.
For more information on flow-based planning also consider the Professional Scrum with Kanban
Training (PSK). For more information visit http://www.scrum.org/psk.

When Will It Be Done?
Publisher. ActionableAgilePress
http://bit.ly/31mTQ0u


Actionable Agile Metrics for Predictability
Daniel S. Vacanti
https://amzn.to/2ITEquv
When will it be done?

Daniel S. Vacanti
https://amzn.to/3CaFbcU
The Professional Product Owner

Don McGreal, Ralph Jocham
https://amzn.to/2JA9Xmw

Sprint 1
In this activity, you and your team will experience a mini-Sprint.
The Product Owner presents the refined Product Backlog to the Developers. The Developers then
select an achievable set of work from the highest-ordered items. This is their forecast. Together they
also create a Sprint Goal and a plan on how to develop those items.
The Developers will then proceed to work efficiently and effectively through their plan (tasks). After
the development timebox has expired, the team should have built an Increment of functionality with
at least some demonstrable business value. This is then demonstrated to stakeholders in the Sprint
Review where feedback is solicited and recorded in the Product Backlog. The team then inspects and
adapts their performance in the Sprint Retrospective in order to make improvements in the way
they work in the following Sprints.
Who will be your Scrum Team’s Product Owner?

____________________________________________
Who will be your Scrum Team’s Scrum Master?

_____________________________________________

Activity: Sprint Planning
In this activity, your team will select items from the refined Product Backlog, create a representative
Sprint Goal, and a plan for achieving this. Be sure to work together as a team, involving the Product
Owner as needed, to do this. Consider your capacity and past performance as you do this.
Please record your Sprint Goal here:
Considerations
 Did you ask adequate questions of the Product Owner?

 Did you consider any PBIs that were not refined?
 Did you consider your capacity/past performance?
 Did you consider your Definition of Done?
 Did you work with the Product Owner to create the forecast and Sprint Goal?
 Did you add your forecasted PBIs to the Sprint Backlog?
 Did you decompose the PBIs into tasks?
 Did you estimate the effort of these tasks?
 Did you create any large/vague tasks to be detailed later?
 Did everyone leave the meeting owning at least one task?

Activity: Development
In this activity, your team will self-organize and use whatever tools and practices it chooses to
develop the items in the Sprint Backlog and achieve the Sprint Goal. Keep the DoD in mind, as you
work.
Considerations
 Will you use your work planning/tracking tool to track the states of tasks?
 Will you maintain and use a Sprint burndown chart to assess progress?
 How will you handle impediments?
 How will you ensure that your work is Done?
 When and where will you meet for your Daily Scrum?
 When refining the Product Backlog, will you use your team’s velocity?
 Consider revisiting and re-estimating some PBIs that were previously refined

Activity: Sprint Review
In this activity, your team will inspect the Increment through demonstration, solicit feedback, and
adapt the Product Backlog with new or updated PBIs.
Who will be doing the demonstration(s)?
Considerations
 Did you achieve your Sprint Goal?

 Did you complete the forecasted PBIs?
 Did you pull any additional work?
 Did you have any “undone” work?
 Did you have anything to demonstrate?
 Did you only demonstrate functionality that was Done?
 Did your increment have any business value?
 Did your team have working tests with the code (if applicable)? Did those tests pass?

Activity: Sprint Retrospective
In this activity, your team will inspect how the Sprint went with regard to the processes and
practices. The goal is to identify areas that can be improved in order to make future Sprints more
effective and enjoyable. The score of this meeting includes people, relationships, culture, process,
practices, and tools.
What improvements will your team make in the next Sprint?
Considerations
 Did your team create and maintain a Sprint Backlog?

 Did your team post and update a Sprint burndown (or other tool to assess progress)?
 Did your team break the Sprint down into days?
 Did your team hold a Daily Scrum each day? If so, was everyone present?
 Did your team keep all Developers busy? Did everyone work to capacity?
 Did you pair-up?
 Were there any impediments? If so, did you record them?
 Do you need to alter your Definition of Done? If so, is it for a good reason?
 Did you capture your Sprint Retrospective? If so, where?

DevOps
In this module we want to give an overview of the term “DevOps” and its underlying principles. We
will discuss practices and tools and its relation to Scrum.
The inventors of the term “DevOps” haven’t created a strict definition. They argued that defining
DevOps will prevent its further evolvement. This leads to interesting discussions in the software
delivery community around what DevOps means and how it is applied – from a DevOps engineer via
a tool stack to a new culture of collaboration.

Activity: Define DevOps
As you participate in this discussion, take any notes below:

Activity: The Three Ways
Gene Kim, one of the inventors of DevOps, has described three ways of improving software delivery.
These three ways are often seen as the principles behind DevOps. They are described in the “DevOps
Handbook”: https://amzn.to/2DkUqnc
The DevOps Handbook was inspired by the principles of lean production and the Toyota Production
System as described in “The Goal”: https://amzn.to/2QHgs7z
You can find a quick introduction into the three ways here: http://bit.ly/2Dk2C7k

DevOps and Scrum
The primary goal behind DevOps is to increase value and lower risk for developing software
products. This goal is achieved through three ways. Their numbers are not an order of importance or
a sequence in which to apply them.
 1st Way
The first way helps to increase value by delivering value to users earlier and more
frequently. It lowers the risk through smaller and more frequent releases. In the first way
teams usually invest in automation to avoid problems. The more often you practice releases,
the more frequently you learn how to avoid problems.
 2nd Way
The second way helps to increase value through early feedback. We can sooner learn what
value means for our end users and customers. The second way reduces risk because we can
lower the investment in uneconomical features by earlier identifying the real value.
 3rd Way
The third way describes a culture of experimentation and learning, which needs a culture to
treat errors as learning opportunities. This lowers risk because errors are no longer glossed
over but made transparent. It increases value by using concepts like hypothesis driven
development. This means, we treat each change as a hypothesis that will increase the value
of our product. It remains a hypothesis until we can measure the real impact. This is
different to Product Owners being sure about what customers want and then take a big
investment before delivering the changes.
These three ways and their contribution to our goal of increasing value while simultaneously
reducing risk are very similar to some of the basic concepts in Scrum.

 Cross-functional Teams & Done
Scrum is designed to build value in the form of a releasable Increment each Sprint. This helps
to deliver value sooner and more frequently. Risk is reduced by detecting problems early,
when fixing them is still cheap.
 Empiricism
To build the right product, Scrum uses empiricism. While learning from real feedback from
stakeholders and end users and adapting our plan accordingly, we reduce the risk of wasting
too much time and money building unnecessary features or having to do a lot of rework.
Focusing our efforts on valuable features helps to increase the overall value of the product.
 Continuous Improvement
A big part of continuously improving the way of creating value are the five Scrum Values.
They define a culture where we openly discuss opportunities for improvements. They create
a safe environment for a team to try out new things and learn from them. This helps to
become better and build more value. It also reduces the risk of having serious problems
uncovered too late in the process.

Activity: DevOps Practices
There are many software delivery practices that support the ideas of the three ways:
Description of the practices from the exercise
Continuous Testing
Traditional approaches of quality assurance are often based on getting all implementation finished
before verifying the latest build of the product before delivering it to production. In contrast
continuous testing is a practice of integrating testing as a fundamental and ongoing part of
development. It helps to identify and fix issues much earlier and so lowers risk drastically.
Continuous testing is especially powerful if combined with practices like test automation, clean code
and others which help to reduce regression testing efforts.
Continuous Integration
Continuous Integration is the practice of integrating changes from different developers and teams
working on the same code base as early and as frequently as possible. This prevents big divergence
of code and lowers effort for merging changes into one single base. It also allows to find problems
and risks earlier which makes it easier to fix them.

Continuous Delivery/ Continuous Deployment
Continuous Deployment is the ability to deliver changes like new features, bug fixes, configuration
changes and others to users in a save, quick and sustainable way. Continuous Delivery therefore
should not only enable more frequent deployments but also make new releases to a none-event. It
helps to deliver smaller chunks and enable earlier feedback.
Continuous Delivery and Continuous Deployment are often used synonymously. While they have a
lot in common, there are slight differences. While Continuous Delivery is describing the ability to
automatically build and distribute the latest artifacts on a test-environment, Continuous Deployment
goes one step further by deploying into production. For more details see https://bit.ly/3c3GRI3.
Testing in Production
What sounds like a very dangerous approach can help not only to reduce cycle time but also make
your tests more reliable. It means to execute various tests right in the production environment. To
reduce the risk of affecting production operations with untested and failing functionality, various
technologies can be used to make the new functionality only available to the test process or a very
small set of users while other users will use the previous functionality. The change will be rolled out
to all users once the test was successful. This practice will help you to get rid of various test stages
like QA, UAT, Staging etc. And as the tests run in the real production environment, you can eliminate
the risk of using a test environment that behaves slightly different from your production
environment.
Feature Flags / Feature Toggles

Feature Flags are a technique that enables to remotely enable or disable functionality within a
software system without deploying a new version of the code. Often feature flags are simple
configuration switches that activate or deactivate a newly implemented functionality or selects
between an older, stable and a new implementation of a feature. Feature flags also allow to define
different behaviours for different set of users and therefore support other practices like Testing in
Production or A/B Testing.
Monitoring
Obviously, it is helpful to know the current state of your system. While most systems support logging
to analyse what happened during an outage or a problem, monitoring is used to check the current
state continuously. Once one or more parameters get out of a healthy range, alarms can be
triggered to initiate some actions.
Cycle Time
Cycle Time is the time between working on an item that has been started and the item is finished
(usually delivered to real end-users). Cycle Time defines how fast work can flow through a system
and minimizing Cycle Time helps not only to make the system more efficient but also to increase
predictability and the ability to quickly respond to changes or new insights.
MTTD = Mean Time to Detect

Mean Time to Detect is the time it takes to identify that there is a problem. The MTTD should not be
determined by the first call of an angry customer at the hotline. Monitoring tools can help to reduce
it.
MTTR = Mean Time to Recover

The Mean Time to Recover is the average time it takes from when a problem occurs until the
problem is fixed and the system is back to normal operations. There are various techniques helping

with MTTR as defensive programming and self-healing systems that can switch to an emergency
mode to keep the basic functionality of the system up and running. As MTTD is usually a significant
portion of MTTR, reducing MTTD will also help with MTTR.
Blue-Green Deployment
Blue-Green Deployment is a practice that helps reducing down-times while upgrading the system to
a new version. It has other positive effects like fast rollbacks in case of emergency. It uses two
identical environments. One environment (called blue to differentiate it from the other identical
one) is handling all requests and executing all production operations. The other environment (green)
can handle software updates and configuration changes without impacting production. Even tests
can be executed on the green environment without risk. Once the green environment is ready, all
requests are switched over to this one and it becomes the new blue environment. The previous blue
environment at the same time becomes the green one and can be used for the next update.
Test-Automation
Automating tests is not only a way to increase the quality of a product, it also helps to reduce cycle
time. If you see test execution as one form of feedback, automated tests help to get this feedback
much earlier. This lowers the effort of fixing issues and allows to deliver releasable increments much
faster.
Vertical Teams
In traditional organizations, there are many different teams and departments involved in the process
from a customer providing feedback or suggesting an improvement to delivering the new version to
customers. Sales & Marketing, Product Management, Development, Quality Assurance, Operations
and more jump to mind. But each different department or team means there is a handoff. Handoffs
tend to be slow and error-prone. In contrast a vertical team combines all the necessary
competencies to handle the whole process end-to-end. In such scenarios teams typically are only
responsible for small parts of the whole product. So instead of splitting the organization into
horizontal layers (departments) this approach suggests slicing the product.
Infrastructure as Code
Instead of setting up and configuring infrastructure and environments, this process can be
automated by scripts and parameter files. While this approach is not faster for the initial setup of the
infrastructure (it might even be slower), it provides a lot of advantages. The scripts and configuration
files can be stored in version control together with the source code of the software. This allows to
create exactly the matching environment for a given version of the software. Changes to the
environment are documented in version control as they are no longer executed on the environment
directly but by changing and executing a script. And new instances of an exact copy of the
production environment can easily be created, for example for testing purpose.
Release-Pipelines
Automating the steps from code commit into version control to delivery in production help
increasing speed and reliability of this process. This practice is often referred as Release-Pipelines as
this pictures the ideal of a steady stream of changes delivered.
Blameless Postmortems
The purpose of a Blameless Postmortem is to understand systemic factors that lead to an outage
and identify learnings and actions that can help to prevent this kind of failure from recurring. This
practice is based on the idea that in hindsight we usually know how the outage could have been

prevented. But the past cannot be changed and therefore it is useless to discuss who should have
done what, aka as blaming. But it is about shaping the future by learning from what just happened.
What can we learn and how can we improve our process to make it more resilient?
Error Culture
How mistakes are handled has an important impact on an organizations ability to innovate. If people
feel that errors are something negative and try to avoid them, they might be much less likely to take
a risk and try something new. Instead encouragement for experimentation and learning is important
while at the same time considering how to tame risks and decrease the impact of failures.
Application Telemetry
Understanding how a product is used is a key factor for taking better decisions on where to invest.
Application Telemetry can provide some insights to increase this understanding by showing usage
statistics, performance parameters, user workflows and other relevant information.
Dev & Ops collaboration

This is at the core of the DevOps movement. Instead of separating development and operations,
collaboration is key. Instead of developing something and then make running this in production
someone else’s problem, we try to achieve end-to-end responsibility. This not only helps with
smoothening the delivery process, but it also closes the feedback loop. A closer collaboration
strengthens learning how we could support robust operation already in the design and
implementation operations.
Hypothesis Driven Development

The basic idea behind Hypothesis Driven Development is that in a complex environment we do not
know where to invest in order to achieve the highest possible value: we formulate hypothesises
about that. Once we accept uncertainty and agree that the assumptions our plans are based on can
be wrong, it makes sense to change our approach to the development of new features. Validating
our assumptions gets high priority and finding small and fast experiments to get more insights
becomes an important part of work.
Minimum Viable Product

One practice to achieve Hypothesis Driven Development is the Minimum Viable Product (MVP). The
MVP is the smallest implementation of our product or a feature which allows to learn more about
how users will react to it or technical behaviour like performance.
A/B Testing
A/B Testing extends the idea of hypothesis driven development by evaluating two or more different
implementations to find out which one works best. Usually this is done by having different
implementations and then route a part of our users to each of them. This allows to measure which
implementation better supports the expected user behaviour. A/B Testing is often combined with
Feature Flags and Application Telemetry.

The Three Ways are About Flow
The three ways as described by Gene Kim have to do with ever smaller iterations and feedback
cycles in order to learn faster and be more innovative.
The first way optimizes the flow of work through the system. This system includes everything from
planning the work until the end user can benefit from it. The goal is to decrease the time it takes for
a single piece of work to flow through this system. At the same time this flow should be as
standardized and as painless as possible by making it a non-event.
In the second way we amplify feedback loops. We bring back the learnings and insights from
productive use by real users in order to improve the overall system. This feedback needs to be
generated and delivered as quickly as possible, as efficiently as possible and it should generate
exactly the right kind of information we need to improve our decision-making.
© Peter Götz / Thomas Schissler

The third way is about the flow of ideas and knowledge. As we act in a complex environment it is not
possible to plan the work and its results up front. Instead we have to continuously inspect and adapt
our work and the way we work. Our goal is to create a culture of learning and experimentation
where
- We accept our inability to know everything

- We use failures as opportunities to learn and see value in them
- Risk is being minimized by making small steps

Activity: Flow
There are various concepts in and part of Scrum that can be seen as batches. In order to increase
and optimize flow we want to be able to recognize them and minimize their size.
What batches do we have in Scrum and how can their size be reduced?

Azure DevOps
Azure DevOps is an integrated DevOps solution that enables software development teams of all sizes
to deliver continuous value with high velocity and high quality. It provides both individual developers
as well as entire Scrum Teams the ability to build business and consumer applications. Azure DevOps
includes a feature-rich, comprehensive, integrated environment and new tooling to support a range
of Agile practices and methods, such as Scrum. Project artifacts and data from work item tracking,
version control, automated builds and testing tools are stored centrally. Queries, charts, and reports
provide real-time transparency and traceability as well as historical trending of the progress and
quality of both the product and process.
On Premises and Cloud Solutions

Azure DevOps is available as Azure DevOps Server which is a on premise product you install in your
own datacenter or as Azure DevOps Services which is a cloud service hosted on Microsoft Azure
platform. Both versions provide the same functionality and in fact share most of the code base.
The main benefit of the hosted version is that an organization or team can get started quickly. There
is no infrastructure to provision or manage. In fact, a developer can go from zero to their first team
project in minutes, including the sign-up process. In addition, Microsoft has a three-week cadence to
release new Azure DevOps Services features and bug fixes. This means that internally, Microsoft has
adopted a Continuous Delivery (CD) approach of their own, releasing new capabilities to the service
every 3 weeks.
For more information about Azure DevOps, visit http://dev.azure.com.

Release Pipelines in Azure DevOps
The Developers may choose to use Release Pipelines within Azure DevOps to configure and
automate deployments to a variety of target environments. The Developers can model their release
processes, track approvals and sign-offs, and display release status graphically. Release Pipelines
provides a continuous deployment solution by automating the deployment process and simplifying
the management of multiple environment. It also helps to improve collaboration throughout the
process and provides release analytics and reporting.
Release Management for Visual Studio originally launched in 2009 as InRelease by InCycle Software.
InRelease version 2.0 launched in 2010 and version 3.0 in 2013. It was acquired by Microsoft in 2013
and released in November 2013. Release Management was updated for Visual Studio 2015 and is
available as a web-based UI with a new architecture and a new set of simplified concepts. In 2017 it
has been renamed to Release Pipelines
Release Pipelines use the same agent as the build server. It shares also the same set of tasks with the
build so those can be used to design a process of steps executed during a release. There are more
tasks available from the Visual Studio Marketplace. Learn more here http://bit.ly/2IVSqnq.


The DevOps Handbook

Gen Kim, Jez Humble, Patrick Debois, John Willis
https://amzn.to/2xOr6UR
Continuous Delivery
Jez Humble, David Farley
https://amzn.to/2JzhMsA
Paul M. Duvall
https://amzn.to/2xJy3GO

Quality Software
This module is about software quality and how to make sure your software is of high enough quality.
Although the first instinct is to jump to testing, this is not the only answer. Therefore, we will talk
about metrics to define and measure quality.
Then we will of course also talk about testing with its different test types, tools and strategies to
ensure a high-quality product.

Activity: More than testing
In this activity, you will discuss as a team and then with the rest of the room what you could do apart
from testing to improve the quality of your software product. There are many more opportunities to
have a positive impact on the quality of your software product than just relying on good tests. You
should make use of a combination of some of them together with a good test strategy to create a
quality strategy.
Record any interesting observations below:

How to Improve Quality
It’s hard to define an efficient quality strategy for a software product. Often there are some best
practices which then are applied to the whole product. But unfortunately there is not a “one size fits
all” strategy.
The three pillars of empiricism can be used to optimize your software quality.
Use Transparency to identify problems and areas of dissatisfaction. Then use Inspection to identify
the most important issues. In the Adaption phase create strategies to resolve these issues and start
using them. Then use Transparency again to make the impact of your changes visible and verify in
the Inspection if the change was successful and which changes could be applied with the current
view on the situation.
This will help to develop a fit-for-purpose strategy which will focus on your specific topics and will
avoid waste in areas with no or not important issues.
A good example for this is how you could work with bugs. Use them to identify opportunities to
improve your process to create high quality software. Select a bug and do a root cause analysis. Try
to go deep until you find the real problem behind the symptoms. Just saying “We should have tested
this better” is not enough. You could use the 5-Whys-Thechnique
(https://en.wikipedia.org/wiki/5_Whys).

Example:
- Why did this bug occur?
- There was a change to the data model which had an unexpected side effect.
- Why didn’t the team expect this side effect?
- Because no one knew about the change to the data model except the guy implementing it.
- Why did nobody know about it?
- Because he was working on this PBI as the only person, and we didn’t do a code review.
- Why didn’t we do a code review?
- Because we don’t have a mandatory rule for it.
- Why don’t we have code reviews mandatory?
- We see situations where it’s not helpful
You can now discuss how to handle code reviews in the future and hopefully find a way to improve
your way of building software and being able to prevent some bugs in the future by this
improvement.

Activity: Quality Metrics
In this activity, you will discuss as a team and then with the rest of the room which metrics could be
used to measure the overall quality of your software and the quality of specific areas therein.

Separating Testing From Development
Given the symptoms you are seeing, how would you advise this team with regards to their testing?

Test in Parallel With Coding
Coding and testing must be merged. In Scrum, testers are Developers. They participate in Sprint
Planning, the Daily Scrums, Sprint Review, and Sprint Retrospective. Tests are developed in parallel
to the code. For this to be possible, the planning and design discussions in Sprint Planning, and even
earlier when refining the Product Backlog, must include testing. What tests must be created to test
which features and scenarios? Tests are written in parallel to the code. They fail for quite some time
until the functionality is complete to pass the test. Tests are executed during the Sprint. Some still
fail, but the more features are implemented, the more tests pass.
1. Testing activities can start with the writing of test cases covering the new functionality just after
Sprint Planning. For this, the Developer uses her knowledge about the system gained during the
last Sprints and from collaborative discussions during this Sprint as well as from acceptance
criteria.
2. She carefully listens to those performing the coding activities for any problems or difficulties at
which time she may consider expanding the test cases in these areas.
3. As soon as possible, she runs the tests and discusses any surprises, such as discovered bugs. She
then collaborates on their removal. Where necessary, she adapts/improves the test descriptions.
4. When a PBI approaches Done, she runs the associated tests and collaborates on the fixing of any
bugs.
5. At the end of the Sprint, all test cases developed in this Sprint are executed again.
Ideally, all test cases are supported by automated tests, but depending on the available technology
and testing possibilities, they may be manual. It is also possible to develop the test cases manually
and automate them later, e.g., during a future Sprint.

Failed Testing in the Waterfall Days
The release date was fixed. Enough time for testing was planned initially. But the time planned for
development was too short. At the end of the development time, the software was far from being
usable. Testing could not start since the software was built layer by layer and/or the missing features
required changes in the base of the software. After a big effort, the software was ready just in time
for the planned release date and there was no time left for testing. The software was delivered to
the customer and he was the first tester. No surprise that he was disappointed with the quality.
But even if development would finish in time, there is a high risk of not finishing the project in time.
In fact, the test phase is not testing only as we must fix all the issues we find during testing and then
retest them and fix again if needed. To predict how long this phase will take, we would have to
predict how many bugs we will find and how long it will take to fix them, a thing that is impossible.
So, we put the phase with the highest unpredictability top the very end of our project and so we
have high risks till the very end.
Failed Testing in the Early Agile Days

In the next evolutionary step, Agile teams started to work in shorter cycles. Testing, however, was
still put off until the end of the coding. Was this better than testing only once before shipping to the
customer? It might improve the situation, but it does not address the underlying problem. In both
models, testing is not an integral part of development, but more of an afterthought.
Although tests may be based on more up-to-date requirements and test cases may become more
reusable, the testing “phase” is still abbreviated since development takes longer.

Anti-pattern: Using different Sprint types
Some teams use different types of Sprint they are either executing in parallel or there is something
like a “hardening Sprint” or “refactoring Sprint” every couple of Sprints. This is often the case if
Scrum is used with not enough change.

Acceptance Test Driven Development
As previously mentioned, during the Sprint, tests are developed in parallel with the coding effort.
They will initially fail since the tested functionality is not yet developed. Throughout the Sprint, as
more and more functionality is added, those respective acceptance tests will pass. If they don’t, then
perhaps the Developers have built the wrong thing. At the end of the Sprint, all tests pass.
The tests are added to the pile of already existing tests and are executed as often as possible. If
automated, they might run several times a day. If manual, they might be executed when
appropriate.
Note: High-performance Scrum Teams strive for automated regression tests.
For more information on how to practice Acceptance Test-Driven Development within Scrum, read
fellow Mario Cardinal’s book on Executable Specifications with Scrum https://amzn.to/3FjTpt5.

Three Types of Testing
The Applying Professional Scrum for Software Development program proposes that there exist three
broad categories of tests: development, acceptance, and exploratory. They are distinguished by their
objective:
Development
Development tests support Developers while coding. They help ensure that the Developer “builds
the thing right”. They can also be a design tool and safety harness. Development tests are most
often unit tests developed in parallel with the code. One of the most popular techniques is test
driven development (TDD). Development tests isolate parts of the system and test them
independently. This makes them fast, but when refactoring this part, they might become
superfluous.
In contrast to acceptance tests, development type tests run a few classes or one component isolated
from the system. Due to this fact, they typically run faster than acceptance tests. On the other hand,
when the according code is refactored, they need to be refactored or even thrown away quite often.
A system with thousands of development tests might therefore become hard to refactor.

Acceptance
Acceptance tests check whether new and existing functionality works for the end user. They help
ensure the Developers ”builds the right thing”. Acceptance tests have the most value because they
are connected to the requirement. You can describe not yet realized requirements as acceptance
tests.
These tests are of value for the customer since they check the requirements of the system.
Furthermore, they are of value to the Developer since they support him in developing new
functionality. That is the reason why these tests have most value: More than exploratory tests since
they are automated. More than unit tests since they cover more code and do not change that often.
There are specialized acceptance testing frameworks to automate such tests. But often, a unit
testing framework does the job as well as a specialized framework. When you are using a specialized
framework, make sure that the majority of the Developers are able to write, adapt and run these
tests. Since the tests are automated, they can run regressively: Over and over again, several times a
day.
Exploratory
The objective of these tests is mainly to find new bugs. They can cover the entire system. These tests
have to be executed manually and their description offers the explorer the possibility to adapt the
test steps according to his personal instinct of finding bugs. The completely integrated system is
used to test, but it is running in an isolated test environment: The database usually contains test
data and changes do not affect any productive system.
Exploratory testing can’t be automated:
 It is not the nature of these tests to be automated since they allow the explorer to adapt the
tests based on her intuition
 Interacting with a GUI often requires a dedicated scripting language that is known by a few
experts in the team only. Only those experts are able to write new automated tests. The
Developers may not want to learn the scripting language or are not able to run and debug those
tests.
 A GUI is not made for automation and the test results may not be trustworthy.
Yet errors found during exploratory testing can be validated in automated tests and run frequently
to ensure that fixed defects are not re-introduced into the product by accident.

Unit Tests are Development Tests
Unit testing is probably the single most important quality practice a Developer can adopt. As a
practice, unit testing has been advocated for at least thirty years. However, in the last ten years,
tooling has made the practice much more widespread. Their purpose is to check that your code does
what you intend it to and does not do what you don’t want it to. Except in rare cases, they are not
tests from a customer’s viewpoint. They do not validate scenarios and they might not have a lot of
meaning to users other than the owners of the code under test.
The concept of a unit test is straightforward: It is a test of the unit of functionality in which you write
the program, such as a method in C# or in Java.
You can have multiple unit tests for each method
 A positive test, checking that the method behaves as expected with valid input (a.k.a.
“happy path”)
 Other tests checking alternative paths through the logic to cover all relevant code blocks
 Negative tests, validating that it does not behave unexpectedly with invalid input (a.k.a.
“error path”).
As a Developer, you should write your own unit tests. You know what you intend your code to do.
You know how to validate it. Writing the unit tests ensures that you have thought this subject
through, and it provides a necessary safety net for the future when you have to maintain the code.
Unit Tests should be FIRST

Tim Ottinger and Brett Schuchert devised the FIRST mnemonic for writing effective unit tests: Fast,
Isolated, Repeatable, Self-verifying, and Timely. “FIRST” also answers the important question of
when you should write tests. For more information, visit https://bit.ly/32IPOCp.

Integrated Testing Tools in Visual Studio
The Visual Studio testing tools are designed to support developers and teams who incorporate
testing into their software development practices. Several testing tools give developers a way to
verify behavior and find errors:
 Test Explorer – lets you run unit tests and view test results by using Microsoft’s or 3rd party
frameworks
 Code coverage tools – determine the amount of code that your tests exercise
 Microsoft Fakes isolation framework – create substitute classes and methods for code that is
hard to test
 Microsoft unit test framework for C++ and native code – for the non .NET developers
CodeLens
CodeLens displays items that are related to your code without leaving the code editor. It displays
code references for classes & methods, team information, changeset information, author
information, and unit test status & in-line test execution details.

DEMO: Unit Testing in Visual Studio
Be sure to ask any questions as the instructor performs the demonstration.

Activity: What Are Your Unit Testing Practices?
Think about how you use unit testing on your team and then share with the rest of class.

Code coverage
Regardless of whether you write the tests or the code first, when you run the tests, code coverage
can be calculated and presented with the test results. Typically, you will need to choose which
binaries to instrument or sample prior to running the tests. Studying the code coverage results lets
you pinpoint any code that your tests failed to exercise. You can then consider generating a new test
for that code, or you can manually create or extend an existing test to cover it.
Code coverage is an exquisite tool for showing you which blocks of code have not been exercised by
your tests. Use code coverage to identify gaps where you need more unit tests. Do not let good code
coverage make you too confident, however. Code coverage tells you neither that your tests are good
nor that the acceptance criteria has been met. How much code coverage is enough?
The ideal code coverage would seem to be 100%, wouldn’t it? Unfortunately, this is rarely
obtainable. Frequently, there is some error-handling or integration code for which it is impractically
expensive to write unit tests. In these cases, you need to perform careful code reviews and exercise
the code in a debugger. The value returned in achieving ultra-high code coverage numbers in this
range is typically not worth the effort required.
Read Martin Fowler’s short summary on the value of test (code) coverage here:
http://bit.ly/1uzkqP8.

DEMO: Analyzing Code Coverage in Visual Studio

Good Unit Testing Practices
Tests should be trustworthy. In other words, these tests should provide the same results on every
computer and every environment. They do not have bugs and they test the right things. They find
bugs immediately after writing the buggy code.
Here are some practices for ensuring trustworthy tests:
 Rework or remove unstable tests, such as tests that sometimes pass, sometimes fail
 Eliminate duplicate tests
 Avoid conditional logic in tests: switch, if, else, for, while
 Test only one thing
 Make tests easy to run
 The result of the tests shall be independent on the test run order
 The result of the tests should be transparent to all Developers
It’s better to have a lower number of high-quality tests, than a large number of untrustworthy ones.

Create Maintainable Tests
In addition, tests should be maintainable. Having tests which are hard to maintain are a nightmare.
Developers will simply stop maintaining and fixing tests that take too long to change. Here are some
practices for ensuring maintainable tests:
 Why test private methods? If a method is worth testing, it is also worth being public
 Remove duplicate code. Move it to a setup or private helper methods used in several tests
 Avoid multiple asserts. Instead, create multiple tests or a data-driven test
Tests should also be readable. This means not just being able to read a test but also figuring out the
problem if the test seems to be wrong. Without readability, the other two pillars fall pretty quickly. A
good naming convention will go a long way. Tests shouldn’t require comments for a reader to figure
out its behavior or intent.
Follow a Naming Convention

Having 100s or 1000s of tests, Developers needs a convention in order to quickly find the area and
component that is failing. Roy Osherove provides examples of just such a convention in his Art of
Unit Testing Book by Manning.
Naming convention Examples
[MethodUnderTest]_[Given]_[Then] cmdCd_WithBacklash_ChangesToRoot()
cmdCd_WithoutParameter_PrintsCurrentDirectory()
[ServiceUnderTest]_[Given]_[Then] executeSamples_ClientIdNull_ThrowsPalAccessDeniedException(
)
executeSamples_WithOneInvalidSample_InvalidSampleIsRefused
()
[RequirementUnderTest]_[Given]_[The abort_WhileExecuting2ndSample_Aborts2ndand3rdSample()
n] bug2123_ParsingScript_MustCauseValidationError()
For more information visit http://artofunittesting.com.

Acceptance Tests
Acceptance tests interact with the system just below the GUI. These are sometimes referred to as
“subcutaneous” tests, or tests “under the skin”. Acceptance tests do not necessarily need to interact
with the system below the GUI. They may also interact with the system via the GUI.
To review, development tests focus on the method, class, and even component level. Exploratory
tests focus on the entire system end-to-end, primarily looking for bugs. Acceptance tests focus on
specific feature scenarios. They are definitely bigger that development tests in scope, and usually
smaller than exploratory tests.

Azure DevOps Test Plans
Azure DevOps test plans provides Developers with Test Case Management (TCM) capabilities. Test
plans can be used to plan, run, and track a team’s manual test cases. It allows you to create a test
plan, suites of test cases, and test cases. The test cases can range from simple ones used for
exploratory/Agile testing all the way to multi-step tests using parameterized data values.
You can use Azure DevOps test plans to help you define and manage your testing effort by using test
plans. You create a test plan and add any test suites, test cases, or configurations that you need. The
configurations are used to determine which set ups you want to use to run test suites or test cases.
 Test Plan – lets you specify what you want to test and how to run those tests. You can for
example have test plans for the various sprints and another one for regression tests.
 Test Suite – lets you group your test cases together by organizing them into a test suite hierarchy
in your test plan. Scrum Teams typically create a requirement-based suite per Product Backlog
item.
 Test Case – these are the test case work items that contain action and validation steps that a
developer can use to step through a sequence of actions in order to validate behavior.
 Test Configuration – a set of variables that specify the correct setup required for testing an
application. These variables include hardware, operating system, software, and any other
characteristics that are important to use when you run the tests. Each test configuration can
represent an entry in your test matrix.
For more information on planning and managing test plans, test cases and shared steps visit
https://bit.ly/34R3NsD.

Exploratory Testing
Often times, the most revealing bugs in a software product are discovered as the result of
unanticipated exploration of an application. To support this method of working, there are various
tools available to support these efforts. Basically, you might benefit most from a protocol describing
the steps you took prior to a failure as this is an important piece of information to replicate the
unwanted behavior.
For web-based application you can install a browser plug-in that helps exactly with that. It not only
allows you to record the steps you executed while testing but also add notes, screen shots and
screen recording. You can the create bug work items right from the plug-in containing all the
information collected during your test session. For more information visit https://bit.ly/2QGvaNP.
Another option you could use is the Steps Recorder which is a build-in tool in Microsoft Windows
which records steps on desktop applications and can create an HTML output reporting these steps.
You can find more information about the Step Recorder here: https://bit.ly/34RXKUx.

Demo: Test Planning and Exploratory Testing
In this demonstration, the instructor will show how to create a test plan, test suites, and perform
exploratory testing.

Pair Programming
Pair Programming is a practice from Extreme Programming
(http://www.extremeprogramming.org/). The basic concept behind Pair Programming is that two
people are working on the same task together on one computer at the same time. There are two
different roles in this pair:
 Navigator
The Navigator is focussing on understanding the requirement and the overall direction and
the design of the solution.
 Driver
The Driver is focussing on writing code and make it compile correctly.
In other words, the ideas of the Navigator must go through the Drivers ears, brain and hands to get
into the computer. But by no means this should be understood as everyone just doing her own job.
On the contrary, in a typical pairing session you can observe a lot of discussion, conversation and
even friendly arguing. The two roles make sure that we cover the two main perspectives in these
conversations, the requirement and overall solution perspective as well as the implementation
perspective. It is important to switch these roles frequently by defining a timebox. Pair Programming
is not one person watching the other person doing work. Both roles are actively engaged during the
whole time.
While some people would argue that this is two people doing the work of one, Pair Programming
has a lot of advantages which makes this practice beneficial for a variety of situations:
 Pair Programming is amazingly effective in sharing knowledge and harmonizing code styles.
 It creates better, more creative solutions as two brains are working together and challenge
each others’ ideas.
 The quality of the implementation and the resulting code is better, mistakes are discovered
much earlier.
 Pair Programming also helps to build better relationships between team members by
fostering respect and understanding for each other’s thinking and motives.

 Less distraction, more focus on the task at hand.
Mob Programming
Most things from Pair Programming also apply to Mob Programming which is working with three or
more people on the same task together on one computer at the same time. There is one Driver and
multiple Navigators. It is especially necessary that we have all competencies in the mob needed to
solve the current task. This might include Product Owner, people with testing skills, infrastructure
skills or designers. That helps to drastically reduce wait time and increase the flow as the mob is
working on one task at a time and there are no or little dependencies to people outside the mob. It
is the perfect format to getting things done.
Woody Zuill – Mob Programming: A Whole Team Approach: https://bit.ly/3gWT6qU.
Woody Zuill – Mob Programming and the Power of Flow: https://bit.ly/2Z6887C.

Activity: Quality is a Mindset
The Agile Testing Manifesto (http://bit.ly/2TAlOoP) describes different aspects of how testing in an
agile environment is different from classical approaches. This explains that we not only need new
tools and strategies but a different mindset to achieve this quality.
It ties back to the quote from the start slide “Quality comes from people – not from process”.


The Art of Unit Testing

Roy Osherove
https://amzn.to/2sKn4Hr
Specification by Example
Gojko Adzic
https://amzn.to/2xMV0Jr
Agile Testing
Lisa Crispin, Janet Gregory
https://amzn.to/2sBFhrk

Sprint 2
In this activity, you and your team will experience another mini-Sprint.

Considerations


work.
Considerations

Considerations


Considerations


Emergent Architecture
In traditional approaches most of the architecture decisions are made before implementation is
started. This is the moment in time when we know least about the details like dependencies,
technical challenges, performance constraints, and other functional and qualitative requirements.
In complex environments where we use Scrum, we do not know all requirements up-front, so how
can we define an architecture for our code up front? This is why we need to postpone some design
and architectural decisions and let the architecture emerge as we know more. This module describes
how a Scrum Team can handle various challenges and maximize the benefits that come with this
approach.

An Anti-Pattern for Emergent Architecture
The Winchester Mystery House is a well-known mansion in California that was under construction
continuously for nearly 40 years. It was once the personal residence of Sarah Winchester, the widow
of gun magnate William Wirt Winchester, but is now a tourist attraction. Under Winchester's day-to-
day guidance, its "from-the-ground-up" construction proceeded around-the-clock, without
interruption. The changes continued from 1884 until Ms. Winchester’s death on September 5, 1922,
at which time work immediately ceased.
The mansion is renowned for its size and utter lack of any master building plan. According to popular
belief, Winchester thought the house was haunted by the ghosts of the people who fell victim to
Winchester rifles, and that only continuous construction would appease them. There are doors and
stairways that lead nowhere, and a vast array of colors and materials were used. You can read more
here http://bit.ly/5IdJk.
In software we might finally end up with a Winchester Mystery House with doors to nowhere and
other traps. The goal of this module is to highlight these risks and to describe strategies to avoid
them while still building the architecture while building the product.

Software Architecture vs. Software Design
There are hundreds of different definitions for software architecture published and described in
books, presentations and trainings. And while one could ask about the value of defining a term, the
definition chosen for this module should help to create some interesting insights into the subject of
emergent architecture.
Software architecture is the sum of decisions

that are hard to change later
(compiled from definitions by Grady Booch, Martin Fowler, and Eoin Woods)
In this context, “hard” means that changing these decisions later might be very costly or come with
high risk, for example risk of compromising the system. Architecture decisions are a subset of all
decisions we must make regarding the structure of our code which are usually referred to as
“software design.” In other words, “all architecture is design but not all design is architecture.”
The full quote by Grady Booch says “… not all design is architecture. Architecture represents the
significant design decisions that shape a system, where significant is measured by cost of change.”
The decision for a specific UI technology is usually widespread in the client code and needs a great
effort to change later. It would classify as an architectural decision. The internal structure of a
method (its local variables and logic) is usually comparatively easy to change and therefore referred
to as design.
Both, software architecture and software design are important for the future maintainability and
cost of a product. While this module focuses on software architecture, the next module “Quality
Code” highlights important aspects of software design.

Emergent Architecture
Emergent architecture is a collection of concepts that can help make those inevitable changes easier
and less risky. It is not a specific set of patterns one should apply in a Scrum context but advocates
making decisions in a way that allows course correction later. This is especially helpful when we
don’t know about future demands and challenges, and where we continuously learn about new
opportunities, technologies and possibilities. There are two major perspectives that help in achieving
this:
1. Try to reduce the cost and risk of correcting a decision

We can use different ways to structure code and select technologies in order to solve a
problem. Some of them might be easier to change later than others. While practicing
emergent architecture, we value this and take it into consideration instead of purely
focusing on technical aspects.
Some examples of constructs that make change easier are:
a. Using an OR-Mapper so we can easily change to a different database system.
b. Building loosely coupled components which have more contained impact on the
system.
c. Extract business logic into services that make it easier to switch to a different client
technology.
d. Use component-specific datatypes that only vary locally to reduce impacts of
changing components later.
2. Decide at the Last Responsible Moment

Many decisions are made too early at the point when we know little about the problem and
its possible solutions. Postponing decisions helps to gain more insights before making the
decision. When changes in the requirements or the environment occur, they can be
accommodated. The “last responsible moment” is the moment in time where not deciding
hurts more than making an incorrect decision. There is often no set point in time where this

is true, therefore we have to think about and decide when we think the “last responsible
moment” is for each decision. We use the time until this moment to learn about the
problem at hand and to validate hypotheses. This “learning window” helps us build up
confidence in our decision by ruling out some options and strengthening others. To increase
the learning window, we want to identify those decisions that must be made as early as
possible, and those that should be decided at the last responsible moment.
Some examples for decisions taken at the last responsible moment are:
a. Evaluating different storage options before we decide on a specific vendor and
technology: the last responsible moment is the point in time where we have to
decide, or we won’t be able to implement the solution in time for our scheduled
release. However, we may be able to find ways to postpone the decision, for
example by using XML serialization as an intermediated step.
b. Designing the relational schema for a database step by step: we decide on the final
table and attribute schema for a specific area when we implement functionality that
needs it, avoiding too much up-front design. We know that we have to decide during
our implementation of features, but we can postpone the decision on a specific part
of the schema until it becomes relevant for our solution.
c. We use a container technology like Docker to buy more time to decide on a specific
cloud provider. This abstraction frees us from vendor-specific decisions. This
particular example covers both the first topic of “reducing cost and risk to correct a
decision” as well as illustrating making a decision at “the last responsible moment.”
Some decisions have to be made at the very beginning, for example deciding on the programming
language that will be used.

Activity: Emergent Architecture in action
Share real world stories from your experience about reducing risk and effort of changing a decision,
by deciding at the last responsible moment. These can be positive or negative. Listen while others
share their experience.

The Right Amount of Up-Front Work
The clear distinction we have made between software architecture and software design on a
previous slide is a good, but artificial model which helps to emphasize the goals we want to achieve
in the context of emergent architecture.
They are simply decisions that are more expensive and/or risky to change than others. Therefore, we
should balance the amount of time and work we put into making a decision with the cost and risk to
correct them (if it becomes necessary).
For a simple decision that can easily be corrected, it is not necessary to spend much time and effort
analyzing the problem and preparing to make the decision. Often it is cheaper to just decide and
change the decision later, if necessary.
In contrast, if a decision is risky and expensive to change, a certain amount of planning and
preparation is appropriate (this is illustrated by the diagonal bar on the slide).
There are two areas we want to avoid:
a. On the upper left is the area where we have to make decisions that are hard to change but
we make them with very little up-front planning. That means there is a bigger chance of
missing important aspects and taking more risks than we should.
b. On the lower right is the area where we spend too much time planning and preparing a
decision, even if the decision is easy to correct. That not only means that we are wasting
time, but we also delay the decision and therefore increase the time it needed for us to
deliver value to our customers.

Software Architecture in a Scrum Context
The Scrum Guide doesn’t describe how the Developers executes the work. This obviously includes
work on software architecture. Yet it is very important for a Scrum Team to consider its work on
software architecture. The following pages describe relevant aspects of how Scrum Teams work on
the software architecture.
Who – who is responsible for doing architectural work and how does this align with the
responsibilities of the Scrum roles?
How – how do we organize architectural work and how can we use the Scrum artifacts?
When – how do we integrate architectural work in our sprint flow and in the Scrum events?

Who – There is no Architect-Role in Scrum
The Scrum Guide doesn’t describe a software architect role. This doesn't mean that nobody is doing
architectural work in a Scrum Team. Software architecture is part of the work that is done while
developing the product. The Developers are responsible for building the increment and therefore is
also responsible for making architectural decisions. By not tying this to a specific person or role, the
shared responsibility for the subject is strengthened. Ideally all Developers are involved in making
architectural decisions and share their experience and knowledge to provide different perspectives.
If more than one Scrum Team is working on the same product, some decisions have to be taken in
agreement between all teams.
Many people apart from Developers may have an influence on software architecture. They are not
responsible for making the decisions, but the Developers should consider their opinions and insights
into account.
These are:
 Product Owner: the quality goals the Product Owner has for the product have a big
influence on architectural decisions; if security is an essential goal, this usually calls for a
different software architecture than if performance was the most important quality goal.
 Organization: the organization defines the boundaries in which the product is being
developed; these boundaries are reflected in the technical and business constraints
Developers have to respect. These include technologies, programming languages that may
be used, and others; these standards provide guidance and can have value but may at times
need to be challenged.
 Technical Experts: the expertise (and opinions) they bring to the team influences the
Developers’ solution and architectural decisions; technical experts can be internal or
external coaches that help Developers learn and use a broader set of experience for their
decisions.

 Stakeholders: Although stakeholders are represented by the Product Owner, they can have
their own specific influence on software architecture – directly through their feedback and
demands in interaction with the Developers or indirectly through their work with the
Product Owner. These are often reflected in the quality goals and Product Backlog items.
 Thought Leaders: Industry thought leaders have a big influence on trends; those trends
often define what is seen as “modern” and “good” software architecture; this influence is
not necessarily bad since those thought leaders often create new and previously unseen
perspectives that can broaden the Developers’ view on the problem and its solution.

Activity: How to Decide
There are various factors which might be taken into consideration when making architecture
decisions. Discuss which you have used in the past and which you maybe should have valued more
and see if you can find some patterns.

How – Deciding and Validating Software Architecture
The main drivers for architectural work are quality goals. These are quality objectives for the product
as defined by the Product Owner (and stakeholders) together with the Developers. Examples are
security, usability, functional correctness, therefore quality requirements are often called the “-
ilities”. An example for a selection of quality attributes can be found in the ISO 25010 (for more
information see https://en.wikipedia.org/wiki/ISO/IEC_9126 and
https://www.iso.org/obp/ui/#iso:std:iso-iec:25010:ed-1:v1:en:fig:4 ).
Depending on the most important quality attributes (the product’s quality goals) the resulting
software architecture can change. A system that is optimized for modifiability will most probably
look different from one that is optimized for performance.
Examples for quality goals defined in different areas of our work are:
 Our Product Vision describes that we will building the fastest and most easy to use platform
for searching service providers.
 If performance is a crucial product attribute, it should be part of our Key Value Indicators.
One indicator could be how many users are using our search and how often. Our hypothesis
could be that faster searches lead to more and more frequent usage.
 This might result in a Quality Goal for executing searches in less than 1 sec even if there are
more than 1 million records in our database.
 Decisions on the level of Software Architecture might include topics like database
technology, scaling approaches and service architecture.
 These architecture decisions will then impact our Software Design where we might decide
how to structure the search logic into different classes.
As always, the results of our architecture work and their impact on our quality goals can only be
measured by working software. It is therefore important to regularly (or continuously) validate
software, e.g. through fitness functions or architecture validation workshops.

Fitness functions are tests that validate quality goals and should be included in the build and
deployment pipeline for a system.
If our current software architecture and its implementation is not fit for purpose regarding our
quality goals, we have to adapt it and let it emerge further.

How – Architecture and Quality Goals - Deciding
Once a Scrum Team has clarity about the quality goals it wants to focus on, it can decide on how to
assess them and what level of quality they want to reach for. Based on the decision what the next
improvement step should focus on, the Developers decide which changes to the software
architecture might best help with this.
This could be visualized in a spider web chart and regularly be compared with the status quo. In this
example the scrum team could focus on performance efficiency as a next step.
Functional suitability
Performance
Maintainability
efficiency
Security Usability
Current Target

How – Architecture and Quality Goals - Validating
In a second step the metrics can be used to validate the impact of the architectural changes and
verify if we should revisit some of our decisions.
This hopefully leads to a better understanding of our goals and objectives, which can and should also
be fine-tuned and adapted as needed.

How – Visualizing Quality Goals
Quality goals should not only be defined but there should also be an agreement where the product
stands regarding them and where is the highest need for improvement. This might for example be a
good discussion during Sprint Review to get the perspective of different Stakeholders and how they
evaluate the level of the various quality goals. This then can lead into a discussion what next actions
would help most with improving. These actions could be adding new features, improving existing
functionality or changing software architecture and should be captured in the Product Backlog.
The increase in quality in one area could lead to a decline in another area. This is not a problem if
the Scrum Team is continuously going through this cycle of deciding and validating. This will help to
continuously balancing out the varies goals and being able to respond quickly where necessary.

Activity: How – Planning and Documentation
Discuss with your peers how to organize architectural work. Let the following questions guide you in
your discussion.
 Where would you document your quality goals?

 How would you plan architectural work?
 Where would you document architecture decisions?
 How would you balance architectural work with feature work?
 How would you balance standards vs. autonomy?
 How to figure out which decisions are “hard to change“?
Record answers below:

Activity: When – Architecture in Scrum Events
How can Scrum events help to organize architectural work? Discuss this question in class regarding
the Scrum events.
Event How is architecture considered?

Sprint Planning
Daily Scrum
Sprint Review
Sprint Retrospective
Sprint

When – No Big Design Up Front
Big Design Up Front (BDUF) is the approach in which the design is completed and perfected before
implementation starts. This is preferable when building tangible products where more is known than
unknown, such as a house or a bridge. In other words, this kind of Big Design Up-Front is fine when
the risks and costs of the design itself are low compared to the construction itself.
It is very hard to plan a software product’s evolution more than a few months ahead. The devil is in
the details, and the details are the last thing you find out. A design is validated by working software,
so it makes sense to minimize the time between design creation and design implementation.
BDUF may seem like a good idea if:
 Requirements are better understood

 Thinking things out ahead of time saves headaches
 Changes to specs are cheaper than changes to code
But it isn’t:
 Requirements aren’t well known in the first place

 Requirements change
 Developers are not able to foresee all problems (some implementation is required to flesh
out the details)
 Customers are not able to tell you what they want (only what they don’t want … after they
see it)
Architecture evolves, as does code, as the environment of your product does, as you iterate your
way through the software project. Always keep in mind these principles so that you don’t over-
architect your application during any one Sprint:
 Build at least one piece of business functionality every Sprint

 Build enough of the architecture and design to support that business functionality

 Build adequate architecture and design to meet any non-functional requirements
Every subsequent Sprint, more and more of the Architecture and design emerge, in response to
feedback and implementation of more business functionality. Although this sounds like a “make it
up as you go” approach to architecture, it is not. Teams should already understand available
patterns and practices and their pros of cons as well as an overarching vision which might be
changed if necessary.

Think in Slices Not Layers
Traditionally architects have insisted on building n-tier applications layer by layer. They might start
at the logical data model and based on it define the database with its tables and columns first. They
would then use this to drive the data access and business logic layer development. More progressive
architects would define the entities and relationships and then let an ORM tool generate the layers
automatically. Finally, the presentation and UI would be developed, once all of the “plumbing”
underneath was ready. This approached was meant to optimize the performance of the
development while breaking it down to small cohesive chunk of work.
Turns out it delayed the realization of business value. Given a standard, n-tier architecture and
assuming each layer takes two weeks to build, it would be two months before the business could
derive any value from this solution. This is because the last layer to be developed (the UI) is required
before the business could actually use the software.
Contrast this with an emergent (sliced) architecture approach in which each Sprint develop a slice of
each layer (and sometimes refactored). This ensures that just enough of each layer is implemented
in order to deliver the functionality. At the end of each two-week Sprint the customer can actually
use the software.

Getting started
Emergent architecture is not easy, but neither is software development. First, the Developers should
envision and collaborate on an architectural approach that is fit for purpose, while considering its
maintainability for changes down the road. The Developers should build in the flexibility to adapt to
reasonable changes, leveraging well-known frameworks, patterns, principles, practices. Each Sprint,
the Developers develop architecture as part of the Sprint to support their Sprint goal. Some Sprints
will be more design-heavy than others, which they should keep in mind as they make their forecasts.
Remember: all Sprints must yield at least some additional business value.
Tips
 Make smart decisions (and delay whenever possible)
 Use popular, maintainable, and testable architectures, frameworks, and patterns
 Refactor appropriately
 Test early, often, and automatically
Avoid Premature Optimization

Premature optimization is an anti-pattern where Developers optimizes the code and application
before it is needed. Developers can waste a large amount of time thinking about and designing
solutions to fix the speed of noncritical parts of their application, and these attempts at improving
the efficiency have a negative impact on maintenance. Early Optimization is often regarded as YAGNI
(You Aren't Gonna Need It). Read more at http://bit.ly/1l134WJ.

Activity: How Would You Slice This?
Consider this requirement from your Product Owner and how you would break down the work,
develop, and deliver the Increment while minimizing waste.


Adaptive Code: Agile coding with design patterns and SOLID principles
Gary McLean Hall
https://amzn.to/2Jz2zrC
Beyond Software Architecture

Luke Hohmann
https://amzn.to/2HqG9np
Growing Object-Oriented Software, Guided by Tests

Steve Freeman, Nat Pryce
https://amzn.to/2kSqAvK
Building Evolutionary Architectures

Neat Ford, Rebecca Parsons, Patrick Kua
https://amzn.to/2lOPBsi

Quality Code
Where the module “Quality Software” was all about how to ensure quality in a software product,
this module focuses on source code of high quality.
We will cover different ways to ensure high quality source code, like coding principles, patterns and
practices. We will also introduce tools for code quality and analysis or Continuous Integration
Test Driven Development as a software design practice will be covered, as well as code reviews or
refactoring.

Developing vs. Coding
A common misconception with Agile software development is that the programmer is “off the
leash”. This is not true. Agile still means accountable. Agile requires more than traditional
approaches. Every Developer is responsible for delivering a quality product. Programmers should
follow the guidelines and practices adopted by the team. Agile leaves no room for “rogue coders”,
“loners”, or “cowboys”.
Successful Scrum Teams include Developers who all enjoy building a quality product. There should
be good collaboration and communication, especially when it comes to writing code to meet
requirements. Programmers may not understand all the nuances of the business requirements. They
may also not be adept in understanding all the “edge cases” when writing automated tests and
providing test data.
Producing a quality product is the responsibility of all team members. Programmers don’t get a pass
on testing because “it’s somebody else’s job”. The team members doing the programming tasks are
just as responsible for the quality of the Increment as the team members doing the testing tasks. In
fact, programmers should be held to a higher quality standard, because they are the ones closest to
the code, its meaning, and its execution. Writing good developer tests is an attribute of a
professional Developer.

Yes, we do Scrum. And…
Scrum can be done by just following the rules laid out in the Scrum Guide. Scrum does not force you
to use certain technical practices. Yet these technical practices help Developers in constructing a
Done increment:
 Functionally complete
 Having high quality
 Delivering high value
Therefore, successful Developers typically add technical practices to their implementation of Scrum
to improve the above-mentioned criteria.
Most teams already use a version control system like SVN or Git. If not, this should be the first step
to take. After that having one automated build is a valuable asset to have for your product. And
automated tests that are executed by this automated build are the next one. Once you have this
continuous integration you can proceed to implement continuous delivery, where you test your
product quality by pushing it into test systems, later production-like systems. The final step can be
continuous Deployment where after all those checks during continuous deployment you have an
automated decision to deploy in to the productive environment.
Practices like Test Driven Development (or Acceptance Test / Behavior Driven Development), feature
toggles, A/B testing and will most likely help you on this journey to technical excellence.

Quality Code == Quality Software
Design principles are the values that you hold your design to throughout the product lifecycle. They
are guidelines between competing approaches and represent a consensus on the right approach to
take. They also become a vocabulary around which you can discuss the various approaches.
If Developers don’t apply good principles, patterns, and practices, then their velocity will be
impacted. This may not be apparent, until a few Sprints into a release. Unfortunately, by then, it may
be too late as you’ve acquired technical debt and an inventory of the wrong architecture. Ideally
teams use the Sprint Retrospective to decide if they are going in the right direction architecturally.
Design Patterns
Design patterns are an extremely powerful tool for a Developer actively engaged in any
development endeavour. Design patterns ensure that common problems are addressed via well-
known and accepted solutions. The fundamental strength of patterns rests with the fact that most
problems have likely already been encountered and solved by other individuals or teams. As such,
patterns provide a mechanism to share workable solutions between Developers and organizations.
Design patterns are recurring solutions to software design problems that you run into again and
again, during software development. These patterns are about design and interaction of objects, as
well as providing a communication platform concerning elegant, reusable solutions to commonly
encountered programming challenges. Developers should collaborate to select a pattern and, after
learning it and using it, should retrospect on it and decide if the team wants more or less of that
pattern.
For more information as well as a list of the popular design patterns visit http://bit.ly/1jf8uPP.

Acronyms
• ADT – Ask Don’t Tell (or it’s colleague TDA - Tell Don’t Ask)
• BDD - Behavior-Driven Development
• CQRS - Command Query Responsibility Segregation
• DI - Dependency Injection
• DbC - Design by Contract
• DDD - Domain-Driven Design
• DRY - Don’t Repeat Yourself
• GRASP - General Responsibility Assignment Software Patterns
• IoC - Inversion of Control
• ISP - Interface Segregation Principle
• KISS - Keep it simple, stupid or Keep it simple, silly or Keep it short and simple or Keep it
small and simple
• LSP - Liskov Substitution Principle
• OCP - Open-Closed Principle
• ORM – Object Relational Mapping
• PLP - Principle of Least Privilege
• REST - Representational State Transfer
• SoC - Separation of Concerns
• TDD - Test-Driven Development
• YAGNI - You Ain’t Gonna Need It

SOLID
SOLID is a mnemonic acronym introduced by Michael Feathers for the "first five principles" identified
by Robert C. Martin in the early 2000s that stands for five basic principles of object-oriented
programming and design. The principles, when applied together, intend to make it more likely that a
programmer will create a system that is easy to maintain and extend over time.
The principles of SOLID are guidelines that can be applied while working on software to remove code
smells by causing the programmer to refactor the software's source code until it is both legible and
extensible. It is typically used with test-driven development and is part of an overall strategy of agile
software development.
Aimless refactoring (replacing crappy code with different crappy code) has no value. Developers
should develop their own practices of quality code. SOLID provides useful practices. There are
applications using patterns for everything, even for simple if/then/else statements. Professional
Scrum Developers should find its balance and not use patterns everywhere, but only where it makes
sense.

Single Responsibility Principle
The Single Responsibility Principle (SRP) states that every class should have a single responsibility,
and that responsibility should be entirely encapsulated by the class. All its services should be
narrowly aligned with that responsibility. A “responsibility” is a reason to change and a class or
module should have one, and only one, such reason to change.

Open/Closed Principle
The Open/Closed principle states that software classes and methods should be open for extension
but closed for modification. This means that an entity can allow its behavior to be modified without
altering its source code. This is especially valuable in a production environment, where changes to
source code are very expensive because of testing, code reviews, packaging, and deploying. Code
obeying this principle doesn't change when it is extended, and therefore needs no such effort.

Dependency Inversion Principle
Most modern applications have several layers, services, and components. Each of these can be
dependent on another, such as the UI depending upon a business logic layer, or that layer depending
upon a data access layer. These dependencies, while quite common, result in tightly-coupled code
which is difficult to maintain and to isolate while testing. Dependency inversion is more of a design
approach than a pattern. Every professional software developer that values maintainable code
should know and follow this principle.
Dependency Injection
Dependency Injection (DI) is a way of doing Dependency Inversion. DI is a design pattern that allows
a choice of component to be made at run-time rather than compile time. This is helpful for
dynamically loading plugins or mock vs. real objects.

Interface Segregation Principle
The Interface-Segregation Principle (ISP) demands that no client should be forced to depend on
methods it does not use. This principle is used for clean development and intends to make software
easy-to-change. ISP keeps a system decoupled and thus easier to refactor, change, and redeploy. ISP
splits interfaces which are very large into smaller and more specific ones so that clients will only
have to know about the methods that are of interest.

Liskov Substitution Principle
The Liskov Substitution principle states that if Class2 is a subtype of Class1, then objects of type
Class1 may be replaced with objects of type Class2. In other words, objects of type Class1 may be
substituted for objects of type Class2) without altering any of the desirable properties, such as
correctness, tasks performed, etc. The principle says that you should always be able to use a base
class or interface instead of the actual implementation and still get the expected result. If you can't,
you’re breaking the principle.

Activity: Questions About Code Quality
The truth is that the design will no longer be in any design documents or UML models. It will only
reside in the code and the working software. The code tells the truth, the only truth! Therefore, it is
the code that must be cared for. Often, organizations try to rely on comprehensive documentation
and forget about the code. Their code is unreadable and hard to maintain.
Who is going to read your code? Nobody. That’s sad and not true because YOU are always reading
YOUR OWN CODE; over and over again. How many times did you wonder about the code you have
written a year ago, a month ago, a week ago, or just yesterday?
How many times did you ask yourself when reading code: “What’s this code going to do?” The code
was not readable, not understandable, and therefore not expandable or changeable. You got stuck
in a pile of unmaintainable code. If you do not keep your code clean, in other words if you let it rot,
then you are going to bring your product and team into deep problems sooner rather than later.

Clean Code
The reality is that in professional software delivery, you are responsible for cleaning up your own
code. There are no special clean-up technicians. You are cleaning the code that flows over your own
screen.
What about when you are replacing an old system? The big problem usually is to deliver the new
system in short time with all the features the old system already had. When the pressure is on, code
can rot fast. New projects do not produce cleaner code. It’s up to you to keep the code of the old
system clean so that you can replace only parts with code based on a new technology.
The Boy Scout Rule

For cleaning up your existing code, you might want to apply the Boy Scout Rule. Boy Scouts leave
their campground cleaner than they found it. And they make the world a tiny bit better each day.
The same applies to software. Do not start efforts with the goal to clean up every single piece of crap
you can find in your code. This will be most likely to fail. Instead clean up the code where you are
working on right now while implementing a new feature or fixing a bug. And do not try to make it
perfect. It is great if you manage to make it a bit better than it was before. Over time you will
achieve great improvements.
Read here more about the power of tiny improvements: https://bit.ly/3lLLmM7.

Avoid the “Broken Window” Phenomenon
This story was observed by our fellow Scrum.org trainer Peter Gfader in Sydney, Australia. One day
this car was parked in a street in a peaceful neighborhood. Many cars were parked in that street and
never one got damaged. But this car was different since it already looked wrecked and had no
number plate. Day by day, the car was damaged more and more: A mirror was ripped off, a buckle
here and there, a smashed window, etc. After a few days it was looking bad. The owner of this car
had to place a note that this car is not abandoned!
What has this story to do with Software? A lot!
What matters if we add three additional lines to a method measuring 300 lines of code? What is
wrong increasing a class’s method count from 45 to 48? Why do we need to care about good design
if we don’t even understand the design (but the unit tests tell us that we successfully added the new
functionality without breaking old functionality)? Do you see the broken windows?
Poor quality is contagious. Never allow broken windows in your code.

Code Smells
Often the deeper problem hinted at by a code smell can be uncovered when the code is subjected to
a short feedback cycle where it is refactored in small, controlled steps, and the resulting design is
examined to see if there are any further code smells that indicate the need of more refactoring.
From the point of view of a Developer charged with performing refactoring, code smells are
heuristics to indicate when to refactor, and what specific refactoring techniques to use. Thus, a code
smell is a driver for refactoring.
Determining what is and is not a code smell is often a subjective judgment, and will often vary by
language, Developer and development methodology. Fortunately, there are many tools available to
Developers to help identify code smells. We will look at those shortly.
For more information on Code Smells visit http://bit.ly/3Nnrzw.

Code Quality Support in Visual Studio
Correctness, performance, maintainability, and even elegance are all involved in creating great code.
The tools in Visual Studio can help your team develop and sustain high standards of code excellence.
Note: Testing was previously covered in the Agile Testing module.

Code Analysis
The Code Analysis tool in Visual Studio performs static code analysis on code to help developers
identify potential design, globalization, interoperability, performance, security, and a host of other
categories of potential problems. Code Analysis can be run manually at any time from within the
Visual Studio IDE, or even setup to automatically run as part of an automated build. Developers also
have the ability to configure rule sets rather than picking and choosing from one flat list of rules.
SQL Server Data Tools (SSDT) provides a similar Static Code Analysis capability, but for the code
found in SQL Server databases. Using these tools, a database developer can eliminate potential
design and naming problems and avoid performance pitfalls.
SonarQube
SonarQube (formerly Sonar) is an open source platform for Continuous Inspection of code quality.
SonarQube is a web-based application that supports more than 20 languages, including C# and
VB.NET. It scans architecture & design, duplications, unit tests, complexity, potential bugs, coding
rules, and comments. SonarQube integrates with Visual Studio and Azure DevOps. Learn more by
visiting www.sonarqube.org.

Code Metrics
The increased complexity of modern software applications also increases the difficulty of making the
code reliable and maintainable. In recent years, many software measures, known as code metrics,
have been developed that can help developers understand where their code needs rework or
increased testing. Developers can use Visual Studio to generate code metrics data that measure the
complexity and maintainability of their managed code. Code metrics data can be generated for an
entire solution or a single project.
Code metrics is a set of software measures that provide developers better insight into the code they
are developing. By taking advantage of code metrics, developers can understand which types and/or
methods should be reworked or more thoroughly tested. Developers can identify potential risks,
understand the current state of a project, and track progress during software development.
 Maintainability Index – Calculates an index value between 0 and 100 that represents the relative
ease of maintaining the code. A high value means better maintainability.
 Cyclomatic Complexity – Measures the structural complexity of the code. It is created by
calculating the number of different code paths in the flow of the program.
 Depth of Inheritance – Indicates the number of class definitions that extend to the root of the
class hierarchy. The deeper the hierarchy the more difficult it might be to understand the code’s
intent.
 Class Coupling – Measures the coupling to unique classes through parameters, local variables,
return types, method calls, generic or template instantiations, base classes, interface
implementations, fields defined on external types, and attribute decoration.
 Lines of Code – Indicates the approximate number of lines in the code. The count is based on the
IL code and is therefore not the exact number of lines in the source code file.

Code Clone Analysis
Visual Studio has historically provided tools that enabled a developer to improve code quality by
refactoring code; for example, by extracting commonly occurring functionality into a method.
However, this process depends on the developer to determine where such reusable code is likely to
occur. Different developers working on the same project may not be aware of any such refactoring,
resulting in duplicated code.
Another common phenomenon concerns the use of copy and paste; a developer may copy a chunk
of code that performs some useful task from one project or file to another. If this occurs several
times, it is possible that the same code is added to different parts of the same project. Furthermore,
if the code that is copied contains a bug, the developer has probably duplicated this bug in multiple
places. The result is code that takes longer to test and correct.
You can use the Code-Clone Analysis tool in a couple of ways. In the first scenario, the Code-Clone
Analysis tool examines your solution to look for logic that is duplicated, enabling you to factor this
code out into one or more common methods. The Code-Clone Analysis tool is intelligent—it does
not just search for identical blocks of code, it searches for semantically similar constructs by using
heuristics.
You can search through an entire solution to find all possible code clones, or you can highlight a
block of code and have the Code-Clone Analysis tool find any code that is similar. This technique is
useful if, for example, you are correcting a bug in a piece of code and you want to know whether the
same bug resulting from a similar piece of code occurs elsewhere in the project.

Demo: Code Quality Support in Visual Studio
In this demonstration, the instructor will show off a variety of tools and support in Visual Studio for
establishing and maintaining code quality. Take any notes below:

Test-Driven Development (TDD)
Test-Driven Development is a practice in which you do not write a single line of code until you have
written a test that fails in the absence of that code. Then, you write just enough code to pass the
test, and then write a new test that fails, and keep repeating the loop, refactoring the code as you
go. Advocates of TDD document that the practice forces clear requirements, catches mistakes,
enables refactoring, and removes stress. You also end up with unit tests where you didn’t have any
before.
The strongest argument in favor of TDD is that it uses tests as technical product requirements.
Because you must write a test before writing the code under test, you are forced to understand the
requirements and filter out any ambiguity in order to define the test. This process, in turn, makes
you think in small increments and in terms of reuse so that you do not write any unnecessary code.
In other words, TDD imposes a clear and atomic design, which is easier to grow and maintain.
The next argument is that TDD enables continual refactoring to keep the code clean. If you have
tests that cover 100% of the code and immediately report failing results when there are any side
effects from refactoring, you have the safety net to refactor with confidence. Indeed, the experience
of TDD is that you do much less debugging of your code because your unit tests pinpoint errors that
you would otherwise isolate only by laboriously stepping through the execution with the debugger.

The TDD Cycle
To implement TDD you will write unit tests that will test the target code prior to writing the target
code. These tests should fully test/validate the requirements. You then run the unit tests and watch
them fail, one by one, since there is no target code yet. Write the target code for each failing test –
just enough to ensure the tests pass and then rerun the unit tests.
Here are the steps that apply to most development environments:
0. Envision what you want to do.

1. Write the unit test.
2. Compile the unit test, which will fail (pre-RED).
3. Implement enough of the target code to compile.
4. Run the test and see it fail (RED).
5. Write enough code in the target to “make it pass”.
6. Run all tests and see them pass (GREEN).
7. Refactor the code and rerun all tests as required (REFACTOR).
8. Repeat to add new functionality.

DEMO: Practicing TDD in Visual Studio

TDD Leads to Changes in Behavior
To many teams, maintainability is a very important “-ility”. A study by Springer Science + Business
Media (2008) “Realizing quality improvement through Test-Driven Development” shows that TDD
improves maintainability. Developers using TDD realized 40-90% fewer defects. The “test first”
practice was a major positive factor. The most maintainable tests are small, organized, and isolated.
Download the “Realizing quality improvement through Test-Driven Development: results and
experiences of four industrial teams” report in PDF format: https://bit.ly/3FgNp4l
Common Objections to TDD

Developers, teams, and organizations have a lot of reasons why they are not practicing TDD. Most of
those reasons are not based on their own empirical evidence unfortunately. Here are some of the
more common objections we’ve heard over the years:
“It takes too much time to write the tests.” … how much does not having tests cost your
organization today in terms of debugging, re-writes, re-activations, and fixes introducing new bugs?
Having tests also gives you the confidence to refactor properly.
“It takes too long to run the tests.” … you should consider refactoring your tests, limiting the tests
you are running, or upgrading your hardware.
“My job is to write code, not tests.” … no, your job as a Developer is to deliver business value in the
form of working software. Remember that TDD is a design tool and its usage is considered a
software development activity.

“Our legacy code is impossible to test.” … this is probably true. We can only assume your legacy
code is rife with tight coupling, poor cohesion, and otherwise fragile code. This can be a chicken and
egg problem and has nothing to do with TDD, but with the legacy code itself. Statistics tell us that
70-80% of the development done today is Brownfield (legacy). You should bite the bullet, and start
introducing unit tests as soon as possible, incorporating refactoring into your ongoing development.
For more information on working effectively with legacy code, consider Michael Feathers book by
Prentice Hall:
https://amzn.to/2YjDmuT
“TDD leads to bad architecture” … only if you let it. Bad decisions lead to bad architecture.
Remember, it doesn’t take smart people to practice TDD – it takes smart people to write software.
TDD is For the Long Haul

The biggest advantages of using TDD come with time and complexity of the product being tested.
Refactoring to tested code is not a project, it is a design practice and there is no better tool to help
you sleep well than a complete set of unit tests on a large-scale system.

Build Automation
Build automation is the act of scripting or automating a variety of tasks that software developers do
in their day-to-day work.
Build automation provides many benefits:
 Accelerate the compile and link processing

 Eliminate redundant tasks
 Improve product quality
 Minimize "bad builds"
 Eliminate dependencies on key personnel
 Track a history of builds and releases for auditing or troubleshooting
 Save time and money

Azure Pipelines
Azure Pipelines is an integral part of Azure DevOps Service and Azure DevOps Server. Using Azure
Pipelines, developers can create builds that automate the downloading of source code, compiling of
the application, running of tests, performing code analysis, releasing builds to a shared folder, and
publishing data. Build results are propagated to the data warehouse for historical reporting, such as
quality trending. Azure Pipelines also enable Developers to create multi-stage release pipelines to
deploy software on different environments not only in an automated way but also provides various
manual and automated approvals.
Scalable Topology
Azure Pipelines can support many different size and types of build systems, from the very simple to
the very complex. For example, a small team working on small projects can setup a build system on a
single machine with a single agent or even use cloud-based solutions provided and maintained by
Microsoft. Larger teams building large, more complex solutions can provision multiple agents on
high-speed, dedicated machines. For more information on ways to scale out Azure DevOps build visit
https://bit.ly/3jFn8kM.
Cross-Platform Builds
Azure Pipelines can build more than just Windows, Windows Universal Platform, and ASP.NET web
apps. It can also build Java (using Maven, Gradle or other build platforms), Xcode, JavaScript (e.g.
node.js), Cordova, and many other types of apps on Windows and other platforms. You can also
build your code on different platforms like MacOs, Linux and Windows or use Docker containers to
execute your pipeline. For more information see https://bit.ly/3jFaORn.

Continuous integration refers to the practice of triggering a build upon every check-in. It has been
proven very successful for Scrum Developers in that it delivers immediate feedback on integration
errors to a Developer who has just checked in code. With most modern build automation systems,
you can set up a build for continuous integration and trigger the build from a check-in event. You can
also set additional options to allow your automated build to accumulate check-ins for a period of
time, and then execute the build. Gated check-ins are a variation on this theme, with the exception
that the check-in doesn’t occur, but actually creates a shelveset instead, runs the build using the
shelved code, and then checks-in if the build succeeds.
For more information on Continuous Integration, visit http://bit.ly/KEgGa.
Continuous Integration Builds

CI builds are important to the entire Scrum Team. They ensure that each team member’s changes
integrate with other team members’ changes. This is important when everybody checks in several
times a day. Failing the build is bad, but not that bad. It’s better to fail right away during check-in, so
that the issues are fresh in everyone’s mind. Contrast that with a nightly build that can only be
reconciled once a day. CI is all about finding and fixing problems as quickly as possible.

Continuous Feedback
Getting the right feedback at the right time from the right individuals can determine the success or
failure of a project or application. Frequent and continuous feedback from the Product Owner and
stakeholders support teams in building the experiences that will delight customers. As stakeholders
work with a solution, they understand the problem better and are able to envision improved ways of
solving it.
Note: There are various feedback tools available to software development teams. In general, these
tools are best used when the individuals are not available to provide in-person feedback.
Code Review
A code review is a simple way to assure code quality by having another Developer look at the code.
This assurance can cover multiple levels of quality. It can assure that the code works, is fit for
purpose, is absent of bugs, is absent of avoidable technical debt, is readable, meet's the team's
agreed-upon coding standards as well as the DoD. Additionally, the Developer whose code is being
reviewed can use the conversation as an opportunity to learn about the way he or she writes code.
Code reviews don't have to be a formal process. They can happen spontaneously. They also
shouldn't be despised or avoided. High-performance software development teams actually look
forward to code reviews. This is because those teams know that the code is owned collectively.
Problems and criticisms aren't directed at a single Developer, but rather are learning opportunities
for the entire team. Every code writer and code reviewer will have different perspectives, and
approaches to solving problems.

Communication Tools
Good communication within the Scrum Team is a critical success factor. So while frequent
communication throughout the day is highly valuable it can also lead to many interruptions. That
might impact the mental flow of people. A good alternative for this scenario could be asynchronous
communication. In contrast to synchronous communication asynchronous communication does not
require that sending an information and receiving it has to happen at exactly the same time. Talking
to each other is an example of synchronous communication as one cannot listen just a couple of
seconds after the speaker has finished.
Asynchronous communication often happens via chat clients like Microsoft Teams, Skype, Slack or
others. While on a first glance it might not make a lot of sense if people send messages to each other
while sitting in the same room, this can exactly help to avoid the interruptions as the reader can
consume the information on what ever time is convenient for them, e.g. after finishing a task.
Azure DevOps can integrate with almost all of those communication tools to post important
messages into the chat, e.g. when a build failed. The first team member that gets available can
consume the message and start working on the build issue. To avoid duplicated work, this person
might post to the chat that she is already checking this.

Refactoring
Code refactoring is the process of changing an application’s internal structure without modifying its
external functional behavior or existing functionality, in order to improve internal quality attributes
of the software. For example, refactoring can be used to improve code readability, simplify code
structure, change code to adhere to a given design pattern, improve maintainability, improve
performance, or improve extensibility.
In software engineering, refactoring source code means improving it without changing its overall
results and is sometimes informally referred to as “cleaning it up”. Refactoring neither fixes bugs nor
adds new functionality, though it might precede or follow either activity. Rather, it improves the
understandability of the code, changes the internal structure and design, or removes dead code.
These changes are intended to make the code easier to comprehend, more maintainable, and more
amenable to change. Refactoring is usually motivated by the difficulty of adding new functionality to
a program or fixing a bug in it.
In Scrum, refactoring is an integral part of the software development cycle: first Developers write
tests, then write code to make the tests pass, and finally refactor the code to improve its internal
consistency and clarity. Automatic unit testing helps to preserve correctness of the refactored code.
For more information, visit http://www.refactoring.com.

Refactoring Best Practices
When refactoring, remember to:
 Have a clear vision how the final code should look

 Have a set of unit tests to prove that the code still behaves as expected after the refactoring.
 Ensure that all unit tests pass before starting the refactoring
 Refactor in small steps and run the unit tests in-between.
For more information, visit http://www.refactoring.com/catalog/index.html.
Refactoring and Tests
If you have few tests, your fear of changing the code is high. If you fear (and therefore do not plan)
changes you probably do not have a lot of unit tests. Having unit tests is a prerequisite for
refactoring.
Without unit tests:
 Your refactoring becomes an adventure without happy end.

 You are not able to refactor, to adapt your code to changing requirements.
 Your code becomes legacy code very fast (legacy code as code without unit tests).
 Your code is not an asset for the company, but an obstacle in further development.

Refactoring Examples
You must absolutely test every refactoring you perform. This is easy since you have unit tests in
place already. If a problem gets introduced, the tests will immediately fail, identifying the cause and
the location in the code.
The last step in TDD is to refactor the code and re-run tests. By re-running the tests, the Developer
can be confident that refactoring is not damaging any existing functionality. The concept of
removing duplication is an important aspect of any software design.
Professional Scrum Developers should build solutions that are fit for purpose while avoiding gold
plating. Gold plating is any design or coding that is above and beyond what is absolutely necessary
for the task at hand. For example, if a PBI requires a method that calculates the sales tax for the
state of Washington and the Developer adds additional logic to handle the nearby states, that's gold
plating. The Developer may try to justify the extra coding as being required down the road, for a
future Sprint.
In order to maximize value and minimize waste, Developers should solve today's problem today and
tomorrow's problem tomorrow (in the next Sprint as it is in Scrum).

Refactoring Tools
Refactoring is the process of improving your code after it has been written by changing the internal
structure of the code without changing the external behavior of the code. Visual Studio supports
multi-project refactoring for projects that are in the same solution. All of the refactoring operations
that correct references across files correct those references across all projects of the same language.
Visual Studio provides the following C# refactoring commands on the Refactoring menu:
 Extract Method Refactoring (C#)

 Rename Refactoring (C#)
 Encapsulate Field Refactoring (C#)
 Extract Interface Refactoring (C#)
 Remove Parameters Refactoring (C#)
 Reorder Parameters Refactoring (C#)
SQL Server Data Tools (SSDT) provides support for building, debugging, maintaining, and refactoring
SQL Server databases. SSDT provides the following refactoring commands:
 Rename
 Move to Schema
 Wildcard Expansion
 Fully Qualify Name

Demo: Refactoring
In this demonstration, the instructor will demonstrate how to use the built-in tools to refactor code.
Take any notes below:

Technical Debt
Ward Cunningham created a beautiful metaphor for the hard-to-change, error-prone parts of code
when he likened it to financial debt. Technical debt prevents you from moving forward, from
profiting, from staying “in the black.” As in the real world, there’s cheap debt, debt with an interest
lower than you can make in a low-risk financial instrument. Then there’s the expensive stuff, the
high-interest credit card fees that pile on even more debt.
Technical debt obscures true progress and clouds the transparency required for empirical decision
making by the Product Owner and stakeholders. Technical debt will be paid back, either in deliberate
time spent correcting technical issues, or in loss due to shipping late or with poor quality.
Developers must carefully choose only as much work as they can do in a Sprint. They learn how
much work this is through experience. Still, a team has to employ modern engineering practices like
automated build and regression testing to accomplish much of anything. If these are not employed,
the manual work tends to overwhelm a team after only a few Sprints.

Paying Back Technical Debt
Unfortunately, there is no silver bullet to removing technical debt. Paying back technical debt must
be done Sprint by Sprint. Eat the elephant one bite at a time. Don’t ask to rewrite the product
because of technical debt – that is not what a Professional Scrum Developer would do.
At a high-level, here are the steps to follow:
1. Stop generating debt

2. Make a small payment each Sprint
3. Repeat step 2
Technical debt will always exist, but it doesn’t have to be debilitating. Here is an example of
technical debt in a healthy Scrum Team.


A Philosophy of Software Design

John Ousterhout
https://amzn.to/3b0DJ0Y
The Pragmatic Programmer

Andrew Hunt
https://amzn.to/2JxZjwK
Refactoring: Improving the Design of Existing Code

Martin Fowler
https://amzn.to/2JpzBHt

Sprint 3
In this activity, you and your team will experience another mini-Sprint.

Considerations


work.
Considerations

Considerations


Considerations


Scrum Challenges
In this module, we return to the root cause of successful Scrum: people. These are the same people
that have been trying, failing, and learning all throughout this great experiment which is Scrum.
Sprint after Sprint, you and your colleagues are starting to embrace this new way of working. It feels
different. It feels awkward. Hang in there. Through perseverance, you and your team will leave
behind your old, wasteful approaches to software delivery. Dysfunctions have surfaced and,
hopefully, have been removed. This module will help you and your fellow team members improve
your game of Scrum by helping you identify and eliminate common challenges and dysfunctions
while encouraging continuous improvement.

Common Scrum Challenges
There are many challenges facing Scrum Teams, as well as any software development teams in
general. Software delivery is a complex effort, and anyone who is not in the middle of it will have
difficulty understanding that. Even the smartest Developers will run into the dilemma of balancing
the values of Scrum against just getting something out the door.
This is the goal of this section: to address some of the more common challenges Scrum Teams are
facing and helping them make good decisions.

Getting Done
You would think that Done is when a new feature or bug fix has been deployed and is happily
running in production. I would agree. If that's the status of your PBI, then you are definitely done
with it. From Scrum's point of view, however, this is not always the case. Done doesn't necessarily
mean that the PBI is in production, but that it easily could be. This is the concept of “releasable”. In
Scrum, Done typically includes everything up to, but excluding being deployed. It's actually up to the
Developers to decide what Done means, through the DoD.
What Done doesn't mean is that the PBI has been coded but not yet tested. In Scrum all software
engineering activities, including testing, must be finished before a PBI can be considered Done. It's a
dysfunction when Developers are not able to complete their work according to the DoD. Perhaps
their definition is too stringent. Perhaps the Sprint length is too short. More likely, their Sprint length
is too long. Nothing focuses the Scrum Team like knowing it has a Sprint Review in the same week
that the Sprint starts.

Activity: What About That Dialog Window?
Here are some questions to consider during this activity.
 Is this Scrum? Why or why not?

 Should the team just fix the UI next time they are editing the project?
 Should the team change their Definition of Done?
 How should the team handle the situation?
 What if the Product Owner just doesn’t care and will never make it a priority?

Undone Work
A common problem Scrum Teams face is that of undone work. The Sprint is over, and some things
did not get Done. Maybe an entire PBI (or two) didn't get touched. More likely, however, is that a
PBI is in-progress with one or more undone tasks, code half-written, tests half-passed, the DoD not
fully adhered-to, etc. I refer to that type of undone work as unfinished. Regardless of how much
work was accomplished for a PBI, it cannot be released unless it is Done. Not only could the feature
not work correctly, but the Developers will have introduced technical debt into the product.
Regardless of the type of undone work, or its level of undone-ness, the guidance is the same:
 The PBI(s) are not demonstrated in the Sprint Review as Done work, although they can be
presented for a chance of inspection and feedback – with a disclaimer.
 The PBI(s) are moved back to the Product Backlog.
 The Product Owner will consider developing the PBI(s) in a future Sprint.
In the event that a Sprint ends with unfinished work, there may be a lot of manual effort required to
exclude the unfinished code and behavior from the rest of the Increment. Single piece flow (limiting
work in progress by swarming on a PBI) is one such approach. The Developers can just decide that
they will not advance to the next PBI in the Sprint Backlog until the prior one is done, documented,
and an installer exists, for example. For some environments, this is not practical so other, more
engineering-centric solutions are required. The two common approaches are to create a version
control branch per PBI or to use feature toggles in the application.

Feature Toggles
A feature toggle is a technique where functionality can be selectively excluded, or disabled, from a
release. These types of solutions are not new. They are also referred to as feature bits, feature flags,
and feature switches. Feature toggles allow a Scrum Team to release an Increment that has
unfinished features. These unfinished features are hidden (toggled) so they do not appear in the UI.
The actual implementation of the feature toggle can vary. Menu items can be disabled. Entries in
config files can be used. Even compiler directives can be leveraged. While these techniques can be
easily implemented by most Developers, there are some third-party libraries available to further
simplify the practice.
Ideally, the Developers will finish a partially-completed feature in an upcoming Sprint, prior to the
release. This minimizes waste and also ensures the toggled feature doesn't become long-term
technical debt in the product. Even more ideal is that the team gets better about completing its
forecasted work and doesn't need such solutions in the first place. Be careful releasing a software
product with feature toggles, as they can (by design) cause different behavior in different
deployments, which can make the process of triaging a bug very complex.

Activity: What If You Are Not Really Done?

 Should the team ship the new functionality?
 Should the team demonstrate the new functionality?
 Should the team change their Definition of Done?
 Could this behavior become contagious?
 Can the Product Owner change or renegotiate the Definition of Done?

Renegotiating Scope
In the business world things can change suddenly. Software being developed to support the business
or to sell or support a product or service can quickly become obsolete. Or, thinking about it more
optimistically, the software can be modified to take advantage of new opportunities. Regardless of
the reason for the change, a Product Owner may determine that one or more forecasted PBIs no
longer have value once the Sprint has begun. This realization can also be initiated by the Developers
as they determine that a PBI is not able to be developed to any degree that would be fit for purpose.
The term “renegotiating scope” can mean that the Developers have completed all of their forecasted
work and want to add more PBIs to their Sprint Backlog (scope increases). In the context of this
module however, I'm talking about the more challenging scenarios where the forecasted work was
not completed or has become irrelevant (scope decreases).
Canceling a Sprint
If it is determined that the Sprint Goal becomes obsolete, the Product Owner can cancel the Sprint.
In other words, the Sprint could be canceled if the Product Owner determines that there is no
chance to realize any value in any of the forecasted work being developed. For example, if a
company suddenly decides to abandon support for a particular platform, the Sprint could be
cancelled if it only contained PBIs targeting that platform. Only the Product Owner has the authority
to cancel the Sprint, but he or she can do it under the persuasion of stakeholders or others on the
Scrum Team.
When a Sprint is cancelled, any Done PBIs should be reviewed to determine if they are releasable.
The Product Owner may choose to accept the work. All undone PBIs are moved back to the Product
Backlog. They should be re-estimated if required or left to sink to the dark depths of the backlog if
they are not.

Cross-Functional Team
The Developers in Scrum are a cross-functional group of people possessing all the different skills
required to turn Product Backlog items into an Increment of releasable functionality. The Developers
need to have all the skills necessary to turn the PBIs into something that the organization defines as
Done. Team members will need to develop the skills of business analyst, designer, tester,
programmer, technical writer, etc.
It may take several Sprints for the Developers to even know what functionality it has or is required.
When Scrum was first adopted in an organization, all of the analysts, programmers, and testers were
united on the development team. Since each of them played a role in the development of the
Increment, they became known as a Developer. As self-management and collective ownership
attitudes became established, the backgrounds and titles previously held by the Developers became
blurred.

Collaboration
Software delivery is a team sport. To succeed in this sport, game after game, the team must share
the vision, divide the work, and learn from each other. In other words, they must collaborate. Even a
team of expert craftsmen (rock stars in their own right) is doomed to fail if they don't collaborate
with each other. If the striker on a soccer team had his best game ever, scoring four goals, but the
team was still beaten, they lost. The other team, with even mediocre players, probably collaborated
better.
The Agile Manifesto clearly states that while there is value in process and tools, there is more value
in interacting with individuals. This is to say that Agile software development recognizes the
importance of people and the value they bring when working together. After all, it's people who
build software, not the process or the tool. If you put bright, empowered, motivated people in a
room with no process and inadequate tools, they will still be able to get something accomplished.
Their velocity may suffer, but they will produce value. They will also inspect and adapt their
processes, looking for improvement. Conversely, if the people don't work well together, no process
or tool will fix that. A bad process can screw up a good tool, but bad people can screw up everything.

Collaborate Effectively
Collaboration means working with people. This typically means dividing the work between two or
more individuals and working together. Both the process of dividing the work and the actual
working-together with others, can require intense concentration. Getting into this productive state,
otherwise known as the flow or the zone can take time. Getting out of that state prematurely, as
with any kind of interruption, can be considered waste. The irony is that collaboration requires
interruption, and you will need to get used to it and master it.
Remember that life happens. We're all human and have a life outside of software development.
When issues emerge, be open and honest about it, and take the necessary time to get your head
right. Be appropriately transparent with the rest of your team.

Impediments
An impediment is anything keeping the team from being productive. Impediments can be
environmental, interpersonal, technical, or even aesthetic in nature. Regardless of what the
impediment is, or its size, if it's blocking the team from being productive it should be removed. Just
as the sweepers in the game of Curling keep the path of the stone free from bumps and debris, so
should members of the team keep the path of productive software delivery free of impediments.
Scrum has two formal opportunities to identify impediments: each day during the Daily Scrum and at
the end of the Sprint during the Sprint Retrospective. However, impediments can be identified at
any time during the Sprint. More importantly they can and should be removed at any time. The
problem is not finding the opportunity to identify impediments, but rather getting the Developers to
be honest about their existence.
It's common to hear software developers say that nothing's blocking them. Hearing this repeatedly
does not reflect reality and might actually be a smell of an underlying dysfunction. Developers have
a lot of work to do and can easily find something else to work on. They may not realize that
"blocking" can also mean that they are experiencing slow or non-optimal progress. Also, nobody
wants to bother others with something as depressing as an impediment. What they don't realize is
that by sharing their problems with the rest of the team, that honesty and openness will actually
invite others to help. The impediment might just disappear sooner than expected.
It’s a smell if a Scrum Team relies on their Scrum Master to remove impediments. Servant leadership
only goes so far and can be abused by the rest of the team if allowed. While Scrum Masters are
typically associated with being impediment-removers, a healthier team behavior is for the person
who identified the impediment to become the one who removes it, if possible. Don't let the words
"that's not my job" be uttered.

Splitting PBIs
If a PBI is too large to be completed in a single Sprint, it will need to be split (decomposed). For
example, if the Scrum Team has a velocity of 18 points, they should not forecast a PBI which is 21
points. Even if a team is not using velocity as a forecasting tool, they should never take on more
work than they feel they can accomplish. In either case, the PBI must be decomposed. The intricacies
of how to effectively split a PBI are beyond the scope of this chapter. Suffice to say that it's a
combination of science, art, magic, and a bit of luck at times.
It's a smell when there is an epic PBI near the top of an ordered Product Backlog. It should be
decomposed well in advance of the Sprint in which it is forecasted to be developed.

Believe the Burndown
A Sprint burndown report shows how much work remained at the end of specified intervals during a
Sprint. The source of the raw data is the work items in the Sprint Backlog. The horizontal axis shows
days in a Sprint, and the vertical axis measures the amount of work that remains to complete the
tasks in the Sprint.
A Sprint burndown graph typically displays the following pieces of data:
• The Ideal Trend line indicates an ideal situation in which the team burns down all of the effort
that remains at a constant rate by the end of the Sprint
• The In-Progress series shows how much work remains for tasks that are marked as In Progress in
a Sprint
• The To-Do series shows how much work remains for tasks that are marked as To Do in a Sprint
You can review the report to determine the progress that your team has made in a release and
answer the following questions:
• How much work remains in the Sprint?

• Is your team on track to finish all work for the Sprint?
• When will your team finish all work for the Sprint?
• How much work for the Sprint is in progress?

Unhealthy Burndowns
An unhealthy Burndown report will show one or more of the following indications:
• Actual and ideal trend line are diverging or are far apart
• The total amount of work is increasing
• Actual performance is significantly above the Ideal Trend line
• Tasks move to Done prematurely, then the reactivation shows as a bump in the burndown
• Not creating tasks for large pieces of work that come up during the Sprint
• Tasks stay “in progress” for more than two days
Consider this – how would the burndown look if each Developer takes on their own PBI and works it
diligently throughout the Sprint, getting them each 95% done. The burndown will look great,
declining toward the goal just like it should with one big exception. The remaining work is the hard
testing and integration. It’ll look great, except the testing and integration work at the end which is
very hard and risky.
Tip: Overlay the last N number of Sprint burndowns and look for patterns, dysfunctions, and
improvements.

Changing Scrum
Sometimes organizations make short term changes to Scrum to give them time to correct
deficiencies. For example, Done may not initially include regression and performance testing
because it will take several months to develop an automated testing framework. For these months,
transparency is compromised, but restored as quickly as possible after the automated testing
framework is available, and tests are running. Remember, Scrum doesn’t fail, just like Chess doesn’t
fail. You can read why in Ken Schwaber’s blog post: http://bit.ly/QZPNRZ.
ScrumAnds
Doing Scrum, and doing it properly, is only the beginning. You are “doing Scrum” if you have the
formal elements in place. Without the formal elements in place, you are not “doing Scrum”.
Improving is an option at any point on the continuum. A ScrumAnd is any number of a myriad of
elements included in or attached to the use of the Scrum framework that results in an improvement,
or a movement to the right on the chart below:
Organizations tend to overlook the scaling potential in the way Scrum is being played. Take
advantage of these options first, enjoy the cumulative effect of multiple ScrumAnds and avoid the
additional complexity that arises from volume-oriented scaling like adding people, adding teams,
adding roles, adding phases.
For more information read Gunther Verheyen’s post on the topic http://bit.ly/1tzBpS0.

Working With a Challenging Scrum Master
The Scrum Master is the person who's responsible for ensuring that the rules of Scrum are followed.
There are different ways of thinking of the Scrum Master role. One might be as a parent, because
when you get a team together, at first the team members do not know how to self-manage. They
don’t know how to work cross-functionally. They don't know how to work with a Product Owner.
They don’t know how to work within a timebox. So just like a parent, the Scrum Master is
responsible for teaching them how to do this until they know how, moving them from a relatively
immature childlike state, to a mature self-functioning team. Similarly, a Scrum Master is like a coach,
responsible for cheering them on, for being their leader, and their guide. The Scrum Master is also
like a referee ensuring that all team members follow the rules of Scrum.
The Scrum Master above and beyond anything has to enforce the rules. Many of the processes that
are used in organizations create impediments to the team's progress. It is often easier to simply give
in and accept that the organizational processes can't be changed and compromise the efficiency of
Scrum and the team's output. So, it is vital in order to keep the high productivity of Scrum that the
rules are followed precisely and kept running regardless. By doing that, everything in the
organization that is dysfunctional and gets in the way of building software regularly becomes
obvious. It is the job of the Scrum Master to remove any impediment, within or external to the team
that prevents them reaching their goal of building the functionality they forecasted at the beginning
of each Sprint.

Scrum Master Responsibilities
• Improving the lives and productivity of the Scrum Team by facilitating creativity and
empowerment and any other way possible
• Enabling close cooperation across all roles and functions and removing barriers
• Shielding the team from external interferences and removing "Impediments"
• Ensuring that the rules of Scrum are followed
• Removing any problematic barriers between Developers and the customer
• Helping the customer and Developers understand that the customer drives what functionality is
to be developed, and the Developers drive how it’s implemented
• Teaching the customer how to maximize ROI and meet their objectives through Scrum
• Improving the engineering practices and tools so each increment of functionality is releasable

Activity: How Would You Handle Roger?
 What dysfunctions exist?

 Is it ok to just start tracking actual hours for Roger?
 What if Roger explains that tracking these hours will get you paid and to “think of this as a
timesheet”?
 What if Roger next wants you to start tracking original and final estimates?
 Does Roger have authority?
 Is Roger a servant leader?

Working With a Challenging Product Owner
In addition to all of these challenges, the primary one is if the Product Owner doesn't successfully
reflect the real value/priority for the business. This is both the biggest responsibility and biggest
potential risk of the Product Owner.
Remember, the Product Owner is one person, not a committee. He or she may represent the desires
of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s
priority must convince the Product Owner. For the Product Owner to succeed, the entire
organization must respect his or her decisions. The Product Owner’s decisions are visible in the
content and ranking of the Product Backlog. No one is allowed to tell the Developers to work from a
different set of priorities, and the Developers aren’t allowed to act on what anyone else says.

Activity: What About a Complete Rewrite?
 Would you use Scrum for this project?

 Is it ok to not have a Product Backlog?
 Can the Developers elect a Product Owner
 Should the Developers create and order the Product Backlog themselves?
 Can there be any business value short of a complete rewrite?
 How should the Developers handle the situation?
 Is it ok to go around the Product Owner’s back and survey the users directly?

Working With a Challenging Stakeholder
The real issue here is who is committed to the Scrum Team and its work and accountable for
deliverables and who isn’t. The committed (a.k.a. the Developers) get to talk at the Daily Scrum.
People who are not accountable for deliverables do not get to talk. They are excess overhead for the
meeting and tend to siphon productivity away from the team.

Common Developers Dysfunctions
Leo Tolstoy told us that happy families are all alike, but that every unhappy family is unhappy in its
own way. This is true of teams that develop software as well as families. A certain amount of
dysfunction is going to exist, even in high-performance Scrum Teams, and it will always be unique.
This is because Scrum is about people, and people don't behave like highly predictable machines.
Removing a dysfunctional behavior can be difficult. Identifying it in the first place can be very
difficult, especially if you are in the middle of it, or the cause of it. Part of becoming good at Scrum, is
the ability to inspect and detect dysfunctional behavior. At first this may just be able to know when
your team isn't following the rules of Scrum, according the Scrum Guide. But that's not enough.
It may seem like the Scrum Guide has an answer for everything, but it doesn't. The complex world of
software delivery will sometimes put you and your team in the middle of two practices that conflict
with each other. Your abilities should transcend from just knowing the rules to knowing (and
applying) the principles and values of Scrum. Knowing the higher-level reasoning behind Agile
software development and why Scrum works allow you to identify and resolve such conflicts.

Making It All Work Together
You will need to learn to deal effectively with ambiguity. It should be apparent that for most
software development problem the team won’t have all the answers. Effectiveness in ambiguity is a
measure of intellectual growth and maturity. You are bound to find yourself in unusual
circumstances which cannot be solved by thinking at the practice or procedure level, but rather can
only be solved by abstracting to the “principle” level. It’s up to you to make judgments and not just
copy and paste random bits of practice.
Remember, Scrum provides a framework for more efficient product development. It is focused
around working together in small teams. As Scrum matures within the enterprise, each individual
contributor’s responsibility is to improve their game such that teams continuously work more
effectively together. We’re moving beyond the individual to the team to the enterprise. At the same
time, the individual has the opportunity for intellectual and professional growth.
A Professional Scrum Developer is more than just a good developer that knows Scrum. Professional
Scrum Developers who have gone through the program, learned the skills and how to balance them,
and how to inspect and overcome dysfunction able to navigate the realities of today’s enterprises.
By practicing Scrum according to its rules, they can transform their organization through higher
transparency and productivity.

The Developers Revisited
This is a cross-functional team with all the different skills that are needed to turn Product Backlog
items into an Increment of releasable functionality. Members will need to develop the skills of
business analyst, designer, tester, programmer, technical writer, etc. Developers need to have all the
skills necessary to turn Product Backlog items into something that the organization defines as Done.
There are often centers of excellence in software engineering organizations that group people of
unique, highly specialized skills, like usability engineering, database experts, security experts, and
system architects. When these people's skills are needed, they should become part of the Scrum
Team. That is, they're not outside experts who simply give advice but they become part of the Scrum
Team for those Sprints when they're needed to develop architecture, to develop infrastructure, or to
develop the database. They are doing the work while mentoring, monitoring and guiding the other
Developers. The key differentiator here is that they are no longer just participating. They get
involved at the start of a Sprint and are committed to achieving the Sprint Goal and delivering the
functionality that was forecasted.

Developer Role Summary
• Cross-functional
• Works with the Product Owner to select the Sprint Goal and Product Backlog items
• Forecasts the functionality that will be developed during the Sprint
• Commit to achieving the Sprint Goal and implementing the related Product Backlog items
• Has the right to do everything (within reason) to achieve the Sprint Goal
• Organizes herself and her work
• Demonstrates completed work to the Product Owner and stakeholders at the Sprint Review
• Resists shipping or even demonstrating as Done any work that is in fact undone
• Commits to continuous improvement (a.k.a. “Kaizen” in Japanese)
Developer Responsibilities
• Working on a team practicing Scrum is different than working on a traditional team
• You are now committing to achieving the Sprint Goal as a team
• You now have the autonomy to do anything (within reason) you need to hit your target
• You are working closely with people with other skill sets
• The way you communicate inside and outside the team has changed
• You are now being allowed to work rather than being instructed to work
This Means You Have a Slightly Different Role
• Team focus, not individual

• Much more face-to-face communications
• You are trusted and empowered to solve problems
• Your skills may be used in a different way (cross-functional)

Working As a Team
Scrum is about people. Why are we talking about people here? I thought this was about software
delivery. It’s because we have to work together as a team. We can do it much more effectively if we
have some knowledge and skills to help us all work together productively. Here we are introducing
you to a behavior theory that has evolved successfully over the past 50 years – focused on
interpersonal relations of small groups.
There are many frameworks and techniques out there trying to capture and categorize the attributes
of people and their interpersonal relationship. One of those (FIRO-B) is interesting because it focuses
on capturing and measuring the interpersonal needs of members of small groups. The theory is
based on the belief that when people get together in a group, there are three main interpersonal
needs they are looking to obtain: affection/openness, control, and inclusion. The instrument helps
teams measure and control their feelings when it comes to these needs. For more information, visit
http://bit.ly/Q0OYGO.
Scrum Is About People

Personality is a big component to this. People exhibit normal behaviors, problem-solving behaviors,
stress behaviors, etc. Team members should understand each other. Many frameworks exist: FIRO-B
and Myers-Briggs are examples. It’s also important to note that people may exhibit different
behavior depending on the context of their situation:
• Normal behaviors – this is how team members usually see each other
• Problem solving behaviors – mentally fully engaged, getting stuff done
• Stress behaviors – usually quite different from normal and often harder for the rest of the team
to deal with

Tuckman’s Model of Group Development
In 1965, Bruce Tuckman identified four necessary phases of group (team) development: forming,
storming, norming, and performing. Each of these phases is necessary and inevitable in order for the
team to grow, to face up to challenges, to tackle problems, to find solutions, to plan work, and to
deliver results. This model has become the basis for subsequent models.
 Forming – in the first stages of team building, the forming of the team takes place
 Storming – every group will then enter the storming stage in which different ideas compete for
consideration
 Norming – the team manages to have one goal and come to a mutual plan for the team at this
stage
 Performing – certain teams are able to function as a unit as they find ways to get the job done
smoothly and effectively without inappropriate conflict or the need for external supervision
High-performance Scrum Teams might even add another phase to the model:
 Swarming – when the team voraciously, but efficiently attacks a single Product Backlog item to
get it Done!
How To Mess Up Scrum

There are many ways that people can mess up Scrum:
• Cowboy coders aren’t team players

• Wally is the coffee drinking professional do-nothing guy in the Dilbert cartoon strip – do you
have a Wally?
• No check-in policies breed problems, hard to facilitate consistency, make it too easy to take
shortcuts
• Changing the process order creates problems, is no longer Scrum – don’t change Scrum!
• Weasel Words (see below)
• Get agreement on the Definition of Done up front and do not adapt it – don’t fool yourself
Weasel Words
Here are some examples of weasel words. These are a smell of a deeper dysfunction, such as the
individual has not yet reached the team-based mentality (or doesn’t care for it).
• “I’m 80% done” – the team should probe

• “That isn’t my job” – The team should take care of this or, if it’s an impediment, then the Scrum
Master can help mitigate
• “I’m not a tester”
• “Nothing is blocking me” – is that really the case, or did the Developer find something else to do
• “I’m done-done” (which tells me that when they said they were Done earlier, they weren’t)
It’s easy for a weak, dysfunctional team member to “blend in” and hide on a team. Don’t allow this
to happen. Take advantage of all of the inspect and adapt points that Scrum offers.
Tip: Practice HARD communication at all times. HARD stands for Honest, Appropriate, Respectful,
Direct.

Collective Ownership
Extreme Programming (XP) gave us the notion of collective code ownership. With this approach to
ownership, individual developers do not own modules, files, classes, or methods. All of those things
are owned collectively, by the entire team. Any Developer can make changes anywhere in the code
base.
Consider the alternative to collective code ownership, where each Developer owns an assembly,
namespace, or a class. On the surface it may seem like a good idea. The Developer is the expert on
this component and also the gatekeeper for all changes. But strong code ownership like this has a
tendency to block productivity. Consider the situation where two Developers (Art and Dave) are
working on separate tasks that both need to touch a common component owned by a third
Developer (Toni). Dave will have to wait while Art's functionality is coded and tested. A collective
code ownership model would allow Dave to code the feature himself. The source control tools in the
configuration management system (Azure DevOps, Git, Eclipse) would track who made what changes
to which files and enable a merge (or a rollback) to occur if there were any problems. Another
potential problem with strong code ownership pops up when refactoring. Modern refactoring tools
can do this safely, but if the file (or files) is locked then productivity is blocked again.

The Co-located Team
Scrum enables the creation of self-managing teams by encouraging co-location of all Scrum Team
members and verbal communication across all members and disciplines that are involved in the
endeavour. This does not mean that all team members should sit in a crowded room talking over
each other. Nor does it mean that the team members should disappear to cubicles after the Daily
Scrum and discontinue collaboration. There needs to be a balance so that ideas and concerns are
exchanged as well as focused work accomplished.
When forming a new Scrum Team, co-location should be a requirement. This is not just a nice-to-
have feature. It's required if you want a high-quality product and process. By co-location, I'm not
talking about being in the same time zone, city, or building. While these options are better than
some I've seen, I want the team in the same room or in adjacent rooms. The Product Owner should
be nearby too, but not necessarily in the same room. This way the face-to-face communication can
occur on-demand.
However, company politics and availability of experts sometimes require distributed teams. You are
not able to move Developers from China to Europe or vice versa. But with good communication tools
and frequent traveling you can build up trust and establish a high-performance team as well. What
you should look for are short distance distribution: You should intervene if a team is distributed
among several buildings on the same campus or in the same city. These are situation you could
change to increase the team’s performance.

Developers’ challenges
Software development teams are as much about people and culture as they are about tools and
technologies. You can have highly effective programmers with highly ineffective interpersonal skills.
There are a number of good books on the subject to help identify and improve such problems.
Recommended Reading
 The 7 Habits of Highly Effective People teaches you how to be proactive, begin with the end in
mind, put first things first, think-win-win, seek first to understand, synergize, and sharpen the
saw.
 The Five Dysfunctions of a Team teaches the dysfunctions of absence of trust, fear of conflict,
lack of commitment, avoiding accountability, and inattention to detail.
 Crucial Conversations and Crucial Confrontations teaches how to communicate best when it
matters most, such as when you are at work on a Scrum Team.

Activity: Missing a Key Team Member

 Was the team practicing Scrum? If not, how?
 Does your team have a Simon? Is it you?

Activity: Each Developer Works On Their Own PBI?

 If they used a modern version control system?
 Is it okay for one Developer to handle all facets of implementing a Product Backlog item?
 Do you believe that they can deliver business value?
 What if they are geographically dispersed?

Activity: What About Laura?

 Could the product suffer? If so, how?
 What if QA were skilled at writing unit tests, then could Laura’s idea work?
 What if Laura were a DBA writing SQL? Should she still be expected to write unit tests?

Activity: What About Nick?

 What if Nick’s preferred work hours are midnight to 8am?
 What if Nick’s capacity (commitment to this team) is only 2 hrs/day and he would therefore omit
the Daily Scrum to have more time for progress?

Activity: What About Raj?

 What if this situation is working for the team?
 What if Raj becomes a Simon (and goes walkabout)?

Activity: What About Anna?

 What if the whole team behaved like Anna?
 Can ambient (overheard) conversations have value? Is it unhealthy to avoid them?
 What if Anna’s headphones are not actually on?
 What if she uses them as her Pomodoro?
 How is Anna’s behavior any different from remote/distributed Developers?

Activity: What About Dieter?

 Does “releasable” care about politics?

Activity: What About Ryan?

 What if Ryan works for a video game software company?
 Can Ryan go to the Product Owner on his own and get more work?

Activity: How About Your Lethargic, Flaccid Team?

 Is it ok to defer the work planning and Sprint Backlog creation until the next day?
 Is it ok to give the team the day off and start the Sprint tomorrow?
 What are some motivation techniques that you could introduce here?
 Is the product doomed, or does the team just need a break?

Becoming a High-Performance Scrum Team
To this point you may have had some successes and some failures as a Scrum Team. This module will
help you strive towards being a more successful team by becoming a more successful team member.
It will also point out that failure is a learning opportunity, and not always bad. Remember, what you
do as a software developer is very difficult but ultimately it is you who are responsible for your own
learning and development.
High-performance Scrum Teams think in principles, not practices. This is to say that they know that
the complexities of software delivery will routinely place them in situations that cannot be solved by
thinking at the practice or procedure level. In other words, they won’t be able to pull out the Scrum
Guide and “look up the answer”. Rather, they can only solve these types of impediments and
dysfunctions by abstracting to the principle level of Scrum, and choosing the solution that provides
the most value with the least amount of waste while staying true to Scrum’s values of focus,
courage, openness, commitment, and respect.

Don't Be Flaccid
Scrum is a very widely adopted framework, used for managing such complex work as systems
development and delivery of product releases. When waterfall is no longer in place, however, a lot
of long-standing habits and dysfunctions have come to light. This is particularly true with Scrum,
because transparency is emphasized in Scrum projects. Some of the dysfunctions include poor
quality product and completely inadequate development practices and infrastructure. These arose
because the effects of them couldn’t be seen very clearly in a waterfall project. In Scrum, the impact
of poor quality caused by inadequate practices and tooling are seen in every Sprint. The primary
habits that hinder us are flaccid Developers and flaccid customers who believe in magic.
Attributes of a Flaccid Scrum Team

 Flaccid teams believe in magic  They throw a big book of requirements over
 They lack skills and supportive the wall
infrastructure  They avoid inevitable and unavoidable
 They are using inadequate practices and changes
tooling  They think that pressuring the team will work
 They hide behind the waterfall  They avoid sharing the risk
 Flaccid customers believe in magic  They do not inspect and provide feedback
 They do not value feedback and do not adapt

Be Transparent
Significant aspects of the development process must be visible to those responsible for the outcome.
Transparency requires those aspects be defined by a common standard, so observers share a
common understanding of what is being seen. For example:
 A common language referring to the process must be shared by all participants; and,
 A common Definition of Done
The Product Backlog and Sprint Backlog artifacts are specifically designed to maximize transparency
of key information needed to ensure Scrum Teams are successful in delivering a Done Increment.
Also, each event in Scrum is an opportunity to inspect and adapt something. These events are
specifically designed to enable critical transparency and inspection. Failure to include any of these
events results in reduced transparency and is a lost opportunity to inspect and adapt.

Inspect and Adapt
Scrum is based on empiricism which means the players make decisions based on what is. These
players must frequently inspect Scrum artifacts and their progress toward a goal (e.g., Product Goal
or Sprint Goal) to detect any undesirable variances. Good decisions can't be made if you don't have
the data. Conversely, too much data is useless unless it is acted upon. Not doing either is a
dysfunction.
For example, a Scrum Team may be very diligent about scheduling and attending their Sprint
Retrospective. They may have rich conversations and discuss the high and low points of the Sprint.
They may even identify things to do differently in the next Sprint. Multiple team members capture
this information and then do nothing with it. They have inspected, but not adapted.
If you want to know how a Scrum Team is doing, and if they are improving, ask about their Sprint
Retrospectives. The Sprint Retrospective is usually the first to suffer when times get rough. Sure, the
team may meet and discuss but they may not act on their findings. Therefore, "rough times" often is
code for "we didn't like what we discovered" or "we didn't want to improve".

Improve Your Productivity
We are taught at a young age that it is disrespectful to interrupt others. If your team is working in an
open-space team room, it's easy to see when a fellow Developer is deep in thought or in the zone.
Your instinct should be not to interrupt them. When you're working by yourself, however, it may be
harder to know when you are in the zone. Stopping to take a mental assessment may actually kick
you out of the zone. High-performance Scrum Developers know how to minimize interruptions, in
order to maximize productivity. There have been numerous books, blog posts, and white papers
written about being more productive.
Most Meetings Don’t Provide Value

If you look at most corporate meetings you will see 50-80% excess overhead. These are the meetings
that Scrum eliminates on day 1 if implemented properly. The stakeholders will claim they need to
know what is going on because it impacts their work in some way. They don't necessarily need to
know what is going on in the Daily Scrum, but they do want to see updated visual representations of
the Product Backlog and release burndowns. At the Sprint Review, they get to go to see a demo
where they can see exactly what went on, can provide their input, and can influence the next Sprint.
This is where they can provide a real contribution.
A high-functioning Scrum Team has an immune system which inspects and corrects or expels team
members who don't deliver over time. Mitigating ineffective team members needs to be handled
firmly, impartially, and impersonally. A good Scrum Master (or Scrum coach) handles this effectively,
tactfully, and persistently and can convert such dysfunctional team members into genuine
contributors.

Productivity Tips And Techniques
 Cell phone. Turn it to vibrate, turn it off, or leave it at home.
 Exit your email application. Try to only check email three times a day: at the start of your day,
after lunch, and before leaving. If you can't or don't want to turn it off, then be sure to disable all
notifications, such as Microsoft Outlook’s icons, mouse pointer changes, or audible alerts.
 Exit IM/chat client. Close the program, or at least set your status to busy. The exception to this is
if the tool is used by the Developers to share code or quick questions and feedback.
 Limit Internet searches. Developers can spend their whole day on the Internet if they are not
careful. Timebox the search and keep the scope to just researching the problem at hand.
 Just get started. Some planning is required before starting a task, but over-planning becomes the
antithesis of productivity.
 Use active listening. When your colleague is talking, you should listen to what he or she is saying,
and expect they do the same when you are talking.
 Stop fiddling. Developers can have complex software environments. These can include multiple
versions of software, one or more IDE, virtual desktops and servers, databases, frameworks,
SDKs, testing tools, installers, etc. Do yourself a favor. Get it working, script it, snapshot it, and
forget about it. Endless tweaking tends to have a diminished return on value.
 Life happens. We're all human and have a life outside of software development. When issues
emerge, be open and honest about it, and take the necessary time to get your head right. Be
appropriately transparent with the rest of your team.
 Don’t “shave the yak” which is what you are doing when you're doing some stupid, fiddly little
task that bears no obvious relationship to what you're supposed to be working on, but yet a
chain of twelve causal relations links what you're doing to the original meta-task.
Pomodoro Technique
The Pomodoro Technique is a time management method that uses a
timer to break down periods of work into 25-minute intervals called
“pomodoros” (from the Italian word for tomato) separated by breaks.
Closely related to the concept of timeboxing and iterative and
incremental development used in software design, the method has been
adopted in pair programming contexts. There are five basic steps to
implementing the technique:
 Decide on the task to be done

 Set the pomodoro (timer) to 25 minutes
 Work on the task until the timer rings; record with an x
 Take a short break (5 minutes)
 Every four "pomodoros" take a longer break (15–20 minutes)
This technique also deters interruptions because other team members can see that you are busy
(because the pomodoro still has time left on it). More importantly, they know to come back in X
minutes, and you’ll be taking a break. For this reason, your pomodoro should be placed in a visible
location on your desk. For more information visit http://bit.ly/4q8yD6.

How Can You Improve?
One thing we hope this course has made clear, is that high-performance Scrum Teams know they
can always do better. They can build a better product. They can increase its quality. They can build it
faster. They can build with less waste. They can learn new techniques that will help them improve
personally and as a team.
A big part of improving is knowing where to start. There are tactical improvements, which help the
team successfully deliver the Increment during the Sprint while not generating waste. Mastering
some of the common challenges that Scrum Teams run into will help with this. There are also
strategic improvements, such as learning to become more cross-functional and self-managing.
Teams that improve in these areas will see orders of magnitude increases in capability and
performance.

Activity: Splitting Up a High-Performance Team
 Do you think high-performance teams can be “grown” like this?

 What are the downsides to splitting the team up for this reason?
 Would it be better to split off a single team member rather than all of them?
 Would transplanted developers become like Raj (a hero)?
 Would it be better to bring other, struggling Developers to this team?

Scaling Professional Scrum with Nexus
The Nexus Framework helps teams solve common scaling challenges like reducing cross-team
dependencies, preserving team self-management and transparency, and ensuring accountability.
Nexus helps to make transparent dependencies. These dependencies are often caused by
mismatches related to:
1. Product structure: The degree to which different concerns are independently separated in
the product will greatly affect the complexity of creating an integrated product release.
2. Communication structure: The way that people communicate within and between teams
affects their ability to get work done; delays in communication and feedback reduce the flow
of work.
Nexus builds upon Scrum by enhancing the foundational elements of Scrum in ways that help solve
the dependency and collaboration challenges of cross-team work. Nexus (see Figure 1) reveals an
empirical process that closely mirrors Scrum.

Nexus extends Scrum in the following ways:
 Accountabilities: The Nexus Integration Team ensures that the Nexus delivers a valuable,
useful Integrated Increment at least once every Sprint. The Nexus Integration Team consists
of the Product Owner, a Scrum Master, and Nexus Integration Team Members.
 Events: Events are appended to, placed around, or replace regular Scrum events to augment
them. As modified, they serve both the overall effort of all Scrum Teams in the Nexus, and
each individual team. A Nexus Sprint Goal is the objective for the Sprint.
 Artifacts: All Scrum Teams use the same, single Product Backlog. As the Product Backlog
items are refined and made ready, indicators of which team will most likely do the work
inside a Sprint are made transparent. A Nexus Sprint Backlog exists to assist with
transparency during the Sprint. The Integrated Increment represents the current sum of all
integrated work completed by a Nexus.
For more information read the Nexus Guide: https://www.scrum.org/resources/online-nexus-guide

Attributes of a Professional Scrum Developer
The Scrum Guide does not provide guidance on how to develop a software product. In fact, during
the time between the Sprint Planning and the Sprint Review, the guide is intentionally vague. Other
than requiring a Daily Scrum and regular refining of the Product Backlog, there isn't much guidance
provided. In fact, the rules state that a Daily Scrum should occur, taking no longer than 15 minutes.
So, what about the other 7 hours and 45 minutes of the day? What should the Scrum Team, the
Product Owner, Scrum Master, and Developers, be doing during that time? That's the million-dollar
question. The short answer is: the Developers should be doing the right thing—even when nobody is
looking. There are many longer answers. The contents of this script will hopefully reveal several
answers to this question.


Peopleware
Tom DeMarco, Tim Lister
https://amzn.to/2Lvx2UG
Coaching Agile Teams

Lyssa Adkins
https://amzn.to/2JhG2R1
The Five Dysfunctions of a Team

Patrick Lencioni
https://amzn.to/2JxsIqL

Next Steps
Congratulations! You have reached the end of the Applying Professional Scrum for Software
Development class.
One thing that we hope has been made clear to you, is that high-performance Scrum Teams know
they can always do better. They can build a better product. They can increase its quality. They can
build it faster. They can build with less waste. They can learn new techniques that will help them
improve personally and as a team. While you may be done with class, you are far from done
improving as a Scrum Team member and software developer.

Activity: Review Your Questions
In this activity, the instructor will review any outstanding questions that may still exist in the backlog
that was started on the first day of class. He or she may enlist the help of you or your colleagues to
help answers the questions. This can serve as a review of the material.

Activity: What Makes a Good Scrum Team?
In this activity, the instructor will proctor a short discussion on the important attributes of a good
Scrum Team. Consider your experience, beyond just this class, when listing any improvements that
you or your team might need to make as the attributes are listed.
Courtesy of “Implementing Scrum” by Clark & Vizdos

Activity: What’s Your Next Move?
Write your commitments and any other notes below:

PSD-I Assessment
You will receive one free attempt for attending this course. The Scrum.org support team will email
you instructions within 5 days so be sure to add support@scrum.org to your list of accepted email
addresses. Once you receive the password, don’t delay in taking the assessment. You can learn more
about the assessment here: http://bit.ly/TUgFk1.
Here are some tips to follow:
 Read the Scrum Guide in your native language and then read it in English
(http://scrumguides.org).
 Take the Scrum Open assessment until you can achieve 100% repeatedly
(http://bit.ly/X8vJdp).
 Study for the PSD-I assessment by reading …
- The APS-SD Subject Areas (http://bit.ly/1C5GAg8).
- The APS-SD course, end-to-end.
- Any of the books referenced in the course as needed.
 Take the Developer Open assessment until you can achieve 100% repeatedly
(http://bit.ly/X8vJdp).
 Set aside a clear time to study and then take the exam.

APS-SD Subject Areas
A Professional Scrum Developer has a knowledge of Scrum and is able to work effectively on a Scrum
Team within the Scrum framework while delivering value in the form of working software. This
outline lists those general topics that a certified Professional Scrum Developer knows.
A. Process Domain
a. The Scrum Framework
a. Scrum Theory and Principles
b. Cross Functional, Self-Managing Development
B. Productivity Domain
a. Analysis
a. Emergent Architecture
b. Programming
c. Test First Development
C. Quality Domain
a. Standards
a. Testing
b. DevOps
For more information on the details of the APS-SD Subject Areas, visit http://bit.ly/1C5GAg8.

Inspect Your Knowledge – Feedback in 14 Days or Less!
Inspection in short cycles is a core concept within Scrum. Therefore scrum.org want’s to encourage
you to soon inspect your knowledge about Applying Professional Scrum for software development
by taking the PSD-I assessment. If you do it within 14 days or less after taking this class (exact date
will be mentioned in the mail you receive from scrum.org with the password for the assessment you
will get a benefit by being offered a free retake in the case you are not passing the assessment on
your first try.
Also by attending this class, you are eligible to a 40% discount for the PSM I assessment. So if you
want to get PSM I certified, please send an email to support@scrum.org for a coupon.

Scrum Guide 2020
On November 18th, 2020, a new update to the existing Scrum Guide from 2017 was released which
will clarify Scrum and will make it applicable to a broader set of challenges. Scrum will stay Scrum, so
the ideas and principles behind Scrum remain valid. The framework will be described in a slightly
different way using some different or new terms. For details, please visit
https://www.scrum.org/scrum-guide-2020.

Continue Your Learning Online
This course has (hopefully) given you some insights into what it means to professionally develop and
deliver software with Scrum. But the journey is not over yet.
Find more information and resources online to broaden and deepen your knowledge and
understanding of being a professional Scrum team member.
Scrum is a journey of continuous improvement, therefore the learning path never comes to an end.
There is always a next topic to explore, always another skill to acquire. Have fun doing so.

What Happens Next?
Although you have reached the end of the Applying Professional Scrum for Software Development
class, you still have more work to do. There are several actions you can (and should) take
immediately after class, in addition to the many practices you can perform and behaviors you can
adopt to continuously improve your game of software delivery. Here is a simple roadmap to follow:
1. Evaluate the course – feedback is incredibly important, and we take it very seriously; your
feedback helps us to continually inspect and adapt our courses to your needs:
http://scrum.org/feedback.
2. Prepare for, take, and pass the APS-SD assessment.
3. Join the elite group of other APS-SD certificate holders – if you pass the assessment then you are
certified; once you have become certified, you join the ranks of other distinguished developers;
you can view this elite list of developers here: https://www.scrum.org/certification-
list.
4. Be part of the Professional Scrum community.

Keep Calm and Scrum On!
Consider the attributes of a Professional Scrum Developer as you return to your organization. Make
a personal commitment to inspect, adapt, and improve

This class is a community effort
We deeply believe the highest value for students arises from practical relevance of the material. As
challenges and situations are vastly diverse for students, depending on products, organization,
culture, and many other factors, we depend on a diverse community of trainers frequently sharing
their experiences and the challenges of their customers and students. While worldwide consistency
of the material, messages and learning outcomes are important, the content of this class embodies
the shared knowledge and experience of Professional Scrum Trainers (PSTs) teaching this class all
over the world. Some members of this community are involved in discussions and sharing ideas
while others even actively contribute material. We would like to honor PSTs for taking the time and
effort to help making this class an amazing experience for students and helping their peers to
provide the best possible value.
Thank you!

Software in 30 Days
Ken Schwaber, Jeff Sutherland
https://amzn.to/2HoZLIB
Scrum and XP from the Trenches

Henrik Kniberg
https://amzn.to/2sE5BRJ
The Phoenix Project

Gene Kim, Kevin Behr, George Spafford
https://amzn.to/2HqVOmH

Helping people and teams solve complex problems

Professional Scrum Developer - 1 Workbook

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Professional Scrum Developer - 1 Workbook

Uploaded by

Copyright:

Available Formats

Student Workbook

Applying Professional Scrum

IMAGES AND ARTWORK

All trademarks referenced are the property of their respective owners.

This page must not be removed from the training material.

Copyright © 2022 Scrum.org Version v7.5.5 Page 3

Copyright © 2022 Scrum.org Version v7.5.5 Page 4

Copyright © 2022 Scrum.org Version v7.5.5 Page 5

Copyright © 2022 Scrum.org Version v7.5.5 Page 6

What will you learn from this course?

What will a team learn from this course?

Copyright © 2022 Scrum.org Version v7.5.5 Page 7

Copyright © 2022 Scrum.org Version v7.5.5 Page 8

Do you find more?

Copyright © 2022 Scrum.org Version v7.5.5 Page 9

Copyright © 2022 Scrum.org Version v7.5.5 Page 10

Copyright © 2022 Scrum.org Version v7.5.5 Page 11

This course is three days in duration.

Copyright © 2022 Scrum.org Version v7.5.5 Page 12

Each of the Sprints will follow this schedule:

Component Description Timebox

Copyright © 2022 Scrum.org Version v7.5.5 Page 13

Copyright © 2022 Scrum.org Version v7.5.5 Page 14

Remember the movie "The Karate Kid" (http://imdb.to/iWaz)? In the

Copyright © 2022 Scrum.org Version v7.5.5 Page 15

Mission, Vision, and Goals

Copyright © 2022 Scrum.org Version v7.5.5 Page 16

Applying Professional Scrum

Professional Scrum Master

Professional Scrum Product Owner

Other Professional Scrum Courses

Assessment and Certification

Copyright © 2022 Scrum.org Version v7.5.5 Page 17

Copyright © 2022 Scrum.org Version v7.5.5 Page 18

Copyright © 2022 Scrum.org Version v7.5.5 Page 19

Record your take-away here:

Copyright © 2022 Scrum.org Version v7.5.5 Page 20

Copyright © 2022 Scrum.org Version v7.5.5 Page 21

Write your team’s definition of Scrum here:

Copyright © 2022 Scrum.org Version v7.5.5 Page 22

Scrum is not an acronym. It is a term from the game of Rugby.

The Scrum Guide

For more information, download the official Scrum guide: http://scrumguides.org.

Copyright © 2022 Scrum.org Version v7.5.5 Page 23

Comparing Scrum and Plan-Driven Models

 We don’t know the exact outcomes at the time we begin

Copyright © 2022 Scrum.org Version v7.5.5 Page 24

Scrum vs. Waterfall

Copyright © 2022 Scrum.org Version v7.5.5 Page 25

Copyright © 2022 Scrum.org Version v7.5.5 Page 26

Copyright © 2022 Scrum.org Version v7.5.5 Page 27

Copyright © 2022 Scrum.org Version v7.5.5 Page 28

Copyright © 2022 Scrum.org Version v7.5.5 Page 29

In a nutshell, Scrum requires a Scrum Master to foster an environment where:

Copyright © 2022 Scrum.org Version v7.5.5 Page 30

Copyright © 2022 Scrum.org Version v7.5.5 Page 31

The Product Owner optimizes value of the product:

 Responsible for the product success and ROI

The Product Owner maintains the Product Backlog:

 Is accountable for the management of Product Backlog items

Copyright © 2022 Scrum.org Version v7.5.5 Page 32

 Are part of the Scrum Team

Copyright © 2022 Scrum.org Version v7.5.5 Page 33

The Scrum Master: