Scrum Fundamentals Student Handbook

Student Handbook:

Scrum Fundamentals

Class 101

Date:
Jan 11, 2010

© 2010 Gear Stream, Inc. Class 101 - Student Fundamentals Handbook V1-01_10 Page 1
A Note on Why This Scrum Workbook & Courseware is Free

Gear Stream believes that anyone interested in Scrum should have the opportunity to learn and
practice the techniques of Scrum without paying exorbitant training fees. The Scrum Alliance
has done a fantastic job of building marketplace acceptance for Scrum, but in our view has not
done enough to make basic Scrum education available to those not prepared to spend
thousands of dollars on a two day Scrum Certification Class.

We recognize that most teams will still need professional coaching and possibly formal
instruction, but that should not prevent teams from taking this material and acquiring the basic
skills and knowledge to get started. BTW, Gear Stream also delivers professional Scrum Training
and Agile Coaching services, so if you decide you want or need additional help we hope you’ll
consider us as your Agile partner.

All the material in this workbook and the associated courseware / instructor slides are available
free of charge and can be downloaded at:

http://www.gearstream.com/product‐content‐downloads.html

Please drop us a note if you find these materials helpful.

Best Regards,

Brad Murphy, Founder & CEO
Gear Stream – “We Make Software Innovation Flow”

About Gear Stream:
Gear Stream is the leading large‐scale Agile Enterprise Transformation and Agile Outsourcing
Partner in North America focused on supporting Agile team transitions that drive broad
company support for innovating the entire software and product development life‐cycle. In
contrast to others, Gear Stream’s Agile Transformation Framework integrates direct
involvement from CIO’s, PMO’s, Product Marketing, QA and Operations Leaders to insure that
team level adoption of Scrum and Agile practices are effectively supported and implemented.
Gear Stream, Inc. is headquartered in Raleigh, North Carolina and is privately held with regional
offices in New York, D.C., Atlanta, Dallas, Austin, Chicago and an Agile Development Center in
Argentina. For more information about Gear Stream visit us online at:
www.gearstream.com
1‐800‐935‐1420
Table of Contents
Course Structure ...................................................................................................... 5
Course Objectives .................................................................................................... 6
Module 1 - Introduction to Agile Methodologies ................................................. 7
MODULE 1.1 ‐ GENERAL AGILE CONCEPTS ......................................................................... 7
MODULE 1.2 – THE AGILE MANIFESTO .............................................................................. 8
MODULE 1.3 – AGILE PRINCIPLES ..................................................................................... 10
MODULE 1.4 – TRADITIONAL VS. AGILE DEVELOPMENT ................................................. 13
MODULE 1.5 – REQUISITES FOR AN AGILE CULTURE ....................................................... 17
MODULE 1.6 – MAIN AGILE METHODOLOGIES ................................................................ 20
Module 2 - Introduction to Scrum ........................................................................ 21
MODULE 2.1 – ORIGIN & HISTORY OF SCRUM ................................................................. 21
MODULE 2.2 – WHY SCRUM? ........................................................................................... 21
MODULE 2.3 – PHILOSOPHY OF SCRUM .......................................................................... 23
MODULE 2.4 – SCRUM ATTRIBUTES & CHARACTERISTICS ............................................... 25
MODULE 2.5 – INTRO TO SCRUM VOCABULARY .............................................................. 28
MODULE 2.6 – SCRUM FRAMEWORK .............................................................................. 30
MODULE 2.7 –BENEFITS OF SCRUM ................................................................................. 32
MODULE 2.8 – OVERVIEW OF THE SCRUM FLOW ........................................................... 34
Module 3 – Roles & Responsibilities in Scrum ................................................. 35
MODULE 3.1 – THE RULES OVERVIEW ............................................................................. 35
MODULE 3.2 – THE PRODUCT OWNER ............................................................................ 39
MODULE 3.3 – THE SCRUM MASTER ................................................................................ 40
MODULE 3.4 – THE TEAM (TEAM MEMBERS) .................................................................. 43
Module 4 – The Scrum Process ........................................................................... 44
MODULE 4.1 – USER STORIES ........................................................................................... 44
MODULE 4.2 – RELEASE PLANNING ................................................................................. 47
MODULE 4.3 – PRODUCT BACKLOG ................................................................................. 48
MODULE 4.3 – CONTINUED .............................................................................................. 49
MODULE 4.4 – SPRINT ...................................................................................................... 50
MODULE 4.5 – SPRINT PLANNING .................................................................................... 52
MODULE 4.6 – SPRINT BACKLOG / BURN‐DOWN CHART ................................................ 54
MODULE 4.7 – SPRINT REVIEW ........................................................................................ 58
MODULE 4.8 – DAILY SCRUM ........................................................................................... 60
MODULE 4.9 – SPRINT RETROSPECTIVE ........................................................................... 63
Bibliography / References ..................................................................................... 64

Course Structure
Day 1 Scrum Fundamentals – Concepts

8:00‐9:00 am (1 hr) Introduction to the Course
Getting Started – Round Table Discussion
9:00‐10:00 am (1 hr) Module 1: Introduction to Agile Methodologies

15 minute break

10:15‐11:15 am (1 hr) Module 2: Introduction to Scrum
11:15‐11:45 pm (.5 hr) Module 3: Roles and Responsibilities in Scrum

Lunch

1:00‐2:30pm (1.5 hrs) Module 4: The Scrum Process: User Stories
2:30‐3:30pm (1 hr) Module 4: The Scrum Process: Release Planning and
Product Backlog
15 minute Break

3:45‐4:30pm (.75 hr) Module 4: The Scrum Process: Intro to Sprints, Sprint
Planning and Sprint Backlogs
4:30‐5:00pm (0.75 hr) Module 4: The Scrum Process: Daily Scrum and Sprint
Retrospective

Day 2 Scrum Fundamentals – Getting Started

8:00‐9:30 am (1.5 hr) Review of Concepts from Day 1
Sprint Simulation Exercise

15 minute Break

9:30 – 11:30am (2 hrs) Module 5: Getting Started: Choosing the Right Projects
and Assembling the Right Team
Lunch

1:00‐2:00pm (1 hrs) Module 5: Maximizing Quality & Productivity
2:00‐2:15pm (.25 hr) Module 5: Shared Workspaces

15 minute Break

2:30‐3:30pm (1 hr) Module 5: Information Flow
3:30‐4:30pm (1 hr) Wrap‐Up and Q&A
Course Objectives

Course Main Objectives

This training course is intended (but not limited) to fulfill the following objectives:

• To provide basic knowledge of Agile Methodologies for Software Development;
• To introduce scrum rationale and its principal components and characteristics;
• To enable a general comprehension on scrum roles & responsibilities;
• To share knowledge on how to get started in a scrum effort;
• To provide references and material for ulterior individual research.

Module 1 - Introduction to Agile Methodologies

Module 1.1 - General Agile Concepts

What is Agile?

Software Development Agile Methodologies refer to a group of methodologies based on
iterative development, where requirements and solutions evolve through collaboration
between self‐organizing cross‐functional teams. The term was coined in the year 2001,
when the Agile Manifesto was formulated.

Agile methods generally promote a disciplined project management process that
encourages frequent inspection and adaptation, a leadership philosophy that
encourages teamwork, self‐organization and accountability, a set of engineering best
practices that allow for rapid delivery of high‐quality software, and a business approach
that aligns development with customer needs and company goals.

Module 1.2 – The Agile Manifesto

Manifesto for Agile Software Development

As mentioned previously, during February 2001 The Agile Manifesto was formulated.
On that occasion, at the Lodge at Snowbird ski resort in the Wasatch Mountains of Utah,
seventeen people met to talk and discuss Software Development. What emerged was
the Agile Software Development Manifesto.

Representatives from a wide variety of methodologies sympathetic to the need for an
alternative to documentation driven, heavyweight software development processes
convened.

This group of people (independent thinkers about software development, and
sometimes competitors to each other) was self named “The Agile Alliance” and agreed
on the Manifesto for Agile Software Development displayed as follows:

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

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

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

Kent Beck James Grenning Robert C. Martin
Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick

Source: http://www.agilemanifesto.org/

As it has been shown, according to the Manifesto, the prioritized values are:

 Individuals and development team interactions, more than tools and processes.

It is more important to build a good team than to build the environment.

 Developing working software, more than to achieve good documentation.

Do not produce documents unless they are immediately required to make an
important decision.

 To be collaborative with the customer, more than to negotiate a contract.

It is proposed to enable constant interactions between the customer and the
development team. This reciprocal collaboration between both parties will pace
the project rhythm and will contribute to final success.

 To be responsive to changes, more than to strictly following a project plan.

Planning should not be strict, but open and flexible. It is important to be
responsive to changes and to failures.

Module 1.3 – Agile Principles

Principles behind the Agile Manifesto

In the referred declaration, these thinkers based their thoughts in 12 (twelve) principles,
conceived to lead and guide efforts while developing software.

The Principles are shown in the following exhibit:

Se
lf-
O
rg
an
iz
ngi
Te
am
s
Bu
si
ne to
ss W
Pe ork
op To
le g e
& th
D er
ev
el
op
er
s

Principle #1:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Principle #2:
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

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

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

Principle #5
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

Principle #6
The most efficient and effective method of
conveying information to and within a development
team is face‐to‐face conversation.

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

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

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

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

Principle #11
The best architectures, requirements, and designs
emerge from self‐organizing teams.

Principle #12
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Module 1.4 – Traditional vs. Agile Development

Software Development is a discipline that everyone relates to progress, to productivity
enhancements, and to lots of really smart people working hard and generating
important benefits both to companies and to society.

But at the same time, we observe that very often Software Development Projects (SDPs)
are delayed and business results are not delivered, despite the devoted efforts of
analysts’, programmers’, testers’ and users’ talent.

Why do so many SDP’s exceed schedules, exceed budgets, face serious quality issues and
generate less business value than expected?

Let’s analyze feasible answers to this “tough” and recurrent question.

Traditional Software Development

The traditional way to develop software was based on pre‐defined processes, including
very thorough documentation and detailed initial planning intended to be strictly
followed.

This way of working emerged naturally approximately fifty years ago as an adaptation of
engineering projects (since at that point in time, engineering was the most similar
known technique to develop software), and during those first years it worked
reasonably well. It is important to bear in mind that personal computers (PCs) were
excessively expensive, and that the majority of IT investments were targeted to
hardware and equipment. For this reason, software was developed to complement that
acquired hardware, and was expected to perform very concrete business tasks.

Nowadays, SDP’s include very different challenges to those in bridge or house building.
Thus, it is pretty reasonable to conclude that traditional software development methods
are in crisis.

Traditional software development methodologies tended to be divided into very well
defined phases or workflows, commonly referred to as the Software Development
Lifecycle (SDLC). Common phases in these methodologies included:
 Feasibility/Business Analysis
 Requirements Analysis
 Design
 Coding
 Testing
 Release Management/Deployment
 Maintenance

Work from one stage was completed, and formally reviewed before moving on to the
next stage of the SDLC.

Following this traditional methodology to its conclusion, key business decisions (and
therefore key project decisions) tended to be made very early in the project’s software
development lifecycle, and were generally not reviewed and revised frequently enough
throughout the lifecycle as increased knowledge about the characteristics of the
business problem emerged – causing the SDP failures as previously discussed.

Hence, as the probability of making the wrong key decisions at the beginning of the
project is generally greater than making these key decisions “just in time” after the
project team has completed enough work to sufficiently increase their knowledge of
the problem to be solved ‐ projects were increasingly exposed to not meeting business
or project objectives and deadlines, resulting in cost overruns that are impossible to
recover.

As a solution to address these methodology problems, “agile methods” have emerged.
These new methods are applicable to both Software Development and Project
Management; the main features of both will be addressed in the following sections.

Agile Development Features

In Agile Development Projects every resource must be used in order to create the best
possible software, to meet customer’s requirements. That means that every team
member is focused only on activities and/or processes that imply value add for the
customer through the product that is being created, improved or implemented. In
addition, users or customers receive periodical working releases or prototypes of the
product, while being built. This enables an evaluation of the work, the generation of
early warnings, and the recommendation of new valuable functionality not initially
considered at the starting point (regardless if this happened because of missing specs or
because new functionality is inspired by experience at the moment of product
evaluation).

Distinction between relevant and non‐value added activities emerges through the
creation of environments with a high level of empowerment and feedback.

Empowerment consists in granting the development team autonomy to make decisions
and generates synergy that enables the Group to move forward despite habitual Project
issues and difficulties.

Constant feedback (at every level) enables incremental and adaptive development, as
well as a continual improvement in the way that teams work. This is very useful in
detecting and solving problems before they cause crisis that may impact quality, time
and/or costs of the development effort. Main feedback types happen at product,
process and code level.

Periodically the customer evaluates the software build status, ensuring that final
deliveries will meet expectations. This can be achieved through incremental
development because the product may be tested from the first weeks and months of
the project, at least regarding its basic functionalities, expected then to grow and to be
improved. For this reason it is usually said that the product has –from the beginning‐ an
internal “DNA”, similarly to human beings during their gestational process.

At the process level there are numerous retrospective meetings held where team
members comment and thoroughly discuss their “ups” (so as to repeat them and
transform them into habits) as well as their “downs”, that is to say the work not
properly done (to be reviewed and learn from it).

In addition, programmers commonly work as a team or in pairs, reviewing the code and
enabling problem solving. All of this results in higher quality products that are much
more easily maintained.

A Comparative Exhibit

Aspect Traditional Methodologies Agile Methodologies
Based on Standards followed by Heuristics emerged from code
development environment production practices
Changes Some resistance to changes Specifically prepared to changes
during the project
Adoption Externally imposed Internally adopted (by the team)
Process Control Less controlled process, with Much more controlled process,
lack of principles with many principles
Contracts Prefixed Contracts No Traditional Contracts (or at
least quite flexible ones)
Customer and Customer/Team relationship Customer interacts with
Team based in meetings only Development Team
Group Size Large Groups and probably Small Groups (<10 members) ,
distributed generally co‐located
Artifacts Many Few
Roles Many Few
Software Is Essential and it is expressed Low Emphasis
Architecture through models
Defined Required Planning and Closure only
Processes
Final Product Determined during planning Set during project
Project Costs Determined during planning Set during project
Completion Determined during planning Set during project
Date
Responsiveness Planning Only Throughout
to Environment
Knowledge Training prior to project Teamwork during project
Transfer
Probability of Low High
Success

Module 1.5 – Requisites for an Agile Culture

Requisites for Adopting an Agile Development Culture

The Agile Software Development Methodology is a new paradigm. And it is well known
that every new paradigm implies many cultural challenges both to individuals and
companies.

Every company can become more mature in how it delivers value, and will likely need to
target some new habitual goals to be succession in embracing Agile as a paradigm shift.

For this reason, we expose some habitual transformation goals that companies should
plan to embrace in order to successfully adopt an Agile Software Development
Methodology. There are seven main Transformation Goals, as follows:

Transformation Goal #1

CHANGE MANAGEMENT STYLE FROM “CONTROL AND ORDER” TO “LEADERSHIP AND
COLLABORATION”.

One Organization based on a classical vision (giving orders and implementing tight
control to its resources), can barely assume an agile project. Strict hierarchies end with
no exception in situations in which people limit themselves to do their jobs and nothing
else, without contributing with any value added (and not ad‐hoc paid activities). In an
Agile Organization, coaching and collaborative leadership will move the team to give the
best of every individual.
We do not want a boss who gives orders; we want a leader that motivates. We do not
want control, we want collaboration.


CHANGE ORGANIZATIONAL CULTURE FROM “PROCESS BASED” TO “PEOPLE BASED”.

The vision exclusively focused in Business Processes control without considering the
interactions of those processes with people who execute them has to disappear.


The vision exclusively focused in Business Processes control without considering the
interactions of those processes with people who execute them has to disappear.
Success is in the interaction among people, with processes, with technology. If we want
to be agile we must organize our company focusing on people, that are the ones who
can provide agility, and this capability of adapting to new situations, not previously
thought or modeled in a process, that is vital for survival.


CHANGE NON CRUCIAL KNOWLEDGE MANAGEMENT FROM “EXPLICIT” TO “TACIT”.

Knowledge, within an Organization, use to be always in its employees’ brains.
Organizations tend to try to keep this knowledge in an explicit way (everything, and with
the highest level of details). That leads us to the tedious activity of documenting
everything, formally and explicitly,

Precisely, this willingness of documenting everything has lead companies and
employees to limit its creativity… time is lost in documenting instead of in creating, or in
acquiring new knowledge. I prefer to document a genial idea in a paper napkin than to
have tons of documents full of superficial knowledge.

Obviously, this exposes us to a risk of serious dependency on our employees. But to be
frank, this is ALWAYS this way. Real knowledge is in people, we can try to deceive
ourselves by denying this, but it’s just this, a deception.


CHANGE COMMUNICATION FROM “FORMAL” TO “INFORMAL”.

If we want real teams, that collaborate to each other, share knowledge, and work
coordinated we must NOT be kept in rigid communication, formal, and full of
bureaucracy.


CHANGE FINAL USER ROLE FROM “IMPORTANT” TO “FUNDAMENTAL”.

In traditional methodologies, users or customers took part in the Analysis Phase, where
Systems Requirements emerged. In agile methodologies, final users are part of
development teams and are a key component of the Project. Without them, there is
simply NO Project.


CHANGE ORGANIZATION STRUCTURE FROM “HIERARCHICAL” TO “ORGANIC”.

We must pass from a bureaucratic and highly formal environment to flexible, reflexive
and participative organization that facilitates cooperation. Keep in mind that in our
brains neurons are not displayed in a “hierarchical tree” way, but in a network way.
Every person is like a neuron in the organization’s “brain”.


CHANGE “STRICT ROLES” INTO “INTERCHANGEABLE ROLES”.

During Industrial Revolution may made sense for a person to be specialist in only one
thing. But nowadays, the ability to interchange roles and functions within a same
project gives us the possibility of developing new points of view and hence face an
issue with new tools and different visions. Our employees will increase motivation,
knowledge and the Company will be more adapting.

Surely, these are seven strong hurdles / barriers to successful Agile adoption, but it is
mandatory to start breaking these barriers down if we hold any hope in successfully
adapting to new paradigms.

Module 1.6 – Main Agile Methodologies

There are several agile methodologies. Only with reference purposes, we mention
some of the most well‐known.

Adaptative Software Development (ASD)
Agile Unified Process (AUP)
Crystal Clear
Dynamic System Development Method (DSDM)
Essential Unified Process (EssUP)
Feature Driven Development (FDD)
Lean Software Development (LSD)
Open Unified Process (OPEN UP)
Extreme Programming (XP)
Scrum

Below there is a list of URLs that are useful to go deeper on these agile methodologies:

http://xprogramming.com/index.php

http://media.pragprog.com/articles/other‐published‐articles/ArtInProgramming.pdf

http://www.eclipse.org/epf/

http://www.featuredrivendevelopment.com/

http://www.dsdm.org/

Module 2 - Introduction to Scrum

Module 2.1 – Origin & History of Scrum

“The… ‘relay race’ approach to product development…may conflict with the goals of
maximum speed and flexibility. Instead, a holistic or ‘rugby’ approach—where a team
tries to go the distance as a unit, passing the ball back and forth—may better serve
today’s competitive requirements.”
Hirotaka Takeuchi and Ikujiro Nonaka, “The New Product Development Game”, Harvard
Business Review, January 1986.

Scrum as applied to product development was first referred to in "The New Product
Development Game" (Harvard Business Review 86116:137‐146, 1986) and later
elaborated in "The Knowledge Creating Company" both by Ikujiro Nonaka and Hirotaka
Takeuchi (Oxford University Press, 1995).

The case studies come from the automotive, photo machine, computer and printer
industries.

In 1991, DeGrace and Stahl, in Wicked Problems, Righteous Solutions, referred to this
approach as Scrum, a rugby term mentioned in the article by Takeuchi and Nonaka.

In the early 1990s, Ken Schwaber used an approach that led to Scrum at his company,
Advanced Development Methods (ADM). At the same time, Jeff Sutherland, John
Scumniotales, and Jeff McKenna developed a similar approach at Easel Corporation and
were the first to call it Scrum.

In 1995 Sutherland and Schwaber jointly presented a paper describing Scrum at OOPSLA
‘95 in Austin, its first public appearance. Schwaber and Sutherland collaborated during
the following years to merge the above writings, their experiences, and industry best
practices into what is now known as Scrum.
Module 2.2 – Why Scrum?

Scrum is a concept taken from Sports.

Using a sporting analogy we can compare Scrum, as a management technique, to a
scrum in a game of Rugby. In both instances a team binds together to overcome
impediments in order to reach a clearly defined target. Often both Scrums are defined
by short sharp bursts of forward progression‐in management terminology, a ‘Sprint’.
In defining Scrum we can uncover a number of characteristics:
 Ideally, Scrum is an agile, efficient process that allows for the delivery of the
highest business value in the shortest time. The business itself sets the priorities.
 Scrum is a team‐based approach to developing systems when requirements are
changing rapidly. In a world of rapid technological advances Scrum is able to
meet the resulting challenges.
 Teams self‐organize and analyse, in the everyday working environment to
determine the best way to deliver the highest priority features of the product.
 Every two weeks to a month anyone can see real working software and decide to
release it as is or continue to enhance it for another sprint.
 Scrum is scalable. It can scale from single project to entire organizations, and has
managed development for multiple interrelated products and projects with over
a thousand team members. As such it is applicable to businesses of any size.
 Scrum is a repetitive, incremental process for developing software in chaotic
environments.
Scrum consists of a series of 1 to 4 week Sprints. Each Sprint produces an ‘executable’ (a
product that is functional and could potentially be shipped to market). Between Sprints,
all stakeholders and Sprint team members (and management) meet and evaluate
progress and business requirements. These meetings lead to the creation of a ‘product
backlog’, that is, the tasks to be completed during the following sprint.
The fact that every Sprint produces a potentially releasable set of software features
results in team members feeling good about their job, and their worth as members of
the team. It goes without saying that people who work in a team environment are often
happier than those working alone. Scrum team members can see the tangible results of
their efforts every 1 to 4 weeks.
Scrum is particularly valuable in that it can be implemented in businesses of any size and
at any time during the product life cycle. Notably, the application of Scrum
methodologies can be very beneficial when applied to projects that are facing
difficulties.
Scrum maximises efficiency. It results in the best possible product being produced given
the available resources, level of quality determined by Stakeholders, and release dates.
As mentioned, a fully working, releasable set of software features are produced every 1
to 4 weeks..
Although Scrum is most closely associated with software development it has also been
involved in the production of medical and internet products and reduced production
bottlenecks in many organizations. The use of Scrum has resulted in incremental
product delivery in a very short time period.
Module 2.3 – Philosophy of Scrum

The Philosophy of Scrum

Before looking at the philosophical basis for Scrum it is necessary to understand why it
was developed. This involves a brief look at the process it seeks to replace. The still
often accepted philosophy is that the systems development process is a well understood
approach that can be planned, estimated, and successfully completed. In other words it
is a linear process. As mentioned, rapid technological advances challenge the
effectiveness and wisdom of such a strategy.
Scrum states, on the other hand, that product development is in fact a complicated, and
often unpredictable process. It takes into account the changing requirements of product
owners and has the scope to evolve as team members learn during sprints, and also to
respond quickly to feedback from consumers where necessary.
Scrum involves a loose set of activities using of a known set of tools combined with the
ingenuity of the Scrum team. This ingenuity and creativity takes place during the sprint
and results in the best possible product being developed. Such a ‘loose’ approach is
inherently risky, however monitoring minimises the potential damage that may be
caused due to taking these risks.
Scrum proposes that the following problems can occur as a result of applying the
traditional management philosophy:
 By the time the system is delivered, it is often irrelevant or requires significant
change. This occurs because environmental inputs are used only during planning.
As mentioned, the environment (technology, and end‐sure demand) is
constantly changing.
 Management believes that it can predict the cost, delivery schedule, and
functionality that will be delivered.
 Developers and project managers are forced to perpetuate an illusion of control
and predictability. They have to pretend that they can accurately plan and
predict, and then work the best way that they know how to deliver a system
based on those assumptions. They build systems one way, while pretending that
they are building in another way, and are without controls. They may also come
to realize there are better ways of doing what they had planned to do, but are
unable to follow through on this because they may deviate from the estimates
they gave at the outset of the project. This results in tension and
misunderstandings between higher levels of management and the software
management team.
Scrum starts with the premise that you cannot predict what you will deliver, when you
will deliver it, and what the quality and cost will be. Scrum does however strive to
ensure that the best possible functional product is delivered on a consistent and regular
basis. It must be recognised as the best product possible at a given time.
The reaction of many organizations is unsurprising. Directors fear chaos and a lack of
predictability. However Scrum says that in fact the current situation is already out of
control because projects are unable to adequately respond to unplanned change and
new discoveries that influence scope. In an increasingly service‐oriented environment
(a web 2.0 world whereby consumers demand a greater say in the features of a product)
organizations are struggling to maintain a feedback loop that sustains the changing
requirements of consumers. These demands must be addressed if product owners are
to maximize ROI.
The challenge is for management (the company directors) to understand the inherent
realities of software development. It is critical they come to appreciate that Scrum
insures delivery of a product or system that meets the desires of the intended users
when delivered. Without SCRUM, a product or system is potentially obsolete or out of
sync with end‐user expectations by the time it is released. In this economic climate no
business can afford to waste money by building products that continually fail to meet
consumer needs.
Scrum should be viewed as a process that allows knowledge to be created and shared as
work progresses. It is the team nature of Scrum that ensures knowledge sharing and the
creation of useful quality products.
Module 2.4 – Scrum Attributes & Characteristics

Scrum has some particular attributes and characteristics that distinguish it from other
methodologies. Below are some approaches on this topic.

Scrum enforces an empirical control process with three key elements:

FIRST LEG
TRANSPARENCY

Transparency ensures that aspects of the process that affect the outcome must be
visible to those managing the outcomes. When someone inspecting a process believes
that something is complete it must be equivalent to his or her definition of complete,
not to someone else’s. This is an important control mechanism.
SECOND LEG
FREQUENT INSPECITION

The various aspects of the process must be inspected frequently enough so that
unacceptable variances in the Scrum process can be detected. The frequency of
inspection has to take into consideration the fact that all processes are changed by the
act of inspection. The other significant factor is the skill and diligence of the people
inspecting the work results. This suggests that the inspector must be competent, both in
his or her knowledge of the product being developed, and of how the Scrum process
works (and obviously also his or her place within that process).
THIRD LEG
CONTINUOUS ADAPTATION

If the inspector determines from the inspection that one or more aspects of the process
are outside acceptable Scrum guidelines, and that the resulting product is likely to be
unacceptable, the inspector must adjust the process. Obviously, the adjustment must be
made as quickly as possible to minimise further problems. This control mechanism
reduces waste and inefficiency, a cornerstone of Scrum methodology.

Although Scrum is administered differently across different organizations there are
some commonly accepted attributes. These include:
 An agile process to manage and control development work.
 A team based approach that incrementally develops products in an environment
where requirements are often changing rapidly.
 A process that controls the chaos caused by the conflicting needs and interests
of stakeholders.
 A technique for detecting and removing impediments to the development and
delivery of products.
 A way to improve communication and maximise cooperation and team harmony.
 A methodology, which is scalable.
Scrum is scalable from single projects to entire organizations. Scrum has controlled and
organized development and implementation for multiple interrelated products and
projects with over a thousand developers and implementers.

In order to provide a more comprehensive vision of Scrum’s attributes and
characteristics, from a user point of view:

It is simple: Simplicity is an interesting value for a methodology since it facilitates its
transmission. It is simple to be told to others, it is understandable, and hence usable. It
does NOT require a large “implementation” phase and thus it is easier to find sponsors.

Focuses in visibility and ROI: For Scrum is crucial that progress be visible. There is a
clear moment in which this visibility reaches its highest expression, during the Sprint
Review, when team shows results accomplished during the last sprint. Besides, that
progress is demonstrated through working software, not through theoretical elements.
A Gantt with black bars is not real progress… working usable software is!

Clear roles & rules: It is an easy methodology, because every activity and workflows
are explicitly defined, by using clear rules. There is a specific role –the Scrum Master‐
who is responsible for complying with those rules.

Module 2.5 – Intro to Scrum Vocabulary

As many others methodologies, Scrum has its own vocabulary or terminology. In this
regard, Scrum provides a language for this common sense way of organizing, performing
and managing work.

The most important terms related to it are shown in the below list (alphabetical order).

 Abnormal Termination: The team can cancel a Sprint if they feel they are unable
to meet the Sprint Goal. Management can cancel a Sprint if external
circumstances negate the value of the Sprint Goal. If a Sprint is abnormally
terminated, the next step is to conduct a new Sprint planning meeting, where
the reason for the termination is reviewed.

 Backlog: All work to be performed in the foreseeable future, both well defined
and requiring further definition. Thus, it is a prioritized list of all work to be
completed prior to releasing a product.

 Burn down Chart: Daily progress for a sprint over the sprint’s length. The trend
of work remaining across time in a Sprint, a release, or a product. The source of
the raw data is the Sprint Backlog and the Product Backlog, with work remaining
tracked on the vertical axis and the time periods (days of a Sprint or Sprints)
tracked on the horizontal axis.

 Chicken: Someone who is interested in the project but does not have formal
Scrum responsibilities and accountabilities (is not a Team member, Product
Owner, Scrum Master).

 Daily Scrum Meeting: A short daily meeting where the team shares status.

 Done: Complete as mutually agreed to by all parties and conforming to an
organization’s standards, conventions, and guidelines. When something is
reported as “done” at the Daily Scrum or demonstrated as “done” at the Sprint
review meeting, it must conform to this agreed definition.

 Estimated Work Remaining: The number of hours that a Team member
estimates remains to be worked on any task. This estimate is updated at the end
of every day the Sprint Backlog task is worked on. The estimate is the total
estimated hours remaining, regardless of the number of people that perform the
work.

 Impediment: Anything that prevents a team member from performing work as
efficiently as possible.

 Increment: Product functionality that is developed by the Team during each
Sprint.

 Iteration: One cycle within a project. In Scrum, this cycle is usually two to four
weeks in duration, and is called a Sprint.

 Pig: Someone occupying one of the three Scrum roles (Team, Product Owner,
Scrum Master) that has made a commitment and has the authority to fulfill it.

 Product Backlog: A prioritized list of high level requirements;

 Product Owner: The person responsible for maintaining the Product Backlog by
representing the interests of the stakeholders.

 Sashimi: A slice of the whole equivalent in content to all other slices of the
whole. For the Daily Scrum, the slice of sashimi is a report that something is
done.

 Scrum Master: The person responsible for the Scrum process, making sure it is
used correctly and maximizes its benefits;

 Scrum Team: The Product Owner, Scrum Master and Team;

 Sprint: A short burst of work lasting between two to four weeks, during which an
executable and other deliverables are built by an engineering team, as indicated
by the assigned backlog.

 Sprint Backlog: The features that are well enough defined that they can be
worked on with relatively little change over the period of the Sprint they were
assigned to, and will result in a tangible, incremental deliverable.

 Team: A cross‐functional group of people responsible for managing itself to
develop the product;

 Velocity: How much product backlog effort a team can handle in one Sprint. This
can be estimated by viewing previous sprints, assuming the team composition
and sprint duration are kept constant. It can also be established on a sprint‐by‐
sprint basis, using commitment‐based planning.
Module 2.6 – Scrum Framework

The following diagram provides us a high level view of the overall Scrum framework,
from the roles involved through the activities they engage upon in the course of a Sprint
to the artifacts that they employ manage and control their progress against their Sprint
commitments.

Sprint Planning Product Backlog

Product Owner Sprint Review Sprint Backlog
Scrum Master Sprint Retrospective Burn-down Charts
Team Member Scrum Meeting Release Plan

The Scrum framework consists of a set of Scrum Teams and their associated roles: Time‐
Boxes or Ceremonies, Artifacts, and Rules.

Scrum Teams are designed to optimize flexibility and productivity; to this end, they are
self‐organizing, they are cross‐functional, and they work in iterations.

Each Scrum Team has three roles: 1) the ScrumMaster who is responsible for ensuring
the process is understood and followed; 2) the Product Owner, who is responsible for
maximizing the value of the work that the Scrum Team does; and 3) the Team, which
does the work. The Team consists of software development practitioner’s with all the
skills to turn the Product Owner’s requirements into a potentially releasable piece of the
product by the end of the Sprint.

Scrum uses time boxes to enforce a regular cadence or “rhythm” of delivery. It is this
rhythm that holds the entire Scrum framework together. Elements of Scrum that are
time‐boxed include the Release Planning Meeting, the Sprint Planning Meeting, the
Sprint, the Daily Scrum, the Sprint Review, and the Sprint Retrospective.
The main creative feature of Scrum is the ‘Sprint’. This is a period of 1 to four weeks in
which the Scrum team creates a product or an increment of the final product. Even
though it is only an increment it must have full functionality as the Product Owner may
decide to bring a product to market at the end of any given sprint.
Scrum employs four principal artifacts:
 The Product Backlog. This is a prioritised list of everything that might be needed
in the product.
 The Sprint Backlog. This is a list of tasks that will result in the Product Backlog for
one Sprint becoming a fully functional increment, which is a potentially
shippable product.
 A burn‐down. This is a measure of the remaining Backlog over time. A Release
Burn‐down measures remaining Product Backlog across the time of a release
plan.
 A Sprint Burn‐down. This measures remaining Sprint backlog items across the
time of a Sprint.

Module 2.7 –Benefits of Scrum

Successful Scrum implementations have many benefits for teams and management.
Scrum does, however, require a change from the status quo.

A well‐functioning Scrum will deliver the highest business value features first and will
avoid building features that will never be used by the customer. Since industry data
shows that about half of the software features developed are never used, development
can be completed in half the time by avoiding waste, or unnecessary work.

In most companies, development is slowed down by issues identified as impediments
during the daily meetings or planning and review meetings. With Scrum, these
impediments are prioritized and systematically removed, further increasing productivity
and quality. Well‐run Scrums achieve the Toyota effect: four times industry average
productivity and twelve times better quality.

Scrum removes management pressure from teams. Teams are allowed to select their
own work, and then self‐organize through close communication and mutual agreement
within the team on how best to accomplish the work. In a successful Scrum, this
autonomy can significantly improve the quality of life for developers and enhance
employee retention for managers.

The simple rules of Scrum allow for continual inspection, adaptation, self‐organization,
and emergence of innovation. This can produce an exciting product for the customer,
develop high team spirit and satisfying work, generate high productivity and customer
satisfaction, and achieve the market and financial goals of the company. As a result,
Scrum is being widely adopted worldwide in companies large and small, localized or
distributed, open source or proprietary, for virtually any type or size of project.

Certified Scrum Master Trainer Craig Larman notes that "Scrum is arguably the oldest
and most widely applied agile and iterative method, with an emphasis on iterative and
adaptive PM practices." He goes on to say that Scrum has been applied in thousands of
organizations and domains since the early 1990s, on projects large and small, from
Yahoo to Medtronics to Primavera, with great results. These results can only happen,
though, when leadership commits to the required changes: teams that adopt Scrum
must move away from command‐control and wishful‐thinking‐predictive management.
Larman says that Scrum can be easily integrated with practices from other iterative
methods, such as those from the Unified Process and Extreme Programming, including
test‐driven development, agile modeling, use cases, user stories, and so forth. Larman
concludes, "On the surface, Scrum appears to be simple, but its emphasis on continuing
inspect‐adapt improvement cycles and self‐organizing systems has subtle implications."

Why Scrum Is Powerful

 Focus is on team's work, and team's work only
 Daily communication of status occurs
 Enables low‐overhead empirical management
 Makes impediments visible (Someone is willing to make decisions and remove
impediments real‐time).

The following diagram extracted from material in the book ‘Scaling Software Agility’,
reflects the paradigm shit that occurs when moving from waterfall to an agile software
development practices.

Running a project with good controls is like driving a sport car through a sharp curve.
The constant, immediate feedback lets you control the car and maximize the speed while
controlling the risk. The small teams used in a Scrum project are like top quality
components in a sports car. When you respond to a measurement, the effect is immediate
and appropriate.
Module 2.8 – Overview of the Scrum Flow

As a closing of Module 2, the following illustration provides an overview of the Scrum
Process.

Vision
Reflect &
Reprioritize
Backlog

It can be seen, in a graphical way, the flow of information that will be treated in Module 5.
Module 3 – Roles & Responsibilities in Scrum

Module 3.1 – The Rules Overview

One of Pigs and Chickens…

Note: This cartoon and others that will be used during this Student Guide are taken from
http://www.implementingscrum.com/section/blog/cartoons/

Why “Chickens” and “Pigs”?

The story depicted above, as weird as it is, helps explain two of the main types of people
or roles in Scrum. The basic premise of the Chicken and the Pig can be seen from the
cartoon example above.

Here is an easy definition of the Chickens versus Pigs.

A Pig is someone who has skin in the game. One famous author, called Mike Cohn,
refers to the people in that role as, “Having their Bacon on the line.”

Pig roles are considered core team members. Performers. People who “do” work.

A Chicken is someone who has something to gain by the Pigs performing, but in the end,
really do not contribute day to day to “getting things done.” Their “eggs” are a
renewable resource, and many get laid (eggs that is).

Usually, the following question arises: “Can I be a Pig and Chicken at the same time?”
No. You cannot be a Pig and a Chicken at the same time.

This is something to be worked with middle managers who struggle with this on a daily
basis. The concept takes coaching and constant [gentle] reminders that they cannot be a
Pig/Chicken. Some people call this a Pigskin… and it is something you do not want to
see in any organization!

This distinction between both types of roles is very important in Scrum. It must always
be clear who is committed and who is only involved. Who is responsible for the ROI,
and who is interested in ROI but it is not responsible for it.

Scrum Roles

This story help us think of the Roles within a Scrum Project: For the chicken, only a
contribution is required, while for a Pig a Total commitment is needed.

Pigs are accountable for the Project’s Outcome, and Chickens that are going to be
consulted on the Project are informed of its progress.

A successful project needs both Pigs and Chickens, and on their empowerment, and on
the Pigs commitment and the Chickens involvement is sustained the Project’s results.


We can then start by identifying which are the teams that will be fully committed on the
development and result of the Project, the “Pig” roles.

“PIG” ROLES

The Product Owner represents the voice of the customer. He/she ensures that the
Scrum Team works with the "right things" from a business perspective. The Product
Owner writes customer‐centric items (typically user stories), prioritizes them and then
places them in the product backlog.

Scrum is facilitated by a Scrum Master, whose primary job is to remove impediments to
the ability of the team to deliver the sprint goal. The Scrum Master is not the leader of
the team (as the team is self‐organizing) but acts as a buffer between the team and any
distracting influences. The Scrum Master ensures that the Scrum process is used as
intended. The Scrum Master is the enforcer of rules. A key part of the Scrum Master's
role is to protect the team and keep them focused on the tasks in hand. The Scrum
Master is NOT responsible for the transition from traditional methods of working to
Scrum or the implementation of Scrum.

The team has the responsibility to deliver the product. A team is typically made up of 5–
9 people with cross‐functional skills who do the actual work (design, develop, test,
technical communication, etc.).

“CHICKEN” ROLES

Chicken roles are not part of the actual Scrum process, but must be taken into account.
They are people for whom the software is being built.

STAKEHOLDERS

For instance, customers, vendors. These are the people who enable the project and for
whom the project will produce the agreed‐upon benefit[s], which justify its production.
They are only directly involved in the process during the sprint reviews.

People who will set up the environment for the product development organizations.

Module 3.2 – The Product Owner

The Product Owner is the first responsible of the Project from the Stakeholders
perspective.

His key responsibilities are:

 Define the features of the product
 Decide on release date and content
 Be responsible for the profitability of the product (ROI)
 Prioritize features according to market value
 Adjust features and priority every iteration, as needed
 Accept or reject work results

The main activity of the product Owner is to proceed with the first of the Scrum
ceremonies: The Planning (further described below).

Focusing on ROI
The Product Owner’s focus is return on investment (ROI).

The Product Backlog provides the Product Owner with a powerful tool for directing the
project, Sprint by Sprint, to provide the greatest value and ROI to the organization. The
Product Owner uses the Product Backlog to give the highest priority to the requirements
that are of highest value to the business, to insert nonfunctional requirements that lead
to opportunistic releases and implementations of functionality, and to constantly adjust
the product in response to changing business conditions, including new competitive
offerings.

The Product Owner’s Value
One of the Product Owner’s primary concerns is the likely ROI of the project. The
Product Owner generally seeks to ensure that priorities in the Product Backlog are
geared to meet his or her requirements. That is, he or she will seek to assign priority to
requirements that present the greatest business value, based on market demand. He or
she may also choose to release a product into the market when the financial benefit is
likely to offset the cost of implementation.
Traditionally, customers (Product Owners) get to state the requirements that optimize
their ROI at the start of the project, but don’t get to change the requirements
throughout product development. If they are able to change the requirements it is to a
small extent that doesn’t allow them to accurately address changing market demands.
Scrum allows the Product Owner to adjust factors that affect his or her ROI much more
frequently.
Module 3.3 – The Scrum Master

The Scrum Master (a.k.a. the Facilitator) works closely with the Product Owner in order
to ensure that the latter’s requirements are met. The Scrum Master is ultimately
responsible for the Scrum process and must ensure that team members understand it
and correctly follow Scrum processes.
The Scrum Master’s key responsibilities include:
 Representing the face of management to the team members, and acting as the
conduit between management and the Scrum team.
 Enacting Scrum values and practices, and ensuring that they are continually
followed. This includes issuing invitations to Daily Scrum, Sprint Review and
Sprint Planning meetings.
 Removing impediments to the Scrum process.
 Ensuring that the team is fully functional and productive.
 Working to enable close cooperation across all roles and functions.
 Shielding the team from external interferences.
At a deeper level it may be noted that:
1. The Scrum Master needs to be aware of what tasks have been completed, what
tasks have begun, any new tasks that the Scrum team has become aware of as a
result of their work, and any estimates that have changed since the Sprint began.
This makes it possible for the Scrum Master to update the Burn‐Down chart,
which shows the work remaining at the end of each day.
2. The Scrum Master needs to be aware of any impediments that are affecting the
work of the Scrum team. These must be prioritised, tracked, and removed where
necessary. Some of these impediments can be resolved within teams, often with
very little effort, some can be resolved across teams (in larger organizations
which employ a number of Scrum teams), and other impediments require the
intervention of management.
3. Last but not least, the Scrum Master might notice personal problems and
conflicts within the Scrum team. Obviously a healthy level of disagreement is to
be expected in any creative environment, but serious problems can occur where
personality types clash. In any case, these problems need to be addressed by the
Scrum Master. Ideally, the Scrum team will be able to resolve the conflict
themselves. If this is not the case the Scrum Master, or even higher levels of
management may need to become involved. It is interesting to note that it is
estimated that over 50% of productivity losses are caused by differences
between team members. The Scrum Master must ensure that any problems are
remedied as soon as they appear.
How Does A Scrum Master Differ From A Traditional Project Manager?
There is a significant reason for using the term Scrum Master as opposed to the
traditional title of ‘Project Manager’. This is because the responsibilities of the Scrum
Master are very different to those of the traditional Project Manager. It highlights the
change in approach managers must make in order to successfully implement Scrum
practices in their organizations.
The Scrum Master can perhaps be seen as more of a Facilitator (and this term is
sometimes used instead of Scrum Master). He or she ensures that Scrum processes are
being followed and does not interfere in the direct development of the product during
the Sprint. The Scrum Team work in they way they prefer. As long as Scrum guidelines
are adhered to, there is no ‘wrong’ way of achieving their goal. Unsurprisingly, however,
the ultimate responsibility for the success of the project lies with the Scrum Master,
therefore he cannot afford to be derelict in his duties.
The Scrum Master’s role is to ensure that a product has the greatest possible chance of
being successfully completed. He does this by helping the Product Owner to select the
most valuable Product Backlog and by guiding the team in order to turn that Backlog
into a functional product.
Although the Scrum Master has more of an indirect role than that of a traditional
Project Manager it is a very important role. However, it is one thing to learn Scrum
practices and another to implement them successfully. Management is never an easy
role and although Scrum management comes easily for some, others struggle with it,
and perhaps we should accept that not all people have the aptitude to be a Scrum
Master. A project manager should not be hard on him or herself if the role of Scrum
Master does not come easily. However an effective and able Scrum Master is necessary
to ensure that Scrum implementations reach the level of success that is rightfully
expected by an organisation.
The difficulty experienced by a Project Manager is natural given that they are
attempting to embrace a completely different management philosophy. Some
individuals may even be resistant to change. But once they implement Scrum
techniques most soon see the advantages. In fact a novice Scrum Master’s best friend is
the regular processes involved in the Scrum methodology. The need to perform certain
tasks regularly matches the practices of many Project Managers, who enjoy the familiar
structure of regular meetings and set timetables.
Naturally, when the Scrum Master is comfortable with his or her role and adequately
fulfils his or her duties the project usually progresses smoothly. The Scrum Master’s
responsibilities should be enough to keep the Scrum Master busy. In fact, no Scrum
Master should have any time left over to act like a typical boss. Indeed, a Scrum Master
who acts like a program manager probably isn’t fulfilling all of his or her duties as a
Scrum Master.
As mentioned above, individuals come to understand the Scrum Master role in their
own time. Some people intuitively understand their new role and take to it like a duck to
water. Others struggle to understand Scrum. Members of the latter group may
sometimes make damaging mistakes as they learn. However, this is part of the learning
process. Indeed, the flexibility and agility of Scrum can be expected in some cases to
result in these errors being quickly detected and remedied. Remember that even the
successful Scrum Master requires several Sprints to get going. Scrum Masters who are
unsure of their role would be well advised to focus on what can be done rather than be
frustrated by things that are beyond their control. Trust in your team, and Scrum
processes.

Module 3.4 – The Team (Team Members)

The Team (and hence the Team Members) assumes the responsibility, in each iteration,
of transforming the Product Backlog into an increment of Product functionality. They
are also responsible for organizing their own work so as to achieve the delivery of each
increment.

Typically Scrum Teams are:

 Composed by 5‐9 people

 Cross‐Functional (Programmers, testers, users experience designer, etc.)

 Members should be full‐time (may be some exceptions, e.g., database
administrator)

 Self‐Organizing (ideally, no titles but rarely a possibility)

 Membership should change only between sprints.

Scrum Teams select the Sprint goal and specify work results. Beside have the right to do
everything within the boundaries of the project guidelines to reach the Sprint goal.
Additionally, the Team demos results to the Product Owner.

Module 4 – The Scrum Process

Module 4.1 – User Stories

What is a User Story?

Extreme programming (XP) introduced the practice of expressing requirements in the
form of user stories, short descriptions of functionality–told from the perspective of a
user–that are valuable to either a user of the software or the customer of the software.
The following are typical user stories for a job posting and search site:

 A user can post her résumé to the web site.
 A user can search for jobs.
 A company can post new job openings.
 A user can limit who can see her résumé.

But user stories are not just these small snippets of text. Each user story is composed of
three aspects:
1. Written description of the story, used for planning and as a reminder;
2. Conversations about the story that serve to flesh out the details of the
story;
3. Tests that convey and document details that can be used to determine
when a story is complete.

Then, user stories are a quick way of handling customer requirements without having to
elaborate vast formalized requirement documents and without performing overloaded
administrative tasks related to maintaining them. The intention with the user story is to
be able to respond faster and with less overhead to rapidly changing real‐world
requirements.

A user story is an informal statement of the requirement as long as the correspondence
of acceptance testing procedure is lacking.

Before a user story is to be implemented, an appropriate acceptance procedure must be
written to ensure by testing or otherwise determine whether the goals of the user story
have been fulfilled. Some formalization finally happens when the team accepts the user
story and the acceptance procedure as his work specific order.

User Stories vs. Use Cases

It is pretty useful to clarify the difference between User Stories and the traditional
Requirements Statements (a.k.a. “Use Cases”).

The exhibit below gives a graphical view on this topic.

Aspect User Stories Use Cases
Communication Emphasize Verbal CommunicationEmphasize Written Language
Encourage the team to defer A use case almost always covers
Scope collecting details (perfect for a much larger scope than a
time–constrained projects) story.
Often permanent artifacts that
Not intended to outlive the
continue to exist as long as the
Longevity iteration in which they’re added
product is under active
to the software.
development or maintenance.
To facilitate release and
iteration planning, and to serve To document an agreement
Purposes as placeholders for between the customer and the
conversations about the users’ development team.
detailed needs.
Difficult Planning. Cost of
Enables Planning. An estimate each requirement is not made
is associated with each story visible until all the
Cost Visibility &
immediately, of how difficult or requirements are written.
Planning
time–consuming it will be to Then they are generally too
develop. large to be given useful
estimates.

Some Tips to Create User Stories

The customer, through the Product Owner, is responsible for formulating the user stories
(i.e., the developer cannot be responsible of this), since those stories should be addressing
specific business needs.

When the time has come for creating user stories, the Product Owner, as responsible of
the project from the Stakeholders perspective, may get together with a customer
representative, to clearly identify the needs. It may be used some series of questions to
get the customer going, such as asking if some particular functionality is desired, but it is
important not to dominate the idea creation process.

As the customer conceives the user stories, the Product Owner writes them down on a
note card (e.g. 3x5 inches or 8x13 cm) with a name and a description which the
customer has formulated. If they find that the user story is lacking in some way (too
large, complicated, imprecise), it is rewritten until it is satisfactory. However, it is
sometimes stressed that user stories are not to be definite once they have been written
down. Requirements tend to change during the development period, which is handled
by not carving them in stone.

Some Limitations

 Without accompanying acceptance tests, they are open to interpretation which
makes them difficult to use as the basis for collaboration;

 They require close customer contact (assumed by the Product Owner)
throughout the project which in some cases may be difficult or may be
unnecessary overhead;

 Can have difficulty scaling to large projects;

 Rely more on competent developers;

 User stories are regarded as conversation starters. Unfortunately they may not
capture where the conversation ended and thus fail to serve as a form of reliable
documentation of the system.

Module 4.2 – Release Planning

Release Planning

The purpose of release planning is to establish a plan and goals that the Scrum Team(s)
and the rest of the organization can understand and communicate.

Release planning seeks to answer the questions: How can we turn the vision into a
winning product in the best possible way? How can we meet or exceed customer
satisfaction and Return On Investment (ROI)?

Release planning determines five things:

 The goal of the release.

 The major risks.

 The overall features and functionality that the release shall contain.

 A probable delivery date and cost, assuming there are no significant changes to
the overall features and requirements.

 The organization can monitor progress and choose to make changes to this
release plan on a Sprint‐by‐Sprint basis.

Each Sprint produces an increment of the final product (that is, the release), starting
with the riskiest and most valuable element of the product. Obviously further Sprints
result in further increments being added. Each increment should be viewed as a
product that potentially could be a release. When enough increments have been added
to the product to make it financially viable the Product Owner decides to release it.

Most organizations have a release planning process in place. Both Scrum and
traditional processes are similar in many of the plans and goals that were listed above.
Scrum release planning should require no more than 15‐20% of the time an
organization consumes to build a traditional release plan. Scrum differs to traditional
processes in that ‘just in time’, or further release, planning occurs throughout the
development of the product. This ‘just in time’ planning occurs at every Sprint Review,
every Sprint Planning meeting, and every Daily Scrum meeting.

Module 4.3 – Product Backlog

The Product Backlog is the master list of all functionality desired in the product.

When a project is initiated there is no comprehensive, time‐consuming effort to write
down all foreseeable tasks or requirements. Typically, a project writes down everything
obvious, which is almost always more than enough for a first sprint. The Product
Backlog is then allowed to grow and change as more is learned about the product and
its customers.

The Product Owner shows up at the Sprint Planning Meeting with the prioritized
product backlog and describes the top items to the team. The team then determines
which items they can complete during the coming sprint. The team then moves items
from the Product Backlog to the Sprint Backlog. In doing they expand each Product
Backlog item into one or more Sprint Backlog tasks so they can more effectively share
work during the Sprint. Conceptually, the team starts at the top of the prioritized
Product Backlog list and draws a line after the lowest of the high priority items they feel
they can complete. In practice it is not unusual to see a team select, for example, the
top five items and then two items from lower on the list but that are associated with the
initial five.

Module 4.3 – Continued

Product backlog items can be technical tasks or more user‐centric.

An example (Excel based) Product Backlog appears as follows:

This Excel spreadsheet shows each product backlog item assigned a general priority
(Very High, High, etc.) by the Product Owner. Estimates have been developed by the
developers but it is understood that they are very imprecise and are useful only for
rough assignments of tasks into the various sprints.

Module 4.4 – Sprint

A Sprint is an iteration. Sprints are time‐boxed. During the Sprint, the Scrum Master
ensures that no changes are made that would affect the Sprint Goal. Both Team
composition and quality goals remain constant throughout the Sprint.

Sprints contain and consist of the Sprint Planning meeting, the development work, the
Sprint Review, and the Sprint Retrospective. Sprints occur one after another, with no
time in between Sprints.

A project is used to accomplish something; in software development, it is used to build a
product or system. Every project consists of a definition of what is to be built, a plan to
build it, the work done according to the plan, and the resultant product. Every project has
a horizon, which is to say the time frame for which the plan is good. If the horizon is too
long, the definition may have changed, too many variables may have entered in, the risk
may be too great, etc. Scrum is a framework for a project whose horizon is no more than
one month long, where there is enough complexity that a longer horizon is too risky. The
predictability of the project has to be controlled at least each month, and the risk that the
project may go out of control or become unpredictable is contained at least each month.
Tip: If the Team senses that it has overcommitted, it meets with the Product
Owner to remove or reduce the scope of Product Backlog selected for the Sprint.
If the Team senses that it may have extra time, it can work with the Product
Owner to select additional Product Backlog.

Tip: When a Team begins Scrum, two‐week Sprints allow it to learn without
wallowing in uncertainty. Sprints of this length can be synchronized with other
Teams by adding two increments together.

Sprints can be cancelled before the Sprint time box is over. Only the Product Owner has
the authority to cancel the Sprint, although he or she may do so under influence from
the stakeholders, the Team, or the ScrumMaster. Under what kind of circumstances
might a Sprint need to be cancelled? Management may need to cancel a Sprint if the
Sprint Goal becomes obsolete. This could occur if the company changes direction or if
market or technology conditions change. In general, a Sprint should be cancelled if it no
longer makes sense given the circumstances. However, because of the short duration of
Sprints, it rarely makes sense to do so.

When a Sprint is cancelled, any completed and “done” Product Backlog items are
reviewed. They are accepted if they represent a potentially shippable increment. All
other Product Backlog items are put back on the Product Backlog with their initial
estimates. Any work done on them is assumed to be lost. Sprint terminations consume
resources, since everyone has to regroup in another Sprint planning meeting to start
another Sprint. Sprint terminations are often traumatic to the Team, and they are very
uncommon.

Sprint Main Rules

Sprints have some specific attributes or rules that determine the Sprint’s outcome.
Below are key Scrum “Ground Rules” that are critical for teams to respect and
support:
 Scrum projects make progress in a series of ‘Sprints’.
 A typical Sprint duration is 1-4 weeks. Usually a maximum of 30 days.
 A Sprint is undertaken by a cross-functional team consisting of no more than

9 members (ideally 6, plus or minus 3).
 A constant duration leads to a better rhythm.
 A fully releasable product increment is designed, coded and tested during the
Sprint.
 Every Sprint has a specific goal.
 The team will complete a set of software features that meets that goal during
the Sprint. The Sprint team has the final say in what they can accomplish
during the Sprint.
 Once the Sprint is underway, new backlog items cannot be added to the
Sprint, except if the Scrum Master determines that a new backlog item will
enhance the viability of the product. This product must be in alignment with
the Sprint, build on the Sprint’s previous product, and must be completed
within the Sprint’s time frame.

Agile Project Management with Scrum – Ken Schwaber (Microsoft Press)

Module 4.5 – Sprint Planning

The Sprint Planning meeting is when the iteration is planned. It is time‐boxed to eight
hours for a one month Sprint. For shorter Sprints, allocate approximately 5% of the total
Sprint length to this meeting and consists of two parts. The first part, a four hour time‐
box, is when what will be done in the Sprint is decided upon. The second part, another
four‐hour time box, is when the Team figures out how it is going to build this
functionality into a product increment during the Sprint.

There are two parts to the Sprint Planning Meeting: the “What?” part and the “How?”
part. Some Scrum Teams combine the two.

“WHAT?” PART

In the first part, the Scrum Team addresses the question of “What?” Here, the Product
Owner presents the top priority Product Backlog to the Team. They work together to
figure out what functionality is to be developed during the next Sprint. The input to this
meeting is the Product Backlog, the latest increment of product, the capacity of the
Team, and past performance of the Team. The amount of backlog the Team selects is
solely up to the Team. Only the Team can assess what it can accomplish over the
upcoming Sprint.

Having selected the Product Backlog, a Sprint Goal is crafted. The Sprint Goal is an
objective that will be met through the implementation of the Product Backlog. This is a
statement that provides guidance to the Team on why it is building the increment. The
Sprint Goal is a subset of the release goal.

The reason for having a Sprint Goal is to give the Team some wiggle room regarding the
functionality. In order to satisfy the goal, it implements the functionality and
technology. If the work turns out to be harder than the Team had expected, then the
Team collaborates with the Product Owner and only partially implement the
functionality.

“HOW?” PART

In the second part of the Sprint Planning Meeting, the Team addresses the question of
“How?” During the second four hours of the Sprint Planning Meeting, the Team figures
out how it will turn the Product Backlog selected during Sprint Planning Meeting
(What?) into a done increment. The Team usually starts by designing the work. While
designing, the Team identifies tasks. These tasks are the detailed pieces of work needed
to convert the Product Backlog into working software. Tasks should have decomposed
so they can be done in less than one day. This task list is called the Sprint Backlog. The
Team self‐organizes to assign and undertake the work in the Sprint Backlog, either
during the Sprint Planning meeting or just‐in‐time during the Sprint.

Tip: Usually, only 60‐70% of the total Sprint Backlog will be devised in the Sprint
Planning meeting. The rest are stubbed out for later detailing, or given large
estimates that will be decomposed later in the Sprint.

The Product Owner is present during the second part of the Sprint Planning Meeting to
clarify the Product Backlog and to help make trade‐offs. If the Team determines that it
has too much or too little work, it may renegotiate the Product Backlog with the Product
Owner. The Team may also invite other people to attend in order to provide technical or
domain advice. A new Team often first realizes that it will either sink or swim as a Team,
not individually, in this meeting. The Team realizes that it must rely on itself. As it
realizes this, it starts to self‐organize to take on the characteristics and behavior of a real
Team.

The following illustration the preparation and execution of a well planned Spring
Planning Meeting:


Tip: Sprint planning needs to be viewed as a collaborative, whole‐team effort.
When sprint planning is viewed solely as the sum of individual or specialty‐based
planning, both the product and the team will suffer. To avoid this, ensure not
only that all team members participate but that they all participate together.

Module 4.6 – Sprint Backlog / Burn-down Chart

Sprint Backlog

The Sprint Backlog consists of the tasks the Team performs to turn Product Backlog
items into a “done” increment. Many are developed during the Sprint Planning
Meeting. It is all of the work that the Team identifies as necessary to meet the Sprint
goal. Sprint Backlog items must be decomposed. The decomposition is enough so
changes in progress can be understood in the Daily Scrum.

The Team modifies Sprint Backlog throughout the Sprint, as well as Sprint Backlog
emerging during the Sprint. As it gets into individual tasks, it may find out that more or
fewer tasks are needed, or that a given task will take more or less time than had been
expected. As new work is required, the Team adds it to the Sprint Backlog. As tasks are
worked on or completed, the hours of estimated remaining work for each task is
updated. When tasks are deemed unnecessary, they are removed. Only the Team can
change its Sprint Backlog during a Sprint. Only the Team can change the contents or
the estimates. The Sprint Backlog is a highly visible, real‐time picture of the work that
the Team plans to accomplish during the Sprint, and it belongs solely to the Team.

Sprint Backlog Burn‐down

Sprint Backlog Burn‐down is a graph of the amount of Sprint Backlog work remaining in
a Sprint across time in the Sprint. To create this graph it is necessary to determine how
much work remains by considering the backlog estimates every day during the Sprint.
The amount of work remaining for a Sprint is the total of the work remaining for all of
the Sprint Backlog. Keep a daily track of these sums and use them to create a graph
that shows the work remaining over time. By drawing a line through the points on the
graph, the Team can manage its progress in completing a Sprint’s work.

It is recommended that this graph be prominently displayed on a whiteboard or large
sheet of paper rather than on a computer Excel spreadsheet. By using a Burn Down
chart a team is likely to be motivated as they can see that they are making progress
through the Sprint. This will give the team encouragement, and keep them motivated.

Some “Look Like” Examples:

Sprint Burn‐down Chart

Sprint Backlog

Tips for Creating a Good Sprint Backlog.
The Sprint Backlog is a list of tasks that must be completed during the Sprint in order to
deliver a functioning increment of the final product to be released. The Sprint Backlog
is created during the second part of a Sprint Planning meeting, and every team
member is expected to contribute. Unfortunately many Scrum Teams struggle with this
process. The following tips should help:
1. Full Team Participation
As mentioned, every member of the team must contribute to the process. The
importance of this point cannot be stressed enough. When everyone
contributes to the creation of the Sprint Backlog, the benefit is that it is drawing
on a variety of perspectives and viewpoints. This leads to the creation of a much
broader Backlog than if only one or two individuals were involved. A Scrum
Master should ensure that more forceful personalities do not ‘drown out’ the
opinion of more introspective individuals.
2. Collaboration:
Discuss how every item should be implemented. Before tasks are written down
the team should discuss every issue of concern (story) that will be brought into
the Sprint. In fact it might be fair to expect that the majority of the meeting
should be dedicated to understanding how the team will approach these stories.
Stories may include creating basic designs, checking existing code, and
architectural features. This shared understanding of the stories and their
possible solutions will enable the Scrum team to create a task list that accurately
defines the work that needs to be done.
3. Clear Definition of “DONE”
Have a definition of ‘done’ or complete. It is important that each member knows
what end result they are working towards. This definition provides the team with
guidance about what needs to be done and will remind the team what the
established criteria are for every task in the Backlog. That is, what every task
involves, and what is required for it to be successfully completed.

4. All Work Scheduled for a Sprint is Fully Identified
Many Scrum teams make the mistake of overly focusing on coding. Coding by
itself is not enough to deliver real functional software, and certainly not the
potentially shippable software that should be produced during a Sprint. The
Sprint backlog should incorporate every kind of task from object modeling, to
architectural elements, and testing.
5. Estimate Tasks in Hours
Estimating tasks should be done in hours. This is especially important given that
teams are required to measure burn down in hours. Naturally, and particularly
for new teams, providing an accurate estimation can be difficult. However, team
members should not get hung up on this. Teams should remember that they can
only make estimates based on what information is available to them at the time.
Circumstances constantly change and this will have an affect on the amount of
time a task takes to complete. By identifying as many tasks as possible the team
creates progress that can be measured. Being able to see this progress
contributes greatly to the morale of a team, the success of the team during the
Sprint, and the quality of product delivered at the end of the Sprint.
6. Avoid Specialization of Team Members
Scrum Masters, and even team members themselves, should be wary of
directing work. The team should decide who is going to do what according to the
current circumstances. By assigning tasks to the ‘most suitable’ team member,
the rest of the team is being denied a chance to learn. Additionally,
communication will decrease as individuals are left to their own devices. Trust
the team to manage themselves and better results can be expected. Remember,
by working according to Scrum principles, teams have the freedom to create
products that best fit the requirements and resources available to them at a
given point of time. By doing things in a particular way “because that is how
something is always done”, valuable opportunities to innovate can be lost.
7. The Team Determines the Sprint Commitment
Review the Sprint commitment. Once task identification is completed, the team
will have a much better idea of the effort that will be required during the Sprint.
At this point the team should re‐analyze the sprint commitment. The team needs
to ask whether the Sprint backlog really fits into the Sprint. If not, there are some
options available to the team. The team may choose to leave out the item that
has the lowest priority, or alternatively split the stories into smaller pieces. What
matters is ensuring that the team has a good understanding of what is required
of them during the Sprint.
8. Time Box in Short, 1‐4 Week Increments
Don’t take too much time. Time‐boxing forces the team to focus their attention
on the job at hand. In this way they are more likely to come up with useful
stories that will contribute positively to the Sprint Backlog.
9. Encourage Backlog Refactoring
Allow the Sprint Backlog to evolve during the Sprint. New ideas may arise and old
ones will possibly be discarded. In essence it is an organic, fluid process,
reflecting the dynamic and changing nature of Scrum. The Daily Scrum is the
ideal time to create new tasks and remove unnecessary ones.

For individuals or teams who are new to the Scrum process, it can reasonably be
expected that they will have difficulties in producing a coherent Sprint Backlog.
However, by following the above tips they will enjoy a number of benefits, which may
include a better overall understanding of what needs to be done, a clear sense of daily
progress, and more productive Sprints.

Module 4.7 – Sprint Review

Sprint Review

At the end of the Sprint, a Sprint Review meeting is held. This is a two‐hour time‐boxed
meeting for one month Sprints. Naturally, for Sprints of a shorter duration the meeting
will be shorter. However, shorter sprints should also be time‐boxed to ensure that the
meeting is conducted efficiently, focusing on important points.

The purpose of the Sprint Review is to allow the Scrum Team, the Scrum Master, and
other stakeholders to discuss what was achieved during the Sprint, and what could be
done better during the next Sprint. The former requires a presentation from the team,
which demonstrates the functionality of the product. It should be noted that this is a
collaborative meeting. Working within the Scrum philosophy, stakeholders such as
management are not there to criticize the Scrum team. They must remember that the
Scrum team has produced something using the resources currently available to them.
This point has been repeated but all stakeholders must understand it.

The Sprint Review meeting should contain the following elements:

 The Product Owner identifies what has been done and what hasn’t been done.

 The team discusses what went well during the Sprint, the problems it
encountered, and how these problems were solved.

 The team then demonstrates the product and its functionality. It then answers
questions from the stakeholders regarding the product.

 The Product Owner discusses the current Product Backlog.

 The Product Owner announces a completion date based on various assumptions
and market trends.

 The entire group discusses the results presented in the meeting and decides
what to do next.

These points demonstrate that the Sprint Review meeting provides important content
for the next Sprint Planning meeting.

Sprint Review Meeting Main Rules.

The most important sprint review rules are listed below:

 Time Boxed: The Sprint review meeting is time‐boxed to 4 hours.

 Limit Prep Time: The Team should not spend more than 1 hour preparing for
the Sprint review.

 Purpose of Meeting – Demo of Completed Functionality: The purpose of the
Sprint review is for the Team to present to the Product Owner and stakeholders
the functionality that was completed during the sprint. In a Scrum context the
functionality is generally understood to mean that the product is completely
engineered to a point where it could potentially be shipped or implemented. If
the functionality is not completed to this state of completeness this must be
clearly communicated to the Product Owner(s) and other stakeholders. No
other work products (artifacts or incomplete software features) are allowed to
be presented at the Sprint Review meeting.

 Demo Environment: Functionality should be presented on Team member
workstations and executed from the server closest to production. This is usually
done on a Quality Assurance (QA) environment server. Of course this assumes
that software is being produced.

 Meeting Kick‐Off Protocol: The Sprint review starts with a Team member
presenting the Sprint goal, the Product Backlog committed to at the start of the
Sprint, and the Product Backlog completed during the Sprint. Different Team
members can then discuss what went well and what didn’t go well during the
Sprint.

 Team Led Discussion: The majority of the Sprint review is spent with Team
members presenting functionality, answering stakeholder questions regarding
the presentation, and noting changes that are desired.

 Wrap‐Up Discussion: At the end of the presentations, the stakeholders are
asked individually to give their impressions, discuss any desired changes, and
the priority they would seek to assign to these changes.

 Product Owner Feedback: The Product Owner discusses with the stakeholders
and the Team a potential rearrangement of the Product Backlog if the feedback
suggests that this is required.

 Open Participation: Stakeholders are free to voice any comments, observations,
or criticisms regarding the potentially shippable product and/or its functionality.

 Highlight Missing Deliverables & Re‐plan for Subsequent Sprint: Product
Owners and Stakeholders should be expected to identify functionality that
wasn’t delivered or wasn’t delivered as expected, and request that such
functionality be placed in the Product Backlog.

 Capture of New Backlog: as Stakeholders can identify new functionality that
occurs to them as they view the presentation and request that this functionality
be added to the Product Backlog.

 Meeting Administration:

o It is the Scrum Master’s responsibility to determine how many people will be
at the meeting and ensure that they can all be accommodated.

o At the end of the Sprint review, the Scrum Master announces the place and
date of the next Sprint review.

Module 4.8 – Daily Scrum

Daily Scrum Meetings

The Scrum team meets daily at a set time and place throughout the duration of the
Sprint. These meetings are called the Daily Scrum.

During these meetings, each Scrum Team member answers three (and they are only
ever the same three) questions. All discussion other than that directly related to the
answering of these questions is deferred to later meetings. These three questions are:
What have you done since the last Daily Scrum regarding this project? What will you do
between now and the next Daily Scrum meeting regarding this project? What impedes
you from performing your work as effectively as possible?

The purpose of the Daily Scrum is to improve communication, eliminate other
meetings, identify impediments to production, highlight and promote quick decision
making, and improve everyone’s level of project knowledge.

Although the Scrum Master ensures that the meeting is carried out, the Daily Scrum is
not a meeting for his benefit. The Daily Scrum discusses progress toward the Sprint
Goal. Follow‐up meetings usually occur in order to make adaptations to upcoming work
during the Sprint.

As well as ensuring that the meeting takes place, the Scrum Master makes sure that the
Daily Scrum rules are followed. This keeps the meeting brief and to the point. The
Scrum Master must also pay particular attention to the rule forbidding any chickens
that may be present from talking.

Daily Scrum Meeting Main Rules.

The most important Daily Scrum rules are as follows:

 The Daily Scrum meeting is time‐boxed to 15 minutes, regardless of the number
of Team members.

 The Daily Scrum meeting is to be held in the same place at the same time on
every workday. Note that the Daily Scrum is best held first thing in the day. This
is because the achievements of the previous day are still fresh in the minds of
team members.

 All Team members are required to attend the meeting in person. If for some
reason a Team member can’t attend in person, the absent member must either
attend via telephone or internet link. Alternatively, another Team member may
report on the absent member’s status.

 Team members must arrive at the meeting at the scheduled time. The Scrum
Master should start the meeting at the appointed time, regardless of who is
present. In order to deter people from turning up late Scrum Masters should
consider issuing a small fine (one dollar is enough) to any latecomers.

 The Scrum Master begins the meeting by starting with the person immediately
to his or her left and proceeding clockwise around the room until everyone has
reported.

 Each Team member should respond to these three questions only: What have
you done since the last Daily Scrum regarding this project? What will you do
between now and the next Daily Scrum meeting regarding this project? What
impedes you from performing your work as effectively as possible? Team
members are expected to answer these questions directly and concisely and not
digress into discussions of problems, questions of their own, or personal
complaints and gossip. The Scrum Master is responsible for moving the
reporting along and ensuring that questions are answered in the manner
described above.

 During the Daily Scrum, only one person talks at a time. Everyone else is
expected to focus his or her attention on this person.

 When a Team member reports something that is of interest to other Team
members or requires the assistance of other Team members any Team member
can immediately arrange for all interested parties to get together after the Daily
Scrum to set up a meeting.

 Chickens (that is stakeholders who are not directly a part of the everyday
development process) are not allowed to talk, make observations, or otherwise
make their presence felt in the Daily Scrum meeting. In fact, their presence in
Daily Scrum meetings should be discouraged wherever possible to ensure that
Team members feel free to speak honestly and openly.

 When present, chickens are expected to stand on the periphery of the Team so
as to minimize the possibility of them interfering with the meeting.

 If the Scrum Master believes that too many chickens are present at the
meeting, the Scrum Master can limit attendance so that the meeting can remain
orderly and focused.

 Pigs (team members) or chickens who cannot or will not adhere to the above
rules can be excluded from the meeting (chickens), or removed from the Team
(pigs).

Module 4.9 – Sprint Retrospective

Sprint Retrospective Meeting

After the Sprint Review and prior to the next Sprint Planning meeting, the Scrum Team
conducts a Sprint Retrospective meeting. At this time‐boxed meeting the Scrum Master
should encourage the Scrum Team to revise, within Scrum process framework and
practices, their development process to make the next Sprint more enjoyable for team
members.

The purpose of the Retrospective is to gauge the success or otherwise of the last Sprint
in regards to personal relationships, processes, and tools. The retrospective can be
expected to result in improved communication and processes that allow for Product
Backlog items to be completed (turned into a functioning product).

Sprint Retrospective Meeting Main Rules.

The most important sprint retrospective meeting rules are:
 The Sprint retrospective meeting is time‐boxed to 3 hours.
 Only the Scrum Team and the Scrum Master attend the meeting. However the
Product Owner may attend if he or she wishes to, but their presence is by no
means compulsory.
 The meeting should begin with all members answering two questions. First,
what went well during the last Sprint? Second, what could be improved in the
next sprint? These questions enable the team to identify the things that they
should continue doing, and the things that they should eliminate during the
next Sprint.

 The Scrum Master writes down the Team’s answers in summary form.

 The Team decides in which order it wants to discuss the potential
improvements.

It should be noted that, in keeping with his role as facilitator, the Scrum Master is not
at this team meeting to provide answers, but rather to facilitate the Sprint team’s
search for better work processes.
Bibliography / References

Below is a list of the main resources consulted to prepare this Guide.

Specialized Internet Sites:

http://xprogramming.com/index.php
http://media.pragprog.com/articles/other-published-articles/ArtInProgramming.pdf
http://www.eclipse.org/epf/
http://www.featuredrivendevelopment.com/
http://www.dsdm.org/
http://www.scrumalliance.org - Scrum Alliance
http://www.odgroup.com - Orion Development Group
http://www.informit.com

Books:

Agile Project Management with Scrum – Ken Schwaber (Microsoft Press)
The Enterprise and Scrum – Ken Schwaber (Microsoft Press)

About Gear Stream, Inc.
Gear Stream is the leading large‐scale Agile Enterprise Transformation and Agile
Outsourcing Partner in North America focused on supporting Agile team transitions that
drive broad company support for innovating the entire software and product
development life‐cycle. In contrast to others, Gear Stream’s Agile Transformation
Framework integrates direct involvement from CIO’s, PMO’s, Product Marketing, QA
and Operations Leaders to insure that broad company change is constructively
supported and implemented.
Gear Flow, Gear Stream’s flagship transformation framework, is designed to guide
Enterprise executives on how best to drive sustainable Lean and Agile change across the
organization resulting in up and down stream enterprise workflows better synchronized
with Agile team speed and cadence. The Gear Flow framework also includes a keen
focus on identifying and eliminating excessive, unnecessary governance resulting in
driving additional Agile team productivity and dramatic improvements to end‐to‐end
cycle‐time and software and product quality ‐ something we like to call “Getting in the
Flow.”
Gear Stream, Inc. is headquartered in Raleigh, North Carolina and is privately held with
additional offices in New York, D.C., Atlanta, Dallas, Austin, Chicago and an Agile
Development Center in Argentina. For more information about how Gear Stream visit
us online at:
www.gearstream.com
or by calling 1‐800‐935‐1420

Copyright © 2010 Gear Flow is a registered trademark of Gear Stream, Inc. All other
trademarks mentioned in this release are the property of their respective owners.


Scrum Fundamentals Student Handbook

Uploaded by

Copyright:

Available Formats

Scrum Fundamentals Student Handbook

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

Scrum Fundamentals Student Handbook

Uploaded by

Copyright:

Available Formats

Module 1 - Introduction to Agile Methodologies ................................................. 7

Module 2 - Introduction to Scrum ........................................................................ 21

Module 3 – Roles & Responsibilities in Scrum ................................................. 35

Module 4 – The Scrum Process ........................................................................... 44

Module 1.1 - General Agile Concepts

Module 2.1 – Origin & History of Scrum

Module 2.2 – Why Scrum?

Module 2.3 – Philosophy of Scrum

Module 2.4 – Scrum Attributes & Characteristics

Sprint Planning Product Backlog

Module 3.1 – The Rules Overview

Module 3.3 – The Scrum Master

Module 4.1 – User Stories

 Scrum projects make progress in a series of ‘Sprints’.

 A typical Sprint duration is 1-4 weeks. Usually a maximum of 30 days.

 A Sprint is undertaken by a cross-functional team consisting of no more than

 A constant duration leads to a better rhythm.

 Every Sprint has a specific goal.

Module 4.5 – Sprint Planning

Module 4.6 – Sprint Backlog / Burn-down Chart

Module 4.7 – Sprint Review

Module 4.8 – Daily Scrum

You might also like