SCRUM MASTER NOTES

12 AGILE MANAGEMENT PRINCIPLES

• Highest Priority is to satisfy the customer (through early and
continuous delivery)
• Welcome changing requirements (competitive advantage)
• Deliver frequently with a preference for the shorter timescale
• Contributors must work together daily throughout the project
• Build projects around motivated individuals in a supportive
environment of trust
• Most efficient and effective method of conveying information
is face-to-face communication
• Working project is the primary measure of progress
• Agile processes should promote sustainable development at a
constant indefinite and pace
• Continuous attention to technical/ design excellence
• Simplicity, the art of maximizing the amount of work “not done”
is essential
• Best results is derived from self-organized emerging teams
• Interactive reviews or every sprint (lessons learned) adjustments
should be made accordingly

AGILE MANIFESTO VALUES

• Individuals and Interactions over Processes and Tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change opposed to following a plan

WHY AGILE?
• Accelerated Speed to Market
• Flexibility (Design and Build to Potentiality)
• Risk Management Enhancement (expedited reaction time)
• Cost Control (Cost Association Affiliation)
• Quality (Request/ Requestor Satisfaction)
• Right Product (Requirement fulfillment)
• Transparency (Time barrier element is eliminated)

1
 MISCONCEPTIONS
• Its new, its different (and it’s been around since over 20 years)
• Fixed Budget potential is possible as long as scope/ schedule/
budget remain the same
• It’s too unpredictable (despite change potential Agile can
bring the product to market sooner)
• Features are controlled by the developers (Features are controlled
by the requirements)
• Strategic goals aren’t considered (developers can only do what you
ask them to do)
• Teams are required to work more closely together… and with business
(as they should)

AGILE LIFE CYCLE

PLAN/ DO/ CHECK/ ACT

• Planning
• Execution
• Review
• Reset and Repeat Cycle

KEY AGILE DEFINITIONS

• Sprint (Phases executed in intervals)

• Backlog (Requirements)
• User Stories: I (the user) wants to do (something) so that I can
accomplish... (goal)

SPRINT PLANING

• Review and understand the goals of the project

• Review the resources assigned to the project
• Determine the key decision makers (customer/ stakeholder/ sponsor)
• Create Project Backlog (LOP)
• Determine what’s “1st to be created”
• Get the team on the same page

PROJECT OWNER BACKLOG

• User Stories should be ranked by priority

• What the users want that has not been delivered

2
ESTIMATIONS

• The process for understanding how long a feature or other

functionality (User Story) will take to be delivered through the sprint
process.
• If longer than 3 sprints, then break it down into increments.
(Best Practice: Each sprint = absolute max. 4 weeks)

THE SPRINT

• A set amount of time where the work is to be accomplished

• Usually 1-2 weeks (not months or years)

THE DAILY STANDUP (Breif 15 minute meeting)

• What was done yesterday?

• What is going to be done today?
• Do you need any help or are there any blockers in the way?

KEYS TO SUCCESS

• Good planning (Do what’s necessary but not too much)

• Team work (Freeform work in environment: teams must be held
accountable)
• Communication Skills (communication between team in itself is even
more important)

EVOLUTIONS

• Scrum Alliance
• The Software Craftsmanship Manifesto
• Guide to Agile Practices
• Agile principle include in PMI and prince 2, IIBA bodies of knowledge

PROJECT MANAGEMENT IN AN AGILE WORLD

Basics of Projects

• What is a project/ program/ portfolio?

- Project: distinct amount of work that has a beginning/

a middle/ an End
- Program: generally a group of Projects
- Portfolio: basically a conglomeration of Projects of
Programs within an Organization

3
Why do Projects Fail?

• Inadequate planning
• Lack of control
• Non-existent support
• Unmitigated risks
• Unrealistic Expectations
• Poor communications
• Missed Deadlines

Keys to Success

• Practical Plan and Expectations

• Change Control
• Management Support
• Effective Risk Management Procedures
• Clear Direction
• Skilled Resources
• Clear Communications

Waterfall vs. Iterative Procedure

• Waterfall Procedure: A rigid flow concept, Main Disadvantage is that

sequential methodic is unable to ensure success because hidden
specifics are unknownable in advance
• Iterative Procedure: Learn and Repeat (Evaluation/ Prioritization,
Requirements, Design, Build or Develop, Test, Repeat)
“Cyclical process” = constant/ continuous improvement

WHY DO WE HAVE PROJECTS IN ORGANIZATIONS

3 C’s
• Cost (we want to make money)
• Customers (we want to make money)
• Compliance (while making money we want to stay out of jail)

Traditional Project elements in an Agile World

• Stakeholders
• Scope (Mission Statement may change by Stakeholder)
• Time/ Schedule
• Cost/ Budget
• Quality
• Resources
• Communications
• Risk
• Change
• Procurement

4
Role of the Project Manager

• Leadership
• Communications
• Facilitation
• Method Guidance (Scrum Master)

Role of the Business Analyst

• Requirements Guidance
• Facilitation

Role of the Developer

• Listener
• Doer

Role of the Client/ Customer

• Guidance
• Agreement
• Approval

AGILE AND SCRUM

What is Scrum:

• Lightweight
• Simple to understand
• Difficult to master

Concept originates from Rugby where a group of opposing teams come to-
gether, where the ball is kind of in the middle and they’re trying to procure
the ball and move forward against the other team. In Agile Project Manag-
ment it’s the framework within which people can address complex adaptive
problems, while productively and creatively delivering products of the highest
possible value. Scrum is founded on empirical process control theory, or em-
piricism. Empiricism asserts that knowledge comes from experience and mak-
ing decisions based on what is known. Scrum employs an iterative, incremen-
tal approach to optimize predictability and control risk.

Three pillars uphold every implementation of empirical process control: trans-

parency, inspection, and adaptation.

3 Components

• Roles (flexible definition of task interaction)

• Process (To Do List)
• Artifacts (Deliverables)

Rules of Scrum: The rules of Scrum bind together the roles, events, and
artifacts, governing the relationships and interaction between them.
5
5 Major Activities

• The Kick-off (initial establishment regarding the common agreement/

direction is conveyed to team)
• Sprint Planning Meeting (conflict resolution meetings which are to be
conducted in intervals)
• The Sprint (The allocated interval for conflict resolution)
• The Daily Scrum (A brief stand-up meeting: what was done
yesterday?, today?, will be done tomorrow?)
• Sprint Review Meeting (Lessons Learned)

Team management by commitment

3 Key Questions

• What was done since the last scrum?

• What will be done until the next scrum?
• Are there any obstacles standing in the way?

The Scrum Team

• Product Owner
• Development Team
• Scrum Master

Scrum Teams are self-organizing and cross-functional. Rather than being di-
rected by others outside the team, self-organizing teams choose how best to
accomplish their work. Cross-functional teams have all competencies needed
to accomplish the work without depending on others not part of the team.

The team model in Scrum is designed to optimize flexibility, creativity, and pro-
ductivity.

The Product Owner is the sole person responsible for managing the Product
Backlog. Product Backlog management includes:

• Expressing Product Backlog items

• Ordering the items in the Product Backlog to best achieve goals
and missions
• Optimizing the value of the work the Development Team performs
• Ensuring that the Product Backlog is visible, transparent, and clear
to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product
Backlog to the level needed.

The Product Owner may do the above work, or have the Development Team
do it. However, the Product Owner remains accountable.

6
The Product Owner is one person, not a committee. The Product Owner
may represent the desires of a committee, any changes must be addressed
through the Product Owner.

For the Product Owner to succeed, the entire organization must respect his
or her decisions. The Product Owner’s decisions are visible in the content and
ordering of the Product Backlog. The Development Team is not to be forced to
work from a different set of requirements.

Scrum Team Capacity

Scrum Teams should consist of 3 but upto no more than 9 participants. Having
more than nine members requires too much coordination.
Large Development Teams generate too much complexity for an empirical
process to be useful. The Product Owner and Scrum Master roles are not in-
cluded in this count unless they are also executing the work of the Sprint Back-
log. Methods to manage team capacity due to changes in business strategy
Note: when splitting and forming new teams you may need to establish new
internal scrum coaching.

Seeding method

• Split and Seed model, (1st Split and then add team members)
• Grow and Split: First grow, (Maximum 9 Members) thereafter Split into
Distributed Scrum Teams
• Virtual sessions: make best use of modern technology to facilitate
interactions. E.g. Team Viewer, Skype Cloud computing
• Place emphasis on Involvement Encouragement: get to know the
people who you are networking with better
• Establish and communicate regular core hour schedules
• Lower productivity levels due to international differences are to
be expected

Types of contracts

• Fixed Price: Because it’s based on an initial definition of scope it’s not
really Agile (ScrumBut)
• Time and Means/ Fixed Unit: Customer is charged based on Man
Hours or per Sprint

7
 Challenges

2016 2017 2016 2017

010101010101 010101010101
010101010101 010101010101
010101010101 010101010101

• Becoming self-organized (e.g. Daily Scrum)
• Going from a Hierarchical Structure to a Matrix organization
• Adhearing to and appliying the Scrum Methodlogy
• Trust in Team Management
• Teamwork between Product Owner and Development Team
• Scrum Master has little to no executable authority

The Development Team

The Development Team consists of professionals who do the work of deliver-
ing a potentially releasable Increment of “Done” product at the end of each
Sprint. A “Done” increment is required at the Sprint Review. Only members of
the Development Team create the Increment.

Development Teams are structured and empowered by the organization to

organize and manage their own work. The resulting synergy optimizes the De-
velopment Team’s overall efficiency and effectiveness.

Development Teams have the following characteristics:

• They are self-organizing. No one (not even the Scrum Master) tells the
Development Team how to turn Product Backlog into Increments of
potentially releasable functionality.

8

• Development Teams are cross-functional, with all the skills as a team
necessary to create a product Increment.

• Scrum recognizes no titles for Development Team members,

regardless of the work being performed by the person.

• Scrum recognizes no sub-teams in the Development Team, regardless

of domains that need to be addressed like testing, architecture,
operations, or business analysis.

• Individual Development Team members may have specialized skills

and areas of focus, but accountability belongs to the Development
Team as a whole.

Development Team Size

Optimal Development Team size is small enough to remain nimble and large
enough to complete significant work within a Sprint.

Fewer than three Development Team members decrease interaction and re-
sults in smaller productivity gains. Smaller Development Teams may encounter
skill constraints during the Sprint, causing the Development Team to be unable
to deliver a potentially releasable Increment.

Having more than nine members requires too much coordination.

Large Development Teams generate too much complexity for an empirical
process to be useful. The Product Owner and Scrum Master roles are not in-
cluded in this count unless they are also executing the work of the Sprint Back-
log.

The Scrum Master

The Scrum Master is responsible for promoting and supporting Scrum as defined
in the Scrum Guide. Scrum Masters do this by helping everyone understand
Scrum theory, practices, rules, and values.

The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master
helps those outside the Scrum Team understand which of their interactions with
the Scrum Team are helpful and which aren’t. The Scrum Master helps every-
one change these interactions to maximize the value created by the Scrum
Team.

Scrum Master Service and the Product Owner

The Scrum Master serves the Product Owner in several ways, including:

• Ensuring that goals, scope, and product domain are understood by

everyone on the Scrum Team as well as possible;

9
 • Finding techniques for effective Product Backlog management;
• Helping the Scrum Team understand the need for clear and concise
Product Backlog items
• Understanding product planning in an empirical environment;
• Ensuring the Product Owner knows how to arrange the Product
Backlog to maximize value
• Understanding and practicing agility
• Facilitating Scrum events as requested or needed

Scrum Master Service and the Development Team

The Scrum Master serves the Development Team by:

• Coaching the Development Team in self-organization and cross-

functionality
• Helping the Development Team to create high-value products
• Removing impediments to the Development Team’s progress
• Facilitating Scrum events as requested or needed
• Coaching the Development Team in organizational environments in
which Scrum is not yet fully adopted and understood.

Scrum Master Service to the Organization

The Scrum Master serves the organization by:

• Leading and coaching the organization in its Scrum adoption

• Planning Scrum implementations within the organization
• Helping employees and stakeholders understand and enact Scrum
and empirical product development;
• Causing change that increases the productivity of the Scrum Team
• Working with other Scrum Masters to increase the effectiveness of the
application of Scrum in the organization.

Scrum Values

When the values of commitment, courage, focus, openness and respect are
embodied and lived by the Scrum Team, the Scrum pillars of transparency,
inspection, and adaptation come to life.

Scrum Events

Prescribed events are used in Scrum to create regularity and to minimize the
need for meetings not defined in Scrum. All events are time-boxed events,
such that every event has a maximum duration.

10
Once a Sprint begins, its duration is fixed and cannot be shortened or
lengthened. The remaining events may end whenever the purpose of the
event is achieved, ensuring an appropriate amount of time is spent without
allowing waste in the process.

Other than the Sprint itself, which is a container for all other events, each
event in Scrum is a formal opportunity to inspect and adapt something.
These events are specifically designed to enable critical transparency and
inspection. Failure to include any of these events results in reduced trans-
parency and is a lost opportunity to inspect and adapt.

The Sprint

The heart of Scrum is a Sprint, a time-box of one month or less during which
a “Done”, useable, and potentially releasable product Increment is cre-
ated. Sprints have consistent durations throughout a development effort. A
new Sprint starts immediately after the conclusion of the previous Sprint.
Sprints contain and consist of the Sprint Planning, Daily Scrums, the devel-
opment work, the Sprint Review, and the Sprint Retrospective.

During the Sprint:

• No changes are made that would endanger the Sprint Goal;

• Quality goals do not decrease; and,
• Scope may be clarified and re-negotiated between the Product
Owner and Development Team as more is learned.

Each Sprint may be considered a project with no more than a one-month

horizon. Like projects, Sprints are used to accomplish something. Each Sprint
has a goal of what is to be built, a design and flexible plan that will guide
building it, the work, and the resultant product increment.

Sprints are limited to one calendar month. When a Sprint’s horizon is too
long the definition of what is being built may change, complexity may rise,
and risk may increase. Sprints enable predictability by ensuring inspection
and adaptation of progress toward a Sprint Goal at least every calendar
month. Sprints also limit risk to one calendar month of cost.

Cancelling a Sprint

A Sprint can be cancelled before the Sprint time-box is over. Only the Prod-
uct Owner has the authority to cancel the Sprint, although he or she may
do so under influence from the stakeholders, the Development Team, or the
Scrum Master.

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might
occur if the company changes direction or if market or technology condi-
tions change. In general, a Sprint should be cancelled if it no longer makes
sense given the circumstances. But, due to the short duration of Sprints,
cancellation rarely makes sense.

11
When a Sprint is cancelled, any completed and “Done” Product Backlog
items are reviewed. If part of the work is potentially releasable, the Product
Owner typically accepts it. All incomplete Product Backlog Items are re-
estimated and put back on the Product Backlog. The work done on them
depreciates quickly and must be frequently re-estimated.

Sprint cancellations consume resources, since everyone regroups in another

Sprint Planning to start another Sprint. Sprint cancellations are often trau-
matic to the Scrum Team, and are very uncommon.

Sprint Planning

The work to be performed in the Sprint is planned at the Sprint Planning. This
plan is created by the collaborative work of the entire Scrum Team.
Sprint Planning is time-boxed to a maximum of eight hours for a one-month
Sprint. For shorter Sprints, the event is usually shorter. The Scrum Master en-
sures that the event takes place and that attendants understand its pur-
pose.

The Scrum Master teaches the Scrum Team to keep it within the time-box.
Sprint Planning answers the following:

• What can be delivered in the Increment resulting from the upcom

ing Sprint?
• How will the work needed to deliver the Increment be achieved?

Artifacts

Product Backlog (owned by Product Owner)

• 16 Hour Rule (nothing noted as a single item which can’t be

handled within 16 hours)
• Sprint Backlog (Specific to the Sprint and subset of the Product
Backlog)

300 Task Rule

• Benchmark regarding Total Amount of Tasks during any given Sprint

Burn Down Chart

• progressive overview of task completion in accordance to timeline)

COMMON SCRUM TERMINOLGY

• Scrum Team (Project Team)

• Product Owner (Project Manager Authority)
• Scrum Master (Fascinator of meetings)
• Development Team (The Doers)


12
 • Sprint Burn-Down chart (a progressive overview of task completion
in accordance to timeline)
• Release Burn-Down Chart (Specific to the End User)
• Product Backlog List (PBL = Functionality/ Requirement list)
• Sprint Backlog List (SBL = List of Open Points)
• SPRINT (Period of Time for any given interval)
• Spike (Specific peaks in productivity, common in prototype phase)
• Tracer Bullet (Drone Spike = current status whose focus is on quality)
• Tasks (things that need to be done)
• Definition of Done (DoD = Handover Acceptance
Best practice: to be defined in advance)
• Velocity (Reaction Rate)
• Impediment (to put something into practice)
• Sashimi (different user stories being impedimental together)
• Abnormal Termination (changes outside the norm)
• ScrumBut (Agile but not quite scrum, potential counterproductive
procedure)

Scrum Limitations

• Geographically Dispersed Team

• Teams with very specialized skills
• Products or Services with external dependencies
• Mature products that need high levels of regression testing

OTHER ITERATVE METHODS

• Spiral Methodology
• Lean Kanban: Method for managing knowledge work which
balances the demand for work to be done with the capacity to
start new work. Intangible work items are visualized to present all
participants with a view of progress from task definition to
customer delivery. Team members “pull” work as they have
capacity, rather
than work being “pushed into the process when requested.
“Pulling as opposed to pushing the work in”
• Extreme Programming (XP) Factors

- XP Values
- Communication, Feedback, Simplicity, Courage

Roles in the XP approach include: Customer, Developer, Tracker, Coach

• Crystal Methods
• Dynamic Systems Development Methods (DSMD): An iterative and
incremental approach that embraces principles of Agile develop
ment, including continuous user/ customer involvement.

13
 • Feature Driven Development (FDD)
• Test Driven Development (TDD)
• Adaptive Software Development (ASD): Embodies the principle
that continuous adaptation of the process to the work at hand is
the normal state of affairs.
• Agile Unified Process (AUP)
• Domain-Driven Design (DDD)
• Lean Software Development (LSD): Translation of lean manufactur
ing and lean IT principles and practices to the software develop
ment domain. Adapted from the Toyota Production System, a
prolean subculture is emerging from the Agile community.

COMMUNICATION SKILLS IN THE AGILE WORLD

Qualitative Communication Patterns

• Effective verbal communication is evident the moment when the

meaning of the words expressed have been acknowledged by
the recipient as being understood
• When not clearly understood, reiteration is to be requested
• “Never take things for granted”
• Encode/ Decode with thoughtfulness

Encode Decode
Message

Sender Receiver

Message
Decode Encode

Verbal vs. Nonverbal Communication

• Verbal Communication is meaning of the words expressed to

convey the message
• Nonverbal Communication is how the words are expressed and
the body language accompanying the expression

Effective Communication Expression Method

14
 • Think before you speak
• Think before you react
• Observe and learn from how people react to you

Communication through Learned Patterns

• We communicate with patterns

• We learn the patterns early, continuously… and unconsciously
• Listen, listen, listen to yourself!
• Problems occur when we access the wrong response to a
perceived pattern
• New patterns can be learned through conscious effort

10 Key Communication Skills

• Know your Audience as well know the role of who it is that you are
communicating with
• Know your Content: be clear and concise, understand what it is
that you are trying to convey
• Be Specific: don’t generalize
• C3’s: Be Clear, Concise, and Complete: focus on the subject
at hand
• Practice Dynamic Listening: Listen so that the other person knows
your listening
• Think Proactively: know that making things happen evolves others
• Be Genuine/ Be Honest: Answer questions consistently and honesty
• Control Communications: Don’t let communications control you
• Listen and Control Non-Verbal (Body Language): Be aware of the
message you are conveying
• Ask Good Questions: Ask questions that enhance understanding,
don’t accept verbatim

Conflict Resolution Model

• Define the Conflict: Identify with what it is that the conflict

really about
• Determine the conflicting parties: what is it that needs to be
looked at
• Define what each party wants as resolution: a mutual understand
ing is required
• Determine the willingness to Resolve: separate the parties and
discuss rational solutions
• Confirm the conflict *** (Confirm early and often): smaller conflicts
often solve themselves
• Seek Resolution: Agree to joint resolution which brings the project
forward

15
 • Confirm agreement with all parties: don’t create situations
where parties are choosing sides

Tuckman’s 5 Stages of Developing of Team

• Form: Bring the parties together (put the puzzle pieces on the
table)
• Storming: Get to know the pieces of the puzzle
• Norming: Start putting the pieces together
• Performing: Things are moving forward, the puzzle is taking form
• Adjourning: Maturity of acceptance has been achieved,
team moves on to other things

AGILE THE GOOD AND THE BAD

• Leveraging measurements to change behavior: every project
will at some point have a red or yellow status. Your responsibil
ity does not include keeping everything incrementally in the
green. Your goal is to promote scrum advancements with moti
vation, thus move the project forward.
• Using non-Agile measures or Agile measures to confirm non-
Agile conditions: Agile concepts should not be used to measure
a non-Agile condition. (Comparing apples and oranges can
prove to be fruitful, comparing dogs and peanut butter won’t).
• Over reliance on Metrics: Thoroughly understand what’s behind
the numbers.
• The cost of measures: Numbers can be good, measures can be
useful they help us make decisions. Crunching the numbers is
not advisable. Understand that changes in direction need to be
guided in a structured and reasonable manner.
• The cost of the “convenient” measure: Results need to be in
alignment, although they may seem right, validity should
always be confirmed. Check, double check before conveying
results.
• Bad analysis: due to different personalities or frameworks, when
viewing the status report the understanding of the parameters
may differ from one person to another.
• Using Risk analysis: following and acting upon an opinionated
“what if” is a greater risk
• Business-Driven Engineering: That Product owners have great
control of what is being done, the project owner can’t afford
to view the project only from a business perspective. In order
for success to be achieved, the project owner must be aware
of the engineering manufacturing requirements.
• Naivety of the process: e.g. “All for one, one for all” with the
acceptation of situation xyz.

16
 • Short term thinking over long term plans: Due to sprint methodology,
thought process is short term. Development team has their “eye on
the ball”, who is it that has their eye on the long term perspective?
• The Agile professional in the corporate plan: The “corporate
role definition” is for many firms is “work in progress”.
• The Transparency myth: implies you can identify low performers:
that sprint intervals may not include all parameters, old school
mentality may be evident. Unknown blockers may be in place.
• Short term value over long term value: Sprint focus is on deliver
immediate gratification (short term value being the nature of
the sprint). The short term ramifications on the long term plan
need to be understood.
• Agile is commonly used to create an emergency situation:
Urgent methodic may be a motivation factor for some but as
well stress for others.

8-Step Process for Leading Change

• Establish sense of Urgency
• Creating the Coalition
• Developing the Vision
• Communication the Vision for Buy-In
• Empowering a Broad Based Action
• Focus on Vision
• Incorporation Change into the Culture

Release Planning

Release 0.5 Release 1.0 Release X.Y

Sprint 1 Sprint 2 Sprint 3 Sprint 4

• Release planning is conducted by Product Owner in
cooperation with customer and other stakeholders
• Release is defined at system/ program level
• Average duration is 3 months
• Features must be Prioritized

17
 Sprint Planning
The Sprint Backlog consist of the following:

• The outline in regards to the goal or status the Sprint is to

achieve
• Selected Items from the Product Backlog
• Detailed Plan for compleing the slected items with in Sprint
increment

Estimations

• No time-based units
• Utillize relative effort based units

Estimation Roles

• Start with a reference for story points

• Reference story points doesn’t need to be a user story from
current project
• Keep story small, simple and clear to ensure familiarity
• Compare other stories to that reference
• Estimation is an approximation
• Conduct periodic re-estimations

Estimation Handling

• Utilize Historical Data

• Discuss Blind as well as Highest and Lowest estimations
to reach an agreement

Monitoring and Metrics

• Burndown Charts: used to show remaining work to be complet-
ed and demonstrate a simplified view of progress
200

180

120

80

40

0
0 12 3

18
 • Sprint Goal Success Rate (High)
• (Escaped) Defects (Low)
• Velocity (High and Sustainable)
• Satisfaction (High)
• Team Member Turnover (Low)
• Burn Down Rate (High)

Inforamtion Radiator

• Burndown-Bar (used to display Estimated Time to Completion)

500

400

300
STORY POINTS

200

100

0
0 1 2 3 4 5 6 7 8 9 10 11 12
-100

-200

-300

Burn-Up-Chart

• Used to show the Volume of Completed Stories in that a line or

bar is used to show sprint performance

800

700

600

500

400

300

200
Done
100

0
1 2 3 4 5 6 7 8 9 10 11 12

19
Sprint Progress Monitoring

• White Board Technique

Sprint Goal To Do In Progress Done
The goal of this
Sprint is to make Item
#1 t 2,6

deliver the complete t 3,5 t 2,

1

product assembly
in a form that all t 2, t 2,1
6
affilated parties can Item #2
t2
,7
Item #4

experince the full t 3,

8
t 4,1
t 1,
6
process
Sprint Burn-Down Chart t 2,7
t 1,5 t 2,7
100 Item #5 t 4,4 t 3,1
80 t 5,6
t 5,4 5
70 t 2,1 t 3,4 t 4, t5
,5
60
50
40
30 3 t 3,2
20 Item #
,5
10 t6
0
1 2 3 4 5 6 7 8 9 10 t 2,5 t 5,1

Workspace

• Co-located in a single room (Osmotic Communication

• Face-to-Face Communication
• Simple Communication Methods
• Be aware of what others are working on (Daily Scrum)
• When required, ask for help/ support one another
• Ensure Backlog and charts are readily available

20