Agile in a Nutshell

Waterfall vs. Agile

To plan or not to plan?

Plan is nothing, planning is everything.

Eisenhower

4
Waterfall vs. Agile

Agile? Scrum?

Sprint

6
 Agile? Scrum?

The
Scrum Guide

8
The
Scrum Guide

Scrum

10
An Introduction to Agile Knowledge Domains

11

Definable work vs. High Uncertainity Work

Definable work High uncertainity work

Clear procedures New design, problem solving
Domain and processes are well Not-done-before
understood
Low levels of uncertainity and risk. High rates of change, complexity, and
risk.

12
 The Agile Manifesto and Mindset

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

Individuals and
Processes and tools
interactions

Working software Comprehensive

(product) documentation

Customer collaboration Contract negotiation

Responding to change Following a plan

13

The Agile Manifesto and Mindset

12 Principles
1. Customer satisfaction through early and
continuous software (product) delivery
2. Accommodate changing requirements throughout
the development process
3. Frequent delivery of working software (product)
4. Collaboration between the business stakeholders
and developers throughout the project
5. Support, trust, and motivate the people involved
6. Enable face-to-face interactions
7. Working software is the primary measure of
progress
8. Agile processes to support a consistent
development pace
9. Attention to technical detail and design enhances
agility
10. Simplicity
11. Self-organizing teams encourage great
architectures, requirements, and designs
12. Regular reflections on how to become more
effective
https://agilemanifesto.org/iso/en/principles.html
Empirical Process Control

Empirical process control is used by

scrum through a process of frequent
inspection and adaptation. Because
our business reality includes process
that are not always perfectly defined,
and can generate unpredictable
results, adaptable and iterative
frameworks such as agile still rely on
controls.

15

Agile Roles and Product Owner Team

Responsibilities
Product vision and roadmap Estimate
Manage product backlog Plan and commit for the iteration
Rank and prioritize the backlog Execute the iteration
Set clear expectations for acceptance Demo
Provide necessary details at the Communicate
appropriate time for Development
Unit
Communicate
Agile Practitioner

The success of AGILE

Establishing practices and rules,
shielding the team and removing
obstacles
Representing management to the
project
16
Scrum Cycle

17

Agile Implementation

18
 Minimum Viable Product (MVP)
Minimum Marketable Product (MMP)

19

ACTIVITY:

TO MOVE TO A NEW HOUSE:

WHAT ARE THE MAIN FEATURES?

WHAT ARE THE USER STORIES?
 Some Agile Terms: Chickens And Pigs

21

Two Strategies for Agile

To adopt a formal agile approach,

intentionally designed and proven to
achieve desired results.

To implement changes to project

practices in a manner that fits the
project context to achieve progress on a
core value or principle

*The end goal is not to be agile for its own sake, but rather to
deliver a continuous flow of value to customers and achieve
better business outcomes.
 Agile in Action
TOPIC B

23

Product Roadmap

24
 Agile Planning

Agile Release Planning

Provides a high-level
summary timeline of the
release schedule based on
the product roadmap and
vision for the
evolution.

25

User Stories

Releases

Features Features Features

Product backlog

Iteration backlog

User
User
stories
User
stories
stories
26
User Stories
As the project commences, the scope of
work comes from the product backlog.
User stories are the backbone of what
becomes a part of the backlog.
Its a device used by agile to gather the
requirements that are needed to
eventually begin development of a
feature.
The user story is used to capture the

desired end result.

requirement in a simple way.

It is the primary task of the product manager
to ensure stories are captured.
One tool used is a simple document template
called a Story Card.

User Story Card

28
 Product Backlog

Feature ID User Story ID Theme As a/an Notes Priority Status

If games cannot be saved and
Create a new game by entering a name returned to, the description is
101 A11Game Moderator and an optional description I can start intiviting estimators. unecessary. Required done

The url should be formatted so

102 A12Game Moderator where they can Access the game We can start the game
Join a game by encering mu name on
103 A13Game Estimator I can participate done
Start a round by entering an item in a
102 A14Game Moderator single multi-line text field We can estimate it done

105 A15Game Estimator for done

Have the application respond quickly to

106 A16Game Participant my actions implementation detail To do
Non- Have nice error pages when something
107 A17 functional User goes wrong developers done

Non- Edit an item in the list of items to be the teams understanding of the
108 A18 functional User estimated team

Export a transcript of a game as a I can futher process the stories Exported file should be directly
109 A19Game Moderator CSV file and estimates importable back into the system done

29

Estimation How to Estimate Better?

Estimating User Stories Story
Points
Before the work can begin, estimates must
be put against the user stories to allow for
proper forecasting of the work.
A user story is the start of the input for
determining what to develop. But just as with
other methodologies and disciplines, you
must have an estimate of the work before
you assign the work and provide a realistic
timeline to your stakeholders.
Teams use relative estimating to estimate the
user story or product backlog
The unit of measure is the

should be able to translate between story points and man

hours (or other units) as needed.
The Fibonacci sequence (1,2,3,5,8) as the
estimating standard for near-term work (sprints
within current minor release) and 13,20,40,100 to
represent for far-term work.

Estimating User Stories / Backlog

Most User Stories will fall here.

Represents full functionality that can be User stories in future major
accomplished in a sprint. releases.

1 2 3 5 8 13 20 40 100

User stories in current minor releases.

EPIC:
May or may not
Defects, small enhancements, etc. Team cannot
need to be
estimate
decomposed
effectively given
further.
current
Very large user understanding of
stories that the work.
team can handle
but will need to
break down by
decomposition

32
Estimating User Stories / Story
Points

Example: Consider five stories, each of varying

size.
In comparing the stories we want to determine
a baseline first. (i.e. A story worth 2 points.) A B C D E
Looking at the 5 stories we would say that
story D represents a size that is not the largest
nor the smallest so we will say story D is 2
points.
Now that we have a baseline we can
determine the points for the other stories:

Estimating Tool: Planning Poker

A technique that is common in the agile User Story: As a/an end user I would
framework is the empowerment of the like to have my software brew my
team to contribute to the estimating coffee so that
process. tool for it.
Individual stories are presented for
estimation.
0 1/2 1 2 3 5 8 13 20 40 100
After a period of discussion, each
participant chooses from his own deck the
numbered card that represents his
estimate of how much work is involved in
the story under discussion. When considering the work effort, think in
terms of ideal time that the work would
All estimates are kept private until each take in an uninterrupted setting.
participant has chosen a card.
At that time all estimates are revealed and
discussed.

34
 Anatomy of an Iteration / Sprint

35

Iteration / Sprint Backlog

Goal of creating an Iteration /

Sprint Backlog:
Determine resource availability
Review stories by priority
Stories are broken down into tasks
Team members pick tasks based on
availability, knowledge level, and
length of sprint.
Team provides actual estimates for
the tasks
Team ensures all work can be
completed within the Sprint
 Burndown Chart

37

Daily Stand Up Meeting

Daily 15 minutes status meetings

Team stands in a circle facing each
other. Each team member answers 3
questions:
What have you done since yesterday?
What will you have done by this time
tomorrow?
Is there anything you need help
resolving?
Use of the Sprint Burn-down chart is a key
tool used in the meeting.
Iteration Demo
(Review Meetings)

The iteration demo is invaluable for

keeping stakeholders up with the speed of
the progress of product development. It
allows them to feedback and discuss with
the Product Owner and team any possible
amendments to the Product
Backlog which would help to maximize
value.

Retrospectives

The purpose of the Iteration

Retrospective is to plan ways to increase
quality and effectiveness.
The Agile Team inspects how the last
iteration went with regards to individuals,
interactions, processes, tools, and their
Definition of Done. Inspected elements
often vary with the domain of work.

Assumptions that led them astray are

identified and their origins explored. The
Team discusses what went well during
the Sprint, what problems it
encountered, and how those problems
were (or were not) solved.
40
 Retrospektives and Lessons Learned

Gathering lessons learned about

improvements and recognizing
achievements.
Encourage the team to review what
went well and what could be better.
Everyone should be included and
their contribution is respected.
Avoiding the blame game and
focusing on learning and growth
opportunities.

Agile Retrospectives Traditional Lessons Learned

at the end of iterations at the end of projects
41

Throughput and
Velocity Tracking
The word velocity is often used during an agile project. The main
idea behind velocity is to help teams estimate how much work they
can complete in a given time period based on how quickly similar
work was previously completed.

WIP (Work In
Progress)
Throughput =
Lead Time

In Agile, throughput measures the average number of work items

processed per unit of time. In a Kanban system, for example, as
work is visualized in cards, throughput is measured based on how
many Kanban cards were finished in a given period (weekly,
monthly, etc.)

42
 43

Definition of
Done

44
 Definition of Done Key Characteristics

The DoD is a checklist of value-based activities to produce the

software or system.
This allows focus to be placed on value added steps and to eliminate waste.
The DoD is the primary reporting mechanism for team members.

The DoD is an auditable checklist

It validates whether all major tasks are accounted for.
The DoD is not static
to evolve.
The DoD is informed in reality.

Reference: www.scrumalliance.org/articles/105-what-is-definition-of-done-dod

45

ACTIVITY: AN AGILE
ITERATION EXPERIMENT
-
Collaborative Game

20 min Sprint duration

Team building
Team responsibilities
Story point estimates
Iteration backlog preparation
Doing the work

46
 Agile Teams
TOPIC C

Agile Team Roles 1 Cross Functional Team Member

T-shaped
Cross-functional teams consist of team members with all the skills necessary to produce a
working product.
In software development, cross functional teams are typically comprised of designers, developers,
testers, and any other required roles.
The cross functional development teams consist of professionals who deliver potentially
releasable product on a regular cadence.
Cross functional teams are critical because they can deliver finished work in the shortest
possible time, with higher quality, without external dependencies.

48
T-shaped / I-Shaped People

49

Agile Team

Rapid product development

3 to 9 members.
Ideally to be colocated.
100 % dedicated to the teams
Self managing teams servant leadership
Cross-functional agile teams produce functional product increments frequently.
The more the team limits its work in progress, the more likely its members can collaborate to
expedite work accross the board.
Collaboration through pairing

50
Agile Team Roles 2 Product Owner

The product owner is responsible for guiding the direction of the product.
Product owners rank the work based on its business value.
Product owners work with their teams daily by providing product feedback and setting direction
on the next piece of functionality to be developed / delivered. That means the work is small, often
small enough to be described on one index card.
The product owner works with stakeholders, customers, and the teams to define the product
direction.
Typically product owners have a business background and bring deep customer expertise, such
as product managers. Product owners need training on how to organize and manage the flow of
work through the team.
In agile, the product owners create the backlog for and with the team.
The backlog helps the teams see how to deliver the highest value without creating waste.
A critical success factor for agile teams is strong product ownership. Without attention to the
highest value to the customer, the agile team may create features that are not appreciated, or
otherwise insufficiently valuable, therefore wasting effort.

51

Agile Team Roles 3 Agile Practitioner / Facilitator Servant Leader

This role may be called a project manager, scrum master, project team lead, team coach,
or team facilitator.
All agile teams need servant leadership on the team.
People need time to build their servant leadership skills of facilitation, coaching, and impediment
removal.
Initially, many organizations invite external agile coaches to help them when their internal
coaching capability is not yet fully developed.
External coaches have the advantage of experience, but the disadvantage of weak relations in the
client organization.
Internal coaches, have strong relationships in their organization, but may lack the breadth of
experience that would make them highly effective.

52
Characteristics of
Servant Leadership

53

Things to Remember as a
Servant Leader

Place yourself in the role of between a

contributer, collaborator and leader.

tactical aspects of the work you also

must act as a coach and advocate for the
team. Monitor the dynamics of the team.

healt

54
Empowering the
Team: Servant
Leadership
Is the practice of leading Characteristics:
through service to the team. Promoting self
Role: To facilitate the awareness
discovery and definition of Listening
agile. Serving those on the team
Helping people grow
Coaching vs. controlling
Approach work in this order:
Promoting safety, respect,
Purpose : Why and trust
People Promoting the energy and
Process intelligence of others.

55

Facilitate
From managing coordination to facilitating collaboration, impartial
bridge-builders.
Remove organizational impediments
Pave
Servant leaders work to fulfill the needs of the teams, projects and
organization.
Educate stakeholders around why and how to be agile.
Support the team through mentoring, encouragement and support.

56
Role of a Project
Manager in an Somewhat of an unknown!
Agile Pragmatic agile practitioners and organizations realize that project
managers can add significant value in many situations.
Environment
Project managers use Servant leadership
In high-change projects, there is more complexity than one person can manage.
Instead cross functional teams coordinate their own work and collaborate with the
business representative (the product owner)

The value of project managers is not in their position but in their ability to make
everyone else better.

57

Successful Agile Teams

Attribute Goal

Dedicated people Increased focus and productivity

Small team, fewer than ten people

Cross-functional team Develop and deliver often

members Deliver finished value as an independent team
Integrate all the work activities to deliver finished work
Provide feedback from inside the team and from others, such as the
product owner

Colocation or ability Better communication

to manage any Improved team dynamics
location challenges Knowledge sharing
Reduced cost of learning
Able to commit to working with each other

58
Successful Agile Teams

Attribute Goal

Mixed team of generalists Specialists provide dedicated expertise and generalists provide
and specialists flexibility of who does what
Team brings their specialists capabilities and often become
generalizing specialists, with a focus speciality plus breadth of
experience across multiple skills.

Stable work environment Depend on each other to deliver

Agreed upon approach to the work
Simplified team cost calculations (run rate)
Preservation and expansion of intellectual capital.

59

Agile Team Dedication

Multitasking Dedicated
teams

Task swiching productivity loss: 20 40 %

60
 Team Workspaces

Some teams work in a room together

Some teams have a team workspace for their standups and charts
Quiet areas and social spaces (caves and commons)
For distributed teams: how much virtual and how much physical?

Remote pairing: use virtual conferensing tools to

Fishbowl window: longlive video conferencing
share screens, including voice and video links.

Form teams by bridging people with different skills from different functions together. Educate managers and
leaders about the agile mindset and engage them early in the agile transformation.

61

High
performance
team
characteristics A high performance team:
1. Identifies measurable tasks
2. Have clear prioritization
3. Achieve team agreement.
DoD)
The simple list of activities that add verifiable
and demonstrable value to the product.

Many levels = Many DoDs

Feature: Story or product backlog item
Sprint: Collection of features developed in the sprint
Release: Potentially shippable state

62
Tools to Keep the
Team Strong
Project Charter

An Agile Project Charter answers:

Why are we doing this project: The

vision
Who benefits and how?

project? The release criteria

How are we going to work together?
the intended flow of work

Tools to Keep the Team Strong - Project Charter

64
Tools to Keep the
Team Strong
Team Charter
Team charter:
Team values, such as sustainable pace
and core hours
Working aggreements, such as what

work, what
judge completeness consistently,
respecting the timebox, or the use of
work-in-process limits
Ground rules, such as one person talking
in a meeting
Group norms, such as how the team
treats meeting times.

Tools to Keep the Team Strong Team Charter

Agile teams use variety of tools and methods to ensure that the risks of team dynamics
are mitigated.
The Team Contract Team Charter: Also known as a Working Aggreement or Ground
Rules, the contract is a simple document which can be changed every iteration or sprint,
or whenever necessary. Anything goes here that all developers agree on.

66
Team Trust
Agile principles require that you build projects around motivated individuals. Give them
the environment and support they need to get the job done, and trust in them that they
can achieve their tasks.
Trust is a core tenet of Agile. Once trust is broken, it is not easily recovered.
Trust allows the team to stay problem focused, it promotes efficient
communication, and it improves the quality of collaborative outcomes.
Trust has four core elements:
Element Description

Honesty
The team member acts with integrity and uphold core values.

Openness Open to share, learn new things, consider alternate

approaches

Consistency Behaviour and reactions that come to be expected.

Respect Treat people with dignity and fairness.

67

Team Collaboration

Agile encourages close customer communication and collaboration.

The customer is represented in the design and requirements documents.
For communication with the team that involves live communication (a core tenet of agile),
documentation is less significant on the project compared to team meetings.
These meetings are essential to team collaboration on an agile project:
Release planning meeting
Iteration planning meeting
Daily standup meeting
Review / Demo meeting
Retrospective meeting

Remember the Manifesto

68
ACTIVITY:

YOUR PROJECT?
HAVE YOU DISCUSSED THEM WITH THE
TEAM OR STAKEHOLDERS?
WHY ARE DODS A PART OF TEAM
PERFORMANCE?

69

Common Agile Practices

TOPIC D
 Common Agile Practices

PRACTISE LEAD / FACILITATOR PARTICIPANTS AIM FREQUENCY DURATION of MEETING

First planning meeting can be

Team and customer The major features pointed, no. of iterations, iteration Depends on release length.
RELEASE PLANNING Customer more than an hour (maybe 2
related participants durations, major milestones. From 2 to 12 months.
half day meeting)

To develop and refine the product backlog items, to

Any time - prior to
BACKLOG PREPARATION and refine the items while more information be available,
Product Owner Team iteration start - midway in An hour per week
REFINEMENT to reach "definition of ready" for each backlog item in
the iteration
order to make them processed.

User story decomposition - decision on what

Product owner &agile At the beginning of the
ITERATION PLANNING Team userstories to be included in the iteration - An hour per iteration week.
coach iteration
negotiations - estimations - sharing task responsibilities

Each team member: What did I complete since the last

Product owner &agile
DAILY STAND-UPS Team standup, what do I plan to do today, Do I come across Everyday 15 minutes!
coach
any impediments, do I need help?

Product owner, agile

REVIEW (DEMONSTRATION) Team to demonstrate the work done, get validation At the end of iteration /
Product Owner coach, customer, An hour per iteration week
MEETINGS from customer. Once in 2 weeks
related participants

Team to understand its own performance, velocity, An hour per iteration week /
Product owner, agile
RETROSPECTIVE MEETINGS Team throughput, wastes, root causes, prioritized action At the end of iteration not to exceed 3 hours at
coach
items. once.

71

Leadership Techniques for Team Commitment

The agile practitioner evolves his team from the perspective of:
Teaching
Teaching: Showing the student of Agile the rules to buy into the

Coaching: Helping the team member take what they have learned
and use it on a daily basis as part of their operational approach
and way of thinking. Coaching
Advising: Your goal is to be able to step away from your role of
teacher or coach once the team has become precisely what agile
desires: a self empowered team that needs only occasional

Advising

This concept mirrors that of the Aikodo which guides a

person from stage of innocence to sophistication to alertness /

72
 Value Delivery And Prioritization
TOPIC E

What is Value is the relative worth of something in comparison to other items.

In value driven planning under Agile, the value of a feature is related to the relative return on
investment (ROI) in relation to other prioritized features.
To deliver value, the feature or product must be relatively greater in its ratio of value and cost
compared to the current state. High value at a high cost may not be treated by the customer
as high value.

BENEFITS
VALUE =
COST

74
75

76
 80/20
77

Plan Driven Projects

Value
Focuses on realizing targets and milestones
of completion instead of incremental
delivery. It is possible to not see any Release milestone
delivery at all until a first milestone release
well into the project.
Task lists assembled from the project A rigorous schedule, change control process and
risk mitigation strategy exists in this stage to help
schedule assist the team in reaching the the project reach the finish line but no incremental
overall project objective. This is also known deliveries occur.
as the Work Breakdown Schedule (WBS)
Plan Driven planning is very often used in
the Waterfall methodology. Performance
 Value Driven Projects

Value Driven Planning focuses on achieving results as quickly as possible, with

less intense wins occuring over time.
The largest amount of value is addressed first, as is shown below.

Value Barely good enough?

Time

79

Anti Value and Risk Mitigation

Consider that issues and risks exist as

Value Anti value
your product, which should always be
intended to add value. Water-tight boat hull epoxy Cracks in the hull
Risks erode value and should be
Fuel efficiency gasoline Rogue particulates from the
refinement process
products value. High strength concrete Ineffective pouring methods
Anti value is the antitheseis of value. Bug- free product code Incomplete code branches at
Consider these examples: launch.
WASTE - MUDA

81

Value Stream Analysis and Value Stream Map

82
Tools used to optimize the Value Stream Cycle and Lead Time

Cycle time: The number of days needed between feature specification and production delivery.
A shorter cycle indicates a healtier project.

Lead time: The time between the initiation and delivery of a User Story.

83

Tools used to optimize the Value Stream - Kanban

Is a scheduling system used in lean and Just in Time production so that inventory levels can be aligned with
consumption.
Controls the production chain to ensure that not too much or too little of something is produced.
Is not an inventory control system.

Advantages:

Dramatically reduce inventory levels

Increase inventory turnover
Enhance supplier / customer relationships
Improve the accuracy of manufacturing schedules

https://www.youtube.com/watch?v=5izyN66PTxs
https://www.youtube.com/watch?v=aeo1JcdHjGU
https://www.youtube.com/watch?v=ueVXZUaWhYw

84
 Tools used to optimize the Value Stream - Decomposition Techniques
in Agile
User story is a requirement of a system to be developed, written in a
simple format, such as:

(User role)
want (goal)
So (business value)

https://www.youtube.com/watch?v=nE8ALJ2M004
https://www.youtube.com/watch?v=v5rIRlfXz4k

85

Decomposition
Steps: Using
Personas

86
Quality Management in Agile Processes
Since agile is a focus on frequent and early progress and value to the customer, you must include quality
control in every phase of development, rather than just a distinct phase of the project.
Because your product is developed iteratively, every change to it should be considered potentially
harmful to its end state.
Tools at your disposal are Verification and Validation : independent procedures that are used together
for checking that a product, service, or system meets requirements and specifications and that it fulfills
its intended purpose.

Validation Verification

The assurance that a product, service or The evaluation of whether or not a product,
system meets the needs of the customer service, or system complies with a regulation,
and other identified stakeholders. It often requirement, specification, or imposed
involves acceptance and suitability with condition. It is often an internal process.
external customers. Contrast with Contrast with validation.
verification.

87

Adaptive Planning
TOPIC F
The Five Levels of Planning

Level What it is Frequency Who

Portfolio Vision Statement 1x 2 x/ year Product owner and

executives
Product roadmap Product evolution 1x-2x /year Product owner and
over time executives
Release Features / user 3x-4x/year Team, product owner,
stories stakeholders.
Iteration Features (user Every iteration Team and product owner
stories and tasks)
Day Tasks, burndown / Every day The team
to-do items

89

The Law of Diminishing Returns

In do significant up-front design work In Waterfall be expected to do so.

The agile manifesto says that Continuous attention to technical excellence and good design
enhances agility It does no design or documentation before you build

So how do you know how much is considered enough design? Consider the law of
diminishing returns which makes it clear to stop once the effort trumps the return.

90
Just Barely
Good Enough
Just Barely Good Enough (JBGE): a concept from agile modeling that states
that work should involve a sufficient level of quality and performance but no
more.

According to the law of diminishing returns, the ratio of value over time
begins to wane.
Rather than continuing to develop additional product enhancements, JBGE
suggests that once the customer confirms acceptance of the feature,
additional work would be wasteful.
Although JBGE occurs during iterations, (the build portion) the decision to not
develop additional items of a feature is a result of the JBGE data points when
performing subsequent iteration planning sessions.

91

The Last Responsible Moment (LRM)

You know the least early on, so early decisions

should feel less confident.
Early decisions are more risky due to the impacts
of pending change.
Time and effort making decisions on things you
will not do for a while is wasted effort you may
never actually need what was decided (think
requirements analysis for low priority items).
Focus on what you know today and assess the
risk of the unknown.
Do not spend much time on something that likely
will change by the time you touch it.
Not every decision needs to be made, at least not
now.

https://timelessagility.com/the-last-responsible-moment/

92
Rolling Wave Planning and Progressively Elaboration

The more you know about something, the easier it is to estimate. The less you know, the
harder it is to estimate.
It is important to highlight a key set of tasks and a well-defined work breakdown for the near
term activities and
Rely merely on milestones for futurework. As the approaches, you break down the milestones
into tasks.

93

Continuous Planning
Each cycle feeds the next.
The agile practitioner and the planning team are likely involved in a number of
planning and review meetings concurrently.

94
 Agile Measurement
TOPIC G

Documentation Progress Reports

Although Agile and Lean concepts recommend eliminating waste, an essential part of stakeholder
involvement is the progress report.
An Information Radiator is a large display of critical team information located in a spot where
people can see it as they work or walk by.
A good information radiator:
Is large and easily visible to casual observer
Changes over time
Is understood at a glance
Is easily kept up to date
Examples of information radiators:
customer demos,
the vision statement,
release and iteration plans,
burn-up charts: a burn up chart tells how much work the project contains and how much scope
has increased at each iteration.

96
Information Radiators

97

Tools used in Agile Measurements

Metrics focusing on VALUE
Predicting the completion and predictive measurements
Traffic lights and watermellon projects
Agile : finished work on a regular basis.
Surrogate measurements (like percentage done) vs. emprical measurements
Qualitative as well as quantitative
AGILE TEAMS MEASURE RESULT
The smaller the chunk of work, the more likely people are to deliver it.
Learning learning while delivering.

Teams might discover it can take four to eight iterations to achieve a stable velocity.
The teams need the feedback from each iteration to learn about how they work and
how to improve.

98
 Measurements in Agile Projects Iteration Based Agile Teams

Velocity: the sum of the story point sizes for the

features actually completed in this iteration, allows the
team to plan its next capacity more accurately by
looking at its historical performance.

99

Velocity Chart

Is tracked on a burndown chart as a depiction of

the total task points remaining per iteration.
Once the team knows their burndown rate it
allows them to determine their ability to meet
their project commitments
To calculate velocity a team first has to
determine how many units of work each task
is worth and the length of each interval.
During development the team keeps track of
completed tasks and at the end of the interval,
counts the number of units of work completed
during the interval.
 Velocity Key Things to Remember

Objective: Customer satisfaction

Measure: Stories (or story points) delivered; ideal hours

delivered. Only completed items.

Trend: An upward or stable trend is expected.

When measured: Velocity is a continuous measure .

101

Measurements in Agile
Projects Kanban Boards

When teams depend on external people or

groups, they need to measure cycle time to
see how long it takes for the team to
complete the work. They need to measure
lead time to see the external dependencies
after the team completes its work. Teams
can also measure the reaction time, the
time from ready to the first column, to see
how long it takes them on avarage- to
respond to new requests.
 Lean Kanban and Some Agile Methodologies
TOPIC H

The Lean Agile and Kanban

FDD: Feature Driven Development

AUP : Agile Unified Process
XP : Extreme Programming
DSDM : Dynamic System Development Method

Agile Practice Guide, Project Management Institute and Agile Alliance, 2017, Figure 2-4, Page 11. 104
 Lean, Agile and Kanban

Agile and Kanban : descendants of lean thinking.

All focuse on:
Delivering value
Respect for people
Minimizing waste
Being transparent
Adapting to change
Continuously improving

Scrum, XP, and Lean / Kanban focus on very different areas. Scrum is
mainly focused on project management: what work is getting done,
and make sure that it is in line with what the users and stakeholders
need. XP is focused on software development: building high quality
code well designed and easy to maintain. Lean / Kanban is a
combination of the Lean Mindset and the Kanban method, and
teams use it to focus on continually improving the way that they
build software.

105

Kanban

106
Kanban

https://www.atlassian.com/agile/kanban/boards

107

Kanban

Tablo A3-3. Defining Principles and Properties of the Kanban Method

Agile Practice Guide, Project Management Institute and Agile Alliance, 2017, Table A3-3, Page 104.
108
Scrum vs Kanban

Agile Practice Guide

109

Extreme Programming

eXtreme Programming (XP) is a software development method based on frequent cycles.

The Practice Areas of eXtreme PRogramming

Agile Practice Guide, Project Management Institute and Agile Alliance, 2017, Table A3-2, Page 102.
110
 Crystal Methods

The Core Values and

Common Properties of Crystal

Table A3-4. The Core Values and Common

Properties of Crystal
Figure A3-3. The Crystal Family of Methods

111

Scrumban

112
Feature-Driven Development Method

Feature-Driven Development (FDD) was developed to meet the specific needs of a

large software development project. Features relate to a small business value
capability.

113

Dynamic System Development Method

DSDM is known best for its emphasis on constraint-driven delivery. The framework
will set cost, quality and time at the outset and then use formalized prioritization of
scope to meet those constraints.

114
Agile Practice Guide, Project Management Institute and Agile Alliance, 2017, Figure A3-5, Page 110.
Agile Modeling

Agile Modeling (AM) is a both management style and a system of discipline used for effective
modeling and documentation of software based systems. It is not a complete software process
but it does complement the agile framework with recommendations for effective
communication and documentation tools.
The term was coined in 2002 by Scott W. Ambler in his book, Agile Modeling: Effective
Practices for eXtreme Programming and the Unified Process. Ambler continues to evolve the
concept on his web site, www.agilemodeling.com
Ambler states that an art, not a science a collection of values, principles, and
practices for modeling software that can be applied on a software development in an effective
and light weight manner.
Assumes simplicity and embraces change.
There are a number of specific best practices in the use of agile modeling:

115

Best Practices of Agile Modeling

Agile modeling is a discipline that is still under development!

116
Reflective Questions:

1.
2. Who manages the backlog refinement activities?
3.
4.
5. Who decides the magnitude of items to be
included in the sprint?
6.
7. You are an agile coach. Describe your role.

117