Agile Project Management: Agile, Scrum,

Kanban & XP

By GenMan Solutions
 Project Management: Need for change

• Time bounded
• Requires definitive effort
• Needs to be well planned
• Must be completed within the assigned budget
Project Management: Need for change
Processes can’t be left behind

Waterfall Model
 Project Management: Need for change
Flaws and weaknesses in historical Time required to push changes
approaches to project management and the
requirements in the current period

Front end Back end

DNS Payment
……..
Routes interface

Example: Any Mobile Application

 Project Management: Need for change
Waterfall Model
Project Management: Need for change

More
More Control
More Control on
Control on your
on your project
your project
project 01

02 Better Productivity & Quality

Higher Customer Satisfaction 03

04 Higher Return on Investment

What is Agile?
 What is Agile?

• Iterative approach to Software delivery

• Delivering faster in less time and less
money
• Ability to create and quickly respond to
change
• Philosophy to rapidly deploy an
application
• Fully loaded tool-kit
• Just a mindset or way of thinking
Manifesto for Agile Software Development

We are uncovering better ways of developing

software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.

Source: https://agilemanifesto.org/
Agile Manifesto & Principles
 Agile Manifesto & Principles

Agile Manifesto

Agile Principles

Agile Alliance:
www.agilealliance.org
Manifesto for Agile Software Development

We are uncovering better ways of developing

software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.

Source: https://agilemanifesto.org/
Individuals and interactions over processes and tools
Working software over comprehensive
documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Agile Principles
Agile Principles

Customer Collaboration over

contract negotiation ?
Violating our principle that says the
developers should be working with the
business owners every day?
 The Agile test
1. Does what we’re doing at this moment support the early and continuous delivery of valuable software?
2. Does our process welcome and take advantage of change?
3. Does our process lead to and support the delivery of working functionality? Are the developers and the product
owner working together daily?
4. Are customers and business stakeholders working closely with the project team?
5. Does our environment give the development team the support it needs to get the job done?
6. Are we communicating face to face more than through phone and email?
7. Are we measuring progress by the amount of working functionality produced?
8. Can we maintain this pace indefinitely?
9. Do we support technical excellence and good design that allows for future changes?
10. Are we maximizing the amount of work not done — namely, doing as little as necessary to fulfill the goal of the
project?
11. Is this development team self-organizing and self-managing? Does it have the freedom to succeed?
12. Are we reflecting at regular intervals and adjusting our behavior accordingly?
What Agile is not?
 Agile is not…
• A specific way of doing software development
• A framework, standard or a process
• An end-goal by itself
• An excuse to stop reducing documentation or an
opportunity to eliminate planning
• One size fits all
• Scrum—Scrum follows Agile principles
• Kanban—Kanban applies Agile principles
• Limited to software developments
 Agile Overview Summary

• Refers to any process that aligns with the concepts

of Agile Manifesto

• Based on incremental delivery and iterative

approach

• Encourages constant feedback from the end users

• Deliver value faster and foster the ability to better

respond to market trends
 Agile Overview Summary

• Refers to any process that aligns with the concepts

of Agile Manifesto

• Based on incremental delivery and iterative

approach

• Encourages constant feedback from the end users

• Deliver value faster and foster the ability to better

respond to market trends
 Agile Overview Summary

• Refers to any process that aligns with the concepts

of Agile Manifesto

• Based on incremental, iterative approach

• Encourages constant feedback from the end users

• Deliver value faster and foster the ability to better

respond to market trends
 Agile Overview Summary

• Refers to any process that aligns with the concepts

of Agile Manifesto

• Based on incremental, iterative approach

• Encourages constant feedback from the end users

• Deliver value faster and foster the ability to better

respond to market trends
Differences and Similarities: Waterfall vs Agile
 Differences and Similarities: Waterfall vs Agile
Waterfall

• Built in phases
• Painful to revisit previous phases
• High dependency on critical
paths
• Customer can’t interact with
product until it’s fully complete
 Differences and Similarities: Waterfall vs Agile
Agile Project Management: Build, deliver, learn, and adjust
• Follows iterative approach
• Regular feedback intervals
• Iterations resolve blocking issue
& let you interact with the
product
• Quickly adapt new
requirements/changes
• Shared skillset among the team
Differences and Similarities: Waterfall vs Agile
 Which one to choose: Waterfall/Agile?

Use Waterfall if……….. Use Agile if………..

• You don’t expect changes in scope and you’re • The final product isn’t clearly defined
working with fixed-price contracts • The clients/stakeholders need the ability to
• The project is very simple or you’ve done it modify the scope
many times before • You anticipate any kind of changes during the
• Requirements are very well known and fixed project
• Customers know exactly what they want in • Rapid deployment is the goal
advance
• You’re working with orderly and predictable
projects
Failing fast is fine, but succeeding early is better. Disciplined Agile makes navigating a wealth of knowledge
simple so you can identify solutions sooner. We call this guided continuous improvement.
Advantages & Disadvantages of Agile
 Advantages of Agile

• Change is embraced
• End-goal can be unknown
• Faster, high-quality delivery
• Strong team interaction
• Customers are heard
• Continuous improvement
 Disadvantages of Agile

• Planning can be less concrete

• Team must be knowledgeable
• Time commitment from developers is required
• Documentation can be neglected
Introduction to Key Agile Concepts
 Introduction to Key Agile Concepts

User Story

• Work divided into functional

increments called “user stories

• Short description of a feature from User Story

the perspective of the person who
desires the new capability Acceptance
Role Action/Goal Benefit
Criteria
• User story should be potentially
shippable

• Size of a user story is measured in

story points
 Introduction to Key Agile Concepts

User Story
 Introduction to Key Agile Concepts

User Story

Who is Responsible for Writing Acceptance Criteria?

Acceptance Criteria

• Should be testable
When Should User Story Acceptance Criteria Be Written?
• Should be clear and concise

• Everyone must understand

• Should provide user How Should You Format User Story Acceptance Criteria?
perspective
 Introduction to Key Agile Concepts

User Story Examples

•As a [customer], I want [shopping cart feature] so that [I A good user story should be: INVEST
can easily purchase items online].
•“I” ndependent (of all others)
•As a [manager], I want to [generate a report] so that [I can •“N” egotiable (not a specific contract for
understand which departments need more resources]. features)
•“V” aluable
•As a [customer], I want to [receive an SMS when the item •“E” stimable (to a good approximation)
is arrived] so that [I can go pick it up right away]. •“S” mall (so as to fit within an iteration)
•“T” estable (in principle, even if there isn’t
As a [manager], I want to be able to [understand my a test for it yet)
colleagues progress], so I can [better report our success
and failures].
 Introduction to Key Agile Concepts
Example of a good User Story
As an [online visitor], I want to [add products in my shopping cart] so that [I can purchase multiple products
at one go]

Acceptance Criteria [Abstract]

• Products can be added to the cart

• Products can be removed from the cart.

• Shopping cart will be empty initially

• Shopping cart will be empty after purchase

• Products can be added with multiple quantities in the cart

• Shopping cart will show the total product breakdown quantity and cost with grand total
 Introduction to Key Agile Concepts
Epic

• Series of user stories with a

broader strategic objective

• A large user story that cannot be Epic Major Component

delivered as defined within a
single iteration or is large enough
that it can be split into smaller Building Blocks
Story 1 Story 2 Story 3
user tasks/user stories

• No standard format to represent

epics
 Introduction to Key Agile Concepts
Epic Example: Selecting Marketing Campaigns
1: As a VP Marketing, I want to review the performance of historical promotional campaigns so that
I can identify and repeat profitable campaigns.

1a: As a VP Marketing, I want to select the timeframe to use when reviewing the performance of
past promotional campaigns, so that …
1b: As a VP Marketing, I can select which type of campaigns (direct mail, TV, email, radio, etc.) to
include when reviewing the performance of past so that …

1b1: As a VP Marketing, I want to see information on direct mailings when reviewing historical
campaigns so that...
1b2: As a VP Marketing, I want to see information on TV ads when reviewing historical campaigns so
that...
1b3: As a VP Marketing, I want to see information on email ads when reviewing historical campaigns
so that...
and so on for each type of ad campaign.
 Introduction to Key Agile Concepts
Initiatives
• Initiatives are collections of
epics that drive toward a
common goal

• The product roadmap is

expressed and visualized as a
set of initiatives plotted along
a timeline

• Completion of epics will lead

to the completion of the
initiative
 Introduction to Key Agile Concepts
Themes

• Themes are large focus areas

that span the organization

• A theme is an organization
goal that drive the creation of
epics and initiatives
 Introduction to Key Agile Concepts
Theme, Initiatives, Epic & Story
Fill empty seats in
Theme
theaters

Run Sales Promotion Initiative

Use a mobile app to

drive last-minute Epic
ticket sales

Add text-message capability

Create and assign Story
to the mobile app, to send Develop creative for promo
promotional codes for
last-minute promos and emails and SMS texts
last-minute purchases
coupons
 Introduction to Key Agile Concepts
Benefits of Using the Theme-Initiative-Epic-Story Development Framework

• It allows for more strategically sound

decisions

• It improves performance monitoring

and timeline estimates

• It keeps the team focused on key

goals
 Introduction to Key Agile Concepts

Product Backlog

A • Lists & Prioritizes the task-level details to execute a plan- To do list!

• Includes user stories, new features, changes to existing functionalities, bug fixes,
B and other tasks like infrastructure changes etc.
• Single source of requirements that defines the product
C • Contains short description of functionality desired in the product
• Can be represented in physical form or in electronic form
D • Owned & maintained by the product owner
• User Stories is the most common format
E • Dynamic in nature: addition, deletion and reordering of requirements possible
 Introduction to Key Agile Concepts

Product Backlog

A • Lists & Prioritizes the task-level details to execute a plan- To do list!

• Includes user stories, new features, changes to existing functionalities, bug fixes,
B and other tasks like infrastructure changes etc.
• Single source of requirements that defines the product
C • Contains short description of functionality desired in the product
• Can be represented in physical form or in electronic form
• Owned & maintained by the product owner
• User Stories is the most common format
• Dynamic in nature: addition, deletion and reordering of requirements possible
 Introduction to Key Agile Concepts

Product Backlog

C • Lists & Prioritizes the task-level details to execute a plan- To do list!

• Includes user stories, new features, changes to existing functionalities, bug fixes,
B and other tasks like infrastructure changes etc.
• Single source of requirements that defines the product
A • Contains short description of functionality desired in the product
• Can be represented in physical form or in electronic form
• Owned & maintained by the product owner
• User Stories is the most common format
• Dynamic in nature: addition, deletion and reordering of requirements possible
 Introduction to Key Agile Concepts
Difference Between a Product Backlog and Product Roadmap

Product
Vision

Product
Goals

Product
Roadmap

Release
Plan &
Backlog

From Product Vision to Backlog

 Introduction to Key Agile Concepts
Difference Between a Product Backlog and Product Roadmap

Product Roadmap Product Backlog

High-level: themes and epics or Task-level: user stories and

Content
outcomes and goals defects

Executive team (and other Primary for product and

Audience
stakeholders) development teams
Conveys tactical steps in
Intent Convey a strategy
execution of plan
Time
Varies, typically ~3 Months 1 or 2 sprints
Frame
 Introduction to Key Agile Concepts
Burn down Chart
A burndown chart is a visual display of work completed and remaining in a project, sprint, or iteration

Work Remaining(in hrs/Story points)/Tasks

Start Point
Estimated Effort
Actual Effort

End Point

Day of Sprint
 Introduction to Key Agile Concepts
Burn down Chart
Estimated Effort
Y Y Y Actual Effort

X X X
1. Ideal Scenario 2. Still, a good scenario 3. Decent scenario
Y Y Y

X X X
4. Missed the deadline 5. There’s something wrong 6. Team forgot about it
 Introduction to Key Agile Concepts
Burn down Chart
Benefits

• Simple & easy way to track team’s progress

• Timely prevention of issues

• Helps keep the team motivated

 Introduction to Key Agile Concepts
Y

Work Remaining(in hrs/Story points)/Tasks

Burn down Chart

1 2 3 4 5 6 7 8 9 10
Creating Burn down Chart

Mike, a project manager is

asked to create a burndown
chart for a project by his
leadership to know how
things progressing based on
what was planned. 1 2 3 4 5 6 7 8 9 10 X

Time
Project has 10 tasks to
complete in 10 days
 Introduction to Key Agile Concepts
Minimum Viable Product (MVP)
It is the version of a new product that allows a team to collect the maximum amount of
validated learning about customers with the least amount of effort.

- Agile Alliance

Why MVP

•Release a product to the market as quickly as possible

•Test an idea with real users before committing a large budget to the product’s full development
•Learn what resonates with the company’s target market and what doesn’t
 Introduction to Key Agile Concepts
Minimum Viable Product (MVP)
Minimum + Viable Product

It is the version of a new product that

allows a team to collect the
maximum amount of validated
Minimum MVP Viable
learning about customers with the
least amount of effort.
Most rudimentary, Sufficient enough
bare-bones for early adopters
- Agile Alliance foundation of the
solution possible
Product good enough to solve the core
problem for customers and has only
needed features to use it
 Introduction to Key Agile Concepts
Minimum Viable Product (MVP)

Why MVP?

•Release a product to the market as quickly as possible

•Test an idea with real users before committing a large

budget to the product’s full development

•Learn what resonates with the company’s target market

and what doesn’t
 Introduction to Key Agile Concepts

Minimum Viable Product (MVP)

Use case: Create the most basic version

of the Product
Your target audience needs a
specific means of transport, but Gather feedback on your
they are not sure if they want product
to buy a premium product right
away.
What do you do then?
 Introduction to Key Agile Concepts
Minimum Viable Product (MVP)

3
image source: http://www.expressiveproductdesign.com/
 Introduction to Key Agile Concepts
Minimum Viable Product (MVP)
Important points to be noted:

• Make sure your planned MVP aligns with your business objectives
• Identify specific problems you want to solve for your users
• Product must be viable
• MVP is based on iterative process of building
 Introduction to Key Agile Concepts
Velocity
At the end of each iteration, the team adds up effort estimates associated with user stories that
were completed during that iteration. This total is called velocity.

- Agile Alliance

Velocity = Units of work completed in a given timeframe

Unit of work can be hours Typically measured in

or user stories or story iterations or sprints, or
points weeks
 Introduction to Key Agile Concepts
Velocity
Sprint 1 Sprint 2 Sprint 3
User Stories Story Points Status
A 3 Complete
B 5 Incomplete
C 8 Complete
Velocity = 3 + 8 = 11 Story Points/ Sprint Velocity = 13 Story Points/ Sprint Velocity = 6 Story Points/ Sprint

Average velocity: (11+13+6)/3= 10 Story Points/Sprint

For the next sprint, the product manager should
pick up User Stories equivalent or not more than 10 story points
 Introduction to Key Agile Concepts
Velocity

Total Story points against remaining User Story (A) : 60

Average Velocity (B) : 10 Story Points/ Sprint

Forecast for the remaining effort for the Project: A/B = 60/10
= 6 Sprints with each sprint of 10 story points
 Introduction to Key Agile Concepts
Velocity

Failing to bring a story to completion Accurate Estimation

Velocity see-sawing Decomposition of User Stories
 Batch Size
What is Batch size?
Items which will be worked-on together. In scrum, all items to be completed in
a Sprint will be batch size.
Impact of Batch size?
Large batch size – longer sprints – Slower inspection and adaptation
• Slow adaptation means process will be inefficient – Inefficiency cost

Small batch size – faster and multiple sprints – Prepare and deploy many times
• Multiple deployments – overhead cost

Therefore, we need to find optimal batch size

 Batch Size
Example
Total 30 items Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5
2 items 2 items 2 items 2 items 2 items
6 days 6 days 6 days 6 days 6 days

Sprint 1 Sprint 2 Sprint 3 Sprint 6 Sprint 7 Sprint 8 Sprint 9 Sprint 10

10 items 10 items 10 items 2 items 2 items 2 items 2 items 2 items
30 days 30 days 30 days 6 days 6 days 6 days 6 days 6 days

Sprint 11 Sprint 12 Sprint 13 Sprint 14 Sprint 15

2 items 2 items 2 items 2 items 2 items
Scenario 1: Batch size of 10
6 days 6 days 6 days 6 days 6 days

Sprint takes 30 days to complete Scenario 2: Batch size of 2

Only 3 sprints – only 3 feedback loops
Sprint takes only 6 days to complete
15 feedback loops – 15 times planning & deployment
 Batch Size
Cost nomenclature
Large batch size – Longer sprints – delay in feedback - Holding cost

Smaller batch size – Multiple sprints – planning and deployment many times –
Transaction cost/ Overhead cost
 Batch Size

Suggestive cost curves – for purpose

of understanding only

Exact value of these costs cannot be

measured
 Introduction to Key Agile Concepts

Estimation

38+19 is about 60

For reasonable guess, you estimate basis

what you know or see
 Introduction to Key Agile Concepts
Agile Estimation

Traditional Estimation Agile Estimation

Efforts were estimated Business values or
Complexity is estimated
Unit: Hours Unit: Story Points or bucket
Estimation is done in task Estimation is done in user
level story level
Provides absolute estimate Provides relative estimate
Estimates once done are Estimates are revisited in
not revised every iteration
 Introduction to Key Agile Concepts
Agile Estimation

Traditional Estimation Agile Estimation

Efforts were estimated Business values or
Complexity is estimated
Unit: Hours Unit: Story Points or bucket
Estimation is done in task Estimation is done in user
level story level
Provides absolute estimate Provides relative estimate
Estimates once done are Estimates are revisited in
not revised every iteration
 Introduction to Key Agile Concepts
Agile Estimation

Traditional Estimation Agile Estimation

Efforts were estimated Business values or
Complexity is estimated
Unit: Hours Unit: Story Points or bucket
Estimation is done in task Estimation is done in user
level story level
Provides absolute estimate Provides relative estimate
Estimates once done are Estimates are revisited in
not revised every iteration
 Introduction to Key Agile Concepts
Agile Estimation

Traditional Estimation Agile Estimation

Efforts were estimated Business values or
Complexity is estimated
Unit: Hours Unit: Story Points or bucket
Estimation is done in task Estimation is done in user
level story level
Provides absolute estimate Provides relative estimate
Estimates once done are Estimates are revisited in
not revised every iteration
 Introduction to Key Agile Concepts
Agile Estimation

Traditional Estimation Agile Estimation

Efforts were estimated Business values or
Complexity is estimated
Unit: Hours Unit: Story Points or bucket
Estimation is done in task Estimation is done in user
level story level
Provides absolute estimate Provides relative estimate
Estimates once done are Estimates are revisited in
not revised every iteration
 Introduction to Key Agile Concepts
Agile Estimation

Traditional Estimation Agile Estimation

Efforts were estimated Business values or
Complexity is estimated
Unit: Hours Unit: Story Points or bucket
Estimation is done in task Estimation is done in user
level story level
Provides absolute estimate Provides relative estimate
Estimates once done are Estimates are revisited in
not revised every iteration
 Introduction to Key Agile Concepts
Agile Estimation
Story Points

3 Story Points: Study Room

Washroom Bedroom 1 Bedroom 2 5 Story Points: Bedroom 1
and Bedroom 2
8 Story Points: Kitchen

Livingroom Kitchen Study room

 Introduction to Key Agile Concepts
Agile Estimation
Influencing Factors of Story Point :

• Business Value
• Complexity
• Risks
• Dependencies
• Amount of work
Image Source: Dilbert.com
 Introduction to Key Agile Concepts

Agile Estimation: But why relative estimation?

Illustration 1
Building B
Which one is taller?
Which one is more complex?
Building A Which would take more time to build?
Which would cost more?
How much money?
How much time?

1 Story vs 2 Story
 Introduction to Key Agile Concepts
Agile Estimation: But why relative estimation?
Illustration 2

What about these

Which building is taller?
Which one is more complex?
Which would take more time to build?
Which would cost more?
How much money?
How much time?

100 Story vs 101 Story

 Introduction to Key Agile Concepts

Estimation
 Introduction to Key Agile Concepts

Agile Estimation
Agile Estimation is a team sport
 Introduction to Key Agile Concepts

Agile Estimation
Agile Estimation is a team sport

Estimation methods include:

• T-shirt sizes (XS, S, M, L, XL) or the

• Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.)
 Introduction to Key Agile Concepts

Agile Estimation
T-shirt sizes (XS, S, M, L, XL)
 Introduction to Key Agile Concepts

Agile Estimation

Fibonacci sequence

1,2,3 is equivalent to 10,20,30

0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89… and so on.

0+1=1
1+1=2
1+2=3
 Introduction to Key Agile Concepts

Agile Estimation

0, 1, 1, 2, 3, 5, 8, 13, 21……..
Fibonacci sequence

Infinite
 Introduction to Key Agile Concepts

Agile Estimation

0, 1, 1, 2, 3, 5, 8, 13, 21……..
Fibonacci sequence

0.0%
Infinite
 Introduction to Key Agile Concepts

Agile Estimation

0, 1, 1, 2, 3, 5, 8, 13, 21……..
Fibonacci sequence

100%
0.0%
Infinite
 Introduction to Key Agile Concepts

Agile Estimation

0, 1, 1, 2, 3, 5, 8, 13, 21……..
Fibonacci sequence

50%
100%
0.0%
Infinite
 Introduction to Key Agile Concepts

Agile Estimation

0, 1, 1, 2, 3, 5, 8, 13, 21……..
Fibonacci sequence

66.7%
50%
100%
0.0%
Infinite
 Introduction to Key Agile Concepts

Agile Estimation

0, 1, 1, 2, 3, 5, 8, 13, 21……..
Fibonacci sequence

60%
66.7%
50%
100%
0.0%
Infinite
 Introduction to Key Agile Concepts

Agile Estimation

0, 1, 1, 2, 3, 5, 8, 13, 21……..
Fibonacci sequence

62.5%
60%
66.7%
50%
100%
0.0%
Infinite
 Introduction to Key Agile Concepts

Agile Estimation

0, 1, 1, 2, 3, 5, 8, 13, 21……..
Fibonacci sequence
61.5%

62.5%
60%
66.7%
50%
100%
0.0%
Infinite
 Introduction to Key Agile Concepts

Agile Estimation

Fibonacci sequence

In Agile Estimation, slightly modified version of Fibonacci estimation is used

1, 2, 3, 5, 8, 13, 21, 34, 55, 89… and so on.

 Introduction to Key Agile Concepts
Skyscraper B
Skyscraper A

Agile Estimation
Fibonacci sequence
Building B

Building A

1 Story 2 Story 20 Story 21 Story

Story Points are Relative

1 – QUICK TO DELIVER AND MINIMAL COMPLEXITY. AN HOUR

Example: add field to a form

2 – QUICK TO DELIVER AND SOME COMPLEXITY. MULTIPLE HOURS

Example: Add parameter to form, validation, storage

3 – MODERATE TIME TO DELIVER, MODERATE COMPLEXITY, POSSIBLE UNKNOWNS

Example: Migrate somewhat complex static CSS into a CSS pre-processor

5 – LONGER TIME TO DELIVER, HIGH COMPLEXITY, LIKELY UNKNOWNS

Example: Integrate with third-party API for pushing/pulling data, and link to user profiles in platform

8 – LONG TIME TO DELIVER, HIGH COMPLEXITY, CRITICAL UNKNOWNS

Example: Overhaul the layout/HTML/CSS/JS of a web application

13 – LONG TIME TO DELIVERY, HIGH COMPLEXITY, MANY CRITICAL UNKNOWNS

Example: Migrate application from an outdated data store to new DB technology and ORM

21 – YOU’RE DOING THIS WRONG.

 Introduction to Key Agile Concepts
Agile Estimation Techniques for user story

• Delphi
• Wide Band Delphi
• Complexity Bucket
• Estimation Poker
 Introduction to Key Agile Concepts
Agile Estimation Techniques for user
story
• Delphi
• Wide Band Delphi
• Complexity Bucket
• Estimation Poker
 Estimation/Planning Poker
Product Owner
explaining all the aspects
of the story requirement,
dependencies,
acceptance criteria and
business value

Scrum Master can help

coordinate the estimation

Developers, testers, mutually

discussing
• Amount of work
• Associated Risks
• Technical Changes
• Dependencies
• Complexities
• And the value
Estimation/Planning Poker

1, 2, 3, 5, 8, 13, 21, ...

 Service Level Expectation
Service level expectation (SLE)
An estimation of the cycle time for work-items

Why do we calculate SLE?

• To calculate estimated delivery date
• Benchmark for comparing with work-item age
• Identifying stuck/ delayed items

How is it calculated?
Based on historical values. If old data is not available, guess initially and update
later
 Service Level Expectation
How is SLE used?
Identify slow items by comparing work-item age with SLE
Define policy to handle slow items
Talk about the items which missed the SLE during Retrospective

Is SLE same as SLA?

No, SLA is Service level Agreement – It is a commitment
SLE is an estimation
Scrum
 Scrum
Scrum is a process framework used to manage product development and other
knowledge work.

- Agile Alliance

20 Days
 Scrum
Scrum is a set of rules for structuring the team, processes and techniques for making the development
process agile..

Scrum
Team

4 components of
Scrum Framework Scrum
Rules

Scrum Scrum
Artifacts Events
 Scrum
3 Pillars of Scrum
Scrum
Transparency

Adaptation
Inspection
Minimize deviation

Required information Regular monitoring for early Course correction to prevent

is available and flows properly detection of issues further deviation
 Scrum
Scrum Team

Product Owner Developers Scrum Master

 Scrum
Responsibility
• Maximize the total value of work done by the developers

• Product backlog management

Product Owner Clear Prioritization Visibility & Clarity of

Expression of in the Product Product Backlog with
requirements Backlog based shared understanding
in the Product on value to of priorities
Backlog the customer
 Scrum

Task 1

Task 2

Task 3
Product Owner
………..
 Scrum
Organization also provides authority to a Product Owner..

Product Owner Product Owner

 Scrum
Responsibility
• Craft a “Done” increment that meets the “Definition of Done” by the end of the sprint
• Deliver a potentially releasable increment of a product at the end of each Sprint

Developers
Group of professionals who work
collaboratively to deliver a potentially • Work within the boundaries of the Sprint Goal
releasable increment(“Done”) of a
product at the end of each sprint Authority
Sprint: Short, fixed, time-boxed period
• How the work would be done is left to the developers
during which a potentially releasable
product Increment is created
• Sprint Backlog: A plan by and for the Developers
 Scrum
Characteristics of Scrum Developers
• It is cross-functional, no external dependency

• It is self-managing
Developers
 Scrum
Characteristics of Scrum Developers

• No titles and sub teams within developers

• Team size: A team of 3 to 9 team members is good

Developers
 Scrum

• Facilitates understanding of Scrum theory and practice across the team

and organization

• Accountable for the Scrum Team's effectiveness and adherence to Scrum

practices

• Servant-leader(Serving others, Helping people develop and perform as

highly as possible) for the Scrum Team
Scrum Master
 Scrum

Serving the Scrum Team

• Coaches on self-management and cross-functionality

• Guides focus on high-value Increment creation meeting the “Definition of

done”

• Removes impediments to progress

Scrum Master • Ensures productive Scrum events within time constraints
 Scrum

Supporting the Product Owner

• Aids in effective Product Goal definition and Backlog management

• Clarifies the need for concise Product Backlog items

• Facilitates empirical(learn & improve) product planning in complex

environments
Scrum Master • Enhances stakeholder collaboration
 Scrum

Serving the Organization

• Leads Scrum adoption and implementation

• Trains and coaches on Scrum practices

• Promotes empirical approaches for complex work

• Removes barriers between stakeholders and Scrum Teams

Scrum Master
 Scrum

Sprint Sprint Planning

Sprint Events
Sprint Daily Scrum
Retrospective

Sprint Review
 Scrum

Features of Scrum Events

• Time boxed: limit on the duration of these events

Daily Scrum is a 15- minutes meeting

 Scrum
Features of Scrum Events

• Based on three pillars of transparency, inspection & adaptation

Scrum
Sprint
Transparency

Adaptation
Inspection
 Scrum
Sprint

• Short(Typically 1-4 weeks), time-boxed period when a scrum team works

to complete a set amount of work

• No defined or “ideal” number of sprints in a project, depends on scope of

the project
 Scrum

Sprint

Product Owner
 Scrum

Sprint
 Scrum

Sprint Product Increment Product Increment

SPRINT 1 SPRINT 2

-X Days (<=30 )- -X Days (<=30 )-

------------------X Days (<=30 )-----------------------

Product Releasable Product Releasable
(SPRINT)
 Scrum
Sprint

• Short(Typically 1-4 weeks), time-boxed period when a scrum team works

to complete a set amount of work

• No defined or “ideal” number of sprints in a project, depends on scope of

the project

• In the face of significant external changes such as regulatory shifts, the

Product Owner can cancel a Sprint, necessitating agile response and
strategic replanning to align with new objectives, despite the challenges
this poses to the team's rhythm and productivity
 Scrum

Sprint Review
Meeting
Product Owner Developers

Scrum Master Stakeholder

Sprint Retrospective
Meeting
Sprint

Completed
Sprint Planning Product
Product Backlog Sprint Backlog Meeting
 Scrum

Sprint Planning

• Meeting where plan for the upcoming Sprint is drafted

• Sprint planning happens once in each Sprint, outlines the tasks to be completed

• Entire Scrum Team: Product Owner, Scrum Master & Developers must be a part of the event
 Scrum: Sprint Planning

Sprint Review
Meeting
Product Owner Developers

Scrum Master Stakeholder

Sprint Retrospective
Meeting
Sprint

Completed
Sprint Planning Product
Product Backlog Meeting Sprint Backlog
 Scrum
Sprint Planning
• Meeting where plan for the upcoming Sprint is drafted

• Sprint planning happens once in each Sprint, outlines the tasks to be completed

• Entire Scrum Team: Product Owner, Scrum Master & Developers must be a part of the event

• Time box for the event is 8 hours (upper limit)

• Two agendas

• What is to be done in this Sprint

• Establish how it will be done

 Scrum

Sprint Planning
Product Backlog Determining What Will Be Done in the Sprint
Sprint Backlog
• Product Owner Responsible for maintaining
the Product Backlog

In line with Sprint Goal

• Scrum team collaborates to craft the Sprint
Goals(commitment), the outcome of Sprint
Planning

Product Owner discusses the • Developers form Sprint Backlog(forecast)

product backlog with the
developers from the Product Backlog

Product Owner
 Scrum

Sprint Planning
Establishing How the Work Will Be Done

• Developers decide how the work will be organized

within the Sprint

• By the end of Sprint Planning, Developers to convey

their plan for delivering the product increment for
Developers craft plan based on Developers convey plan to
the upcoming sprint to the Product Owner
estimated effort Product Owner

• Developers can renegotiate the selected Product

Backlog items with the Product Owner
 Scrum

Sprint Planning
Product Backlog
Sprint Backlog Scrum Master

Ensures Scrum rules are followed

Can facilitate Agile activities(e.g. Estimation) to support

team, but not a decision maker

Scrum Master Facilitates the Sprint Planning

 Scrum: Daily Scrum

Sprint Review
Meeting
Product Owner Developers

Scrum Master Stakeholder

Sprint Retrospective
Meeting
Sprint

Completed
Sprint Planning Product
Product Backlog Sprint Backlog Meeting
 Scrum

Daily Scrum

• Event is for the Developers

• Scrum Master & Product Owner can participate as developers
if working actively on items in the Sprint Backlog

• Daily Scrum is implementation of two pillars of scrum: Regular

inspection & early adaptation

Daily Scrum is a 15-minutes event

done everyday

Same place, same time

 Scrum

Daily Scrum
15-minutes everyday
Same place, same time

Developers can decide the structure & techniques to be

followed in the meeting for achieving the Sprint Goal

Enhances communication, identifies potential

roadblocks, fosters rapid decision-making, reduces the
necessity for additional meetings

Developers can engage in more in-depth discussions as

needed throughout the day
 Scrum: Sprint Review

Sprint Review
Meeting
Product Owner Developers

Scrum Master Stakeholder

Sprint Retrospective
Meeting
Sprint

Completed
Sprint Planning Product
Product Backlog Sprint Backlog Meeting
 Scrum

Sprint Review Attendees

REVIEW • Entire Scrum Team: Product Owner,

Scrum Master, the Developers &
Product Increment other stakeholders

SPRINT Objective

• Help the scrum team work more

effectively
• Increase transparency within the
team and between other stakeholders
and Scrum team

Time box for the event is 4 hours or less

 Scrum
Sprint Review
What happens in Sprint Review?

1) Product Owner invites all attendees

2) Product Owner highlights completed & not-completed items

3) Developers share Sprint experience, highlight challenges

Developers demonstrates completed item
Stakeholders may ask questions on the demonstrated item

4) Product Owner opens the backlog & initiate discussion on what to do next.
Priorities, budgets, timelines & capabilities etc. are discussed.

5) At the end of Sprint Review, Product Owner should have updated backlog
 Scrum: Sprint Retrospective

Sprint Review
Meeting
Product Owner Developers

Scrum Master Stakeholder

Sprint Retrospective
Meeting
Sprint

Completed
Sprint Planning Product
Product Backlog Sprint Backlog Meeting
 Scrum
Sprint Retrospective
Scrum Team does this event

Agenda Inspection &

Inspect the performance of the team Adaptation of Scrum
Team
What went well? What went wrong?

Time box for the event is 3 hours or less

At the end of Scrum Retrospective, Scrum Team should know:

• Area of improvements → Mostmost impactful improvements are addressed, may be added
• Plan of working on them to Sprint Backlog for next Sprint
 Scrum
Scrum Artifacts

Represent work or
value, designed to
maximize transparency
of key information

Commitment Product Goal

 Scrum
Scrum Artifacts

Represent work or
value, designed to
maximize transparency
of key information

Commitment Product Goal Sprint Goal

 Scrum
Scrum Artifacts

Represent work or
value, designed to
maximize transparency
of key information

Commitment Product Goal Sprint Goal Definition of Done

Reinforce “Empiricism” (Making decisions based on what

is known & observed)
 Scrum
Product Backlog
At a later stage when
requirements changes

At the initial stage of Add details to new

starting the process requirements Product Backlog
Refinement

Act of breaking down

& further defining
product backlog
Product Owner Developers items into smaller,
more precise item
Ever Evolving

Never Fixed
 Scrum
Product Backlog
Product Backlog Refinement is a balancing act

Each Product Backlog Item(PBI) Product Goal

designed to deliver a specific
unit of value
Description/Detail
Order
Size (by developers)

Developers estimate Product

Backlog Items(PBIs)
If the estimate shows the PBI
cannot be completed within a
sprint, the entire team
collaborates on how best to split
it into smaller valuable product
backlog items
 Scrum

Product Backlog

Developers

Business Team Backlog Refinement Product Goal

Break initial Refined/Ordered Backlog Enhancing user satisfaction and
Initial Requirement : • Implementing a system to track
requirements into increasing sales conversions on the
Enhance engagement abandoned carts
smaller, more precise platform
with users who • Designing personalized notification
abandoned their cart items, estimate effort messages
& order tasks • Determining the optimal timing for
sending these notifications to maximize
re-engagement
 Scrum
Sprint Backlog

Product Backlog Sprint Goal(Why)

Sprint Backlog
Set of Product Backlog items
selected for the Sprint (What)

Actionable plan for delivering the

Increment (How)

Sprint Backlog is a plan by & for the developers

 Scrum
Sprint Backlog

Sprint Backlog
• Daily monitoring of Sprint Backlog is done in the Daily Scrum

• Owned by the developers

• Any deviation from the goal should be highlighted to the Product Owner
& Stakeholders immediately

• Focuses on continuous improvement (at least one improvement item in

the Sprint Backlog)
 Scrum
Increment

Increment is the final releasable product

• It should be usable
• It should be inspectable
• It should be cumulative (include increments of all
previous sprints)

Multiple increments can be created within a sprint

Increments can be released to the stakeholders before
the sprint review
Definition of “Done”
Formal description of the state of the Increment when it meets the quality standards required for the product
If a Product Backlog item meets the Definition of Done, it
becomes part of an Increment
Advantages & Disadvantages of Scrum
 Advantages of Scrum

• More transparency and project visibility

• Increased team accountability
• Easy to accommodate changes
• Increased cost savings
• Faster Delivery
• Customers are heard
 Disadvantages of Scrum

• Risk of scope creep

• Team requires experience and commitment
• The wrong Scrum Master can ruin everything
• Poorly defined tasks can lead to inaccuracies
 Introduction to Kanban
Flexible & easy to implement method for process improvement

Scrum: Has Strict Rules Extreme Programming: Has Strict Practices

Introduction to Kanban

Identified bottlenecks in the car

making process using Kanban
Introduction to Kanban

Visualizing the workflow

to
achieve process improvement
Introduction to Kanban

Visualizing the
workflow
to
achieve process improvement
Introduction to Kanban
Visualizing the workflow
to
achieve process
improvement
Limiting the work in progress
Managing the flow
Implementing feedback loops
 Kanban Board
NOT STARTED IN PROGRESS DONE
 Kanban Board

Physical Kanban Board Software Based Board

 Kanban Board
NOT STARTED IN PROGRESS DONE

TASK 1
 Kanban Board
NOT STARTED IN PROGRESS DONE

TASK 1
 Kanban Board
NOT STARTED IN PROGRESS DONE

TASK 1
 Kanban Board
Input Queue Analysis Development Build Ready Test Release Ready

In Progress Done In Progress Done

Board Reference: David Anderson’s “Kanban”

 Kanban Board
Input Queue Analysis Development Build Ready Test Release Ready

In Progress Done In Progress Done

Board Reference: David Anderson’s “Kanban”

 Kanban Board
Input Queue Analysis Development Build Ready Test Release Ready

In Progress Done In Progress Done

Board Reference: David Anderson’s “Kanban”

 Kanban Board
Input Queue Analysis Development Build Ready Test Release Ready

In Progress Done In Progress Done

Board Reference: David Anderson’s “Kanban”

 Kanban Board
Input Queue Analysis Development Build Ready Test Release Ready

In Progress Done In Progress Done

Board Reference: David Anderson’s “Kanban”

 Kanban Board
Input Queue Analysis Development Build Ready Test Release Ready

In Progress Done In Progress Done

Board Reference: David Anderson’s “Kanban”

 Kanban Board
Business
Input Queue Analysis Development Build Ready Test Review Release Ready

New Sent from In Progress Done In Progress Done

review

TASK 3

TASK 2

TASK 4

Board Reference: David Anderson’s “Kanban”

 Kanban Board
Business
Input Queue Analysis Development Build Ready Test Review Release Ready

New Sent from In Progress Done In Progress Done

review

TASK 4 TASK 3

TASK 2

Board Reference: David Anderson’s “Kanban”

 Kanban Board
Business
Input Queue Analysis Development Build Ready Test Review Release Ready

New Sent from In Progress Done In Progress Done

review

TASK 4 TASK 2

TASK 3

Board Reference: David Anderson’s “Kanban”

 Kanban Board
Finding inefficiencies/issues in the process

Business Request Scheduled Building Testing Business Review Release Ready

Sent from
New
review

TASK 2
 Kanban Board
Finding inefficiencies/issues in the process

Business Request Scheduled Building Testing Business Review Release Ready

New Sent from

review

TASK 2
 Kanban Board
Finding inefficiencies/issues in the process

Business Request Scheduled Building Testing Business Review Release Ready

New Sent from

review

TASK 2
 Kanban Board
Finding inefficiencies/issues in the process
Business Request Scheduled Building Testing Business Review Release Ready

Sent from
New review

TASK 2
 Kanban Board
Finding inefficiencies/issues in the process

Business Request Scheduled Building Testing Business Review Release Ready

New Sent from

review

TASK 2
 Kanban Board
Finding inefficiencies/issues in the process

Business Request Scheduled Building Testing Business Review Release Ready

New Sent from

review

TASK 2
 Kanban Board
Finding inefficiencies/issues in the process

Business Request Scheduled Building Testing Business Review Release Ready

New Sent from

review
Too much WIP
TASK 2

Outflow is low

Inflow is higher
 Kanban Board

Finding inefficiencies/issues in the process

Sl. no. Situation Suggestion

1 Too much work in progress(WIP) More team members need to work on that stage
on a single stage (for e.g. testing stage in this scenario) instead of
Limiting the WIP any of the previous stage
 Kanban Board

Limiting the WIP

• A limit is set on the maximum number of tasks that can be present in a column
or that step at a time

• No further inflow into the step until the pending tasks in that step are cleared
 Kanban Board
Finding inefficiencies/issues in the process

Business Request Scheduled Building Testing Business Review Release Ready

New Sent from

review Limit: 6

TASK 2

6 tasks pending
 Kanban Board

Limiting the WIP

• A limit is set on the maximum number of tasks that can be present in a column
or that step at a time

• No further inflow into the step until the pending tasks in that step are cleared

• WIP limits can be set on all the steps

• How do we decide what limit to set?

 Kanban Board

Finding inefficiencies/issues in the process

Sl. no. Situation Suggestion

Too much work in progress(WIP) More team members need to work on that stage
1 on a single stage (for e.g. testing stage in this scenario) instead of
Limiting the WIP any of the previous stage
Under utilization of
2 resources
Pending tasks not moving to the
next step
 Kanban Board
Finding inefficiencies/issues in the process

Business Request Scheduled Building Testing Business Review Release Ready

New Sent from

review
 Kanban Board

Finding inefficiencies/issues in the process

Sl. no. Situation Suggestion

Too much work in progress(WIP) More team members need to work on that stage
1 on a single stage (for e.g. testing stage in this scenario) instead of
Limiting the WIP any of the previous stage
Under utilization of
resources Reallocate the resources somewhere else where
2
Pending tasks not moving to the they can be utilized optimally
next step

Managing the Flow

 Kanban
Kanban is also known as a Pull based system
Optimizes the work flow
Push based system Pull based system
Reduces lead time

Manager/Team Leader Reduces over load on

worker
Team members can
Assign tasks
themselves pull the most
relevant tasks out of the list
of tasks to be done

Team Members
 Kanban Board
Finding inefficiencies/issues in the process

Business Request Scheduled Building Testing Business Review Release Ready

Sent from
review

TASK 3
 Kanban
Finding inefficiencies/issues in the process
Sl. no. Situation Suggestion
Too much work in progress(WIP) on More team members need to work on that stage
1 a single stage (for e.g. testing stage in this scenario) instead of any
Limiting the WIP of the previous stage

Under utilization of resources

Reallocate the resources somewhere else where
2 Pending tasks not moving to the
they can be utilized optimally
next step

Task is taking longer time than it

3
should be
 Kanban Board
Finding inefficiencies/issues in the process

Issue: Task is taking longer time than it should be

Reason Suggestions
Unequal sized tasks Break down the task into smaller sized
tasks
 Kanban Board
Finding inefficiencies/issues in the process
Scoping/Analyzing
Business Request /Specifying Scheduled Building Testing Business Review Release Ready

Sent from
review

TASK 3
 Kanban Board
Finding inefficiencies/issues in the process

Issue: Task is taking longer time than it should be

Reason Suggestions
Unequal sized tasks Break down the task into smaller sized
tasks
Task is stuck due to some bug or issue Keep a regular track of the board
 Kanban
Finding inefficiencies/issues in the process
Sl. no. Situation Suggestion
Too much work in progress(WIP) on More team members need to work on that stage
1 a single stage (for e.g. testing stage in this scenario) instead of any
Limiting the WIP of the previous stage

Under utilization of resources

Reallocate the resources somewhere else where
2 Pending tasks not moving to the
they can be utilized optimally
next step

Keep a regular track of the board

Task is taking longer time than it
3 Break down the task into smaller sized tasks
should be
 Kanban Board
Finding inefficiencies/issues in the process

Business Request Scheduled Building Testing Business Review Release Ready

Sent from
review

Feedback Loop
If tasks are sent multiple times for rework, process throughput
reduces

Work done on the task previously goes to waste

Hence, our Kanban board should highlight the tasks that sent
back for multiple reworks
 Kanban Board
Finding inefficiencies/issues in the process

Business Request Scheduled Building Testing Business Review Release Ready

Sent from
review
 Kanban Board
Finding inefficiencies/issues in the process

Business Request Scheduled Building Testing Business Review Release Ready

Sent from
review
 Kanban Board
Finding inefficiencies/issues in the process

Business Request Scheduled Building Testing Business Review Release Ready

Sent from
review
 Kanban
Finding inefficiencies/issues in the process
Sl. no. Situation Suggestion
Too much work in progress(WIP) on a More team members need to work on that stage
1 single stage (for e.g. testing stage in this scenario) instead of any of
Limiting the WIP the previous stage
Under utilization of resources
Reallocate the resources somewhere else where they
2 Pending tasks not moving to the next
can be utilized optimally
step
Keep a regular track of the board
Task is taking longer time than it
3 Break down the task into smaller sized tasks
should be

Make a mark on the task for the number of rounds

4 Multiple feedback loops that task is going for rework
 Kanban
Finding inefficiencies/issues in the process
Sl. no. Situation Suggestion
Too much work in progress(WIP) on a More team members need to work on that stage
1 single stage (for e.g. testing stage in this scenario) instead of any of
Limiting the WIP the previous stage
Under utilization of resources
Reallocate the resources somewhere else where they
2 Pending tasks not moving to the next
can be utilized optimally
step
Keep a regular track of the board
Task is taking longer time than it
3 Break down the task into smaller sized tasks
should be

Make a mark on the task for the number of rounds

4 Multiple feedback loops that task is going for rework
Find optimum WIP limit for your review step
Finding inefficiencies/issues
in the process
 Kanban
Finding inefficiencies/issues in the process

Sl. no. Situation Suggestion

Having a lot of external
4
dependencies
 Kanban Board
Finding inefficiencies/issues in the process

Business Request Track Scheduled Building Testing Business Review Release Ready

Sent from
review
 Kanban
Finding inefficiencies/issues in the process
Sl. no. Situation Suggestion
Develop a practice of regular follow ups on tasks listed
Having a lot of external
4 in “Tracking” column
dependencies
No need of a WIP limit on this column
 Kanban
Finding inefficiencies/issues in the process
Sl. no. Situation Suggestion
Develop a practice of regular follow ups on tasks listed
Having a lot of external
4 in “Tracking” column
dependencies
No need of a WIP limit on this column

Team required to work on non-

5
product features
 Kanban Board
Finding inefficiencies/issues in the process
Demo/ Business
Business Request Scheduled Building Testing Presentations Review Release Ready
Sent from
review
 Kanban
Finding inefficiencies/issues in the process
Sl. no. Situation Suggestion
Develop a practice of regular follow ups on tasks listed
Having a lot of external
4 in “Tracking” column
dependencies
No need of a WIP limit on this column

Team required to work on non- Create a task for such features and keep a track on the
5
product features same

6 Automate/Upgrade tasks Add such improvement tasks also on the board

 Kanban
Finding inefficiencies/issues in the process
Sl. no. Situation Suggestion
Develop a practice of regular follow ups on tasks listed
Having a lot of external
4 in “Tracking” column
dependencies
No need of a WIP limit on this column

Team required to work on non- Create a task for such features and keep a track on the
5
product features same

6 Automate/Upgrade tasks Add such improvement tasks also on the board

7 Assigning work to new person Assign the new person to the slowest step
Defining “Done”
 Kanban

Defining “Done”
Define done for each feature Define completion for each step
 Kanban
Finding inefficiencies/issues in the process

Business Request Scheduled Building Testing Business Review Release Ready

Sent from
review

TASK
A
 Kanban
Input Queue Analysis Development Build Ready Test Release Ready

In Progress Done In Progress Done In Progress Done In Progress Done

 Kanban

Define completion for each step

• If a step is complete on a task, it does not necessarily mean that

the task moves to the next step

• Task will simply sit in the done column of the previous step

• Do not have separate WIP limits for sub columns “In progress”
and “Done”

• Write "Done” rules as notes on the Kanban board

• Always check if the rules for “Done” were met in the previous
step or not
The Daily Standup
 The Daily Standup
Scrum has rules on:

• How long the meting will be?

• Who will be handling the meeting?
• What will be discussed in the meeting ?
Kanban is flexible
with no such rules
• Any team member can run the meeting even a
fresher
• No fixed duration of the meeting, depends on the
team’s experience
• Daily stand up is the time to get the board up-to-
date, identify issues, highlight problems if any etc.
Not a review meeting or demo of features built or
discussion about the product etc.
Specifying rules
 Specifying rules

Ensure rules are explicitly mentioned and everyone understands them clearly

• Writing WIP limit on top of the column

• Define “Done”
Kanban Flow Metrics
Kanban Flow Metrics
 Work in Progress
Input Queue Analysis Development Build Ready Test Release Ready

In Progress Done In Progress Done In Progress Done

All these steps are part of
the development process
1 2 7 9 11 14 16 18 20 22

3 4 8 10 12 15 17 19 21 23

5 6 13

WIP = 23
 WIP Limit
Finding inefficiencies/issues in the process

Business Request Scheduled Building Testing Business Review Release Ready

Sent from
review Limit: 6

Task 2

New

6 Tasks Pending
Cycle Time
Cycle Time
Cycle Time
Throughput
 Work Item Age

Elapsed time between when a work item ”started” and the current time

Start Time Current Time

Work Item Age

Provides Transparency to the flow

Agile Team tracks the start date of each item to calculate Work Item Age
 Work Item Age

Work Item Age Cycle Time

Leading Indicator Lagging Indicator

Relevant for non-finished item Relevant for finished items

 Work Item Age
Ageing Work in Progress Chart

Applications

• Help identify items that are struggling and

require attention

• Calculate the amount of time for which

item has been under WIP on Kanban
Board

• Predict flow risks based on historical cycle

times
Stages of the workflow
are represented
 WIP indicator shows
how many tasks are in
WIP
 Calendar item
indicating the current
date
 Visualizes how long
each task has spent in
Zoom
Percentage of task that
were previously
completed
 Leading & Lagging Indicators

Measure & Improvec

(Actionable)

(Non-Actionable)
Leading & Lagging Indicators
(Ability to track
Lagging Indicator
progress)

Conversion rate

Website Traffic

Leading Indicator
(Ability to adjust
your course)
Little’s Law
 Little’s Law
Links the three metrics Throughput, Work in progress & Cycle Time

Avg. Waiting time

Avg. Length of queue

Or Avg. Rate of Arrival
Number of items
waiting

John Little
Little’s Law

Avg. Waiting
time

Avg. Length of Each person has to wait

queue Avg. Rate of 3 minutes in the shop
Or Arrival
to get a burger
Number of items
waiting
2 people enter
6 people will be every minute
in the queue
6= 2 x 3
 Little’s Law

Avg. Waiting
time

Avg. Length of
queue Avg. Rate of
Or Arrival
Number of items
waiting

Avg. Avg. Avg.

WIP Throughput Cycle Time

Assumption: Stable flow i.e. no. of items being picked by development team is
equal to avg. number of items completed
Little’s Law
Avg. Avg. Avg.
WIP Throughput Cycle Time
OR
Avg. Avg. Avg.
Cycle Time Throughput WIP
OR
Avg. Avg. Avg.
Throughput WIP Cycle Time
 Little’s Law

Avg. Avg. Avg.

WIP Throughput Cycle Time
WIP: Unit is No. of work items

Cycle time: Unit is Days No. of work items = Days x No. of work items
Day
Throughput: Unit is No. of work items per day

No. of work items = No. of work items

 Little’s Law

Avg. Avg. Avg.

WIP Throughput Cycle Time

Avg. WIP
For 30 days sprint, try to collect data for previous 10—12 sprints Avg. Throughput
Avg. Cycle Time

Uses of Little’s Law Process can be considered as

stationary & predictable
• Checking Process Predictability
• Building Project management intuition Process has higher randomness
 Little’s Law
How not to use Little’s Law

Avg. Avg. Avg. Cycle time depends on

WIP Throughput Cycle Time a lot of factors other
than WIP &
10 5 2 Throughput

Don’t use it to predict future values/forecasting

Don’t use it to make Project completion commitments

 Little’s Law
Assumptions necessary for Little’s law to work

Measuring units for three metrics in the formula should be consistent

Average arrival rate should be equal to average departure rate/Throughput

WIP should be same as the beginning & the end of the chosen interval

All work that enters the process will also exit the process

Average age of WIP should remain the same

 Little’s Law
Assumptions necessary for Little’s law to work

WIP 1 WIP 2

Avg. age of 5 items in

In next 15 days WIP 2 > Avg. age of 5
10 new items 4 out of items in WIP 1
entered the these 5 got
process completed
WIP should be
steadily maintained
6 out of At the end of
these 10 15 days
got
completed

Avg. age of this

item is large
 Cumulative Flow Diagram

• Tracks progress for Agile Teams

• Shows state of WIP & Project pace

• Help identify potential risks & bottlenecks to be on track

500 issues in the To-Do
stage on March 16

Entry point for

To-Do

Leaving point
for To-Do
 Cumulative Flow Diagram

• Tracks progress for Agile Teams

• Shows state of WIP & Project pace

• Help identify potential risks & bottlenecks to be on track

• Help identify lead time, Cycle time, Throughput & Work in progress
Lead Time: Period between a new task’s appearance in your workflow and its final departure from the system

Approx. 2 months & 15 days

(Lead Time)
Cycle Time: Represents the amount of elapsed time that a work item spends as Work In Progress

Approx. 15 days
(Cycle Time)
WIP: Represents the amount of issues that have entered a given process but have not exited

325
WIP
(Approx. 175)
Throughput: Represents the amount of WIP (number of work items) completed per unit of time

Throughput
(Slope)
Bottlenecks
Bottlenecks: Lowest Throughput

Bottleneck
Bottlenecks: Lowest Throughput
The Bands are Progressing in Parallel
The Bands are Progressing in Parallel
The Band is Rapidly Narrowing
The Band is Rapidly Widening
The Band is Rapidly Widening
 Extreme Programming (XP)
Extreme Programming (XP) is an agile software development framework that aims to
produce higher quality software, and higher quality of life for the development team.
XP is the most specific of the agile frameworks regarding appropriate engineering
practices for software development.

- Agile Alliance

Why is it called Extreme Programming?

Code Review
 Extreme Programming (XP)

XP was introduced in 1996 by Kent beck

 Extreme Programming (XP)

Extreme Programming is all about… It ran into controversy around…

• Client satisfaction • Pair programming

• Bringing the social change • Incremental design

• Adaptiveness • Scalability
 Extreme Programming (XP)
Values behind XP practices and methods

• Simplicity

• Communication

• Courage

• Feedback

• Respect
 Extreme Programming (XP)
Values behind XP practices and methods

• Simplicity
• Communication

• Courage

• Feedback

• Respect
 Extreme Programming (XP)
Values behind XP practices and methods

• Simplicity

• Communication
• Courage

• Feedback

• Respect
 Extreme Programming (XP)
Values behind XP practices and methods

• Simplicity

• Communication

• Courage
• Feedback

• Respect
 Extreme Programming (XP)
Values behind XP practices and methods

• Simplicity

• Communication

• Courage

• Feedback
• Respect
 Extreme Programming (XP)
Values behind XP practices and methods

• Simplicity

• Communication

• Courage

• Feedback

• Respect
 Extreme Programming (XP)

Practice Exercise

The development team is organized into pairs, with each pair working in front of a single workstation.

Which of the five aspects of extreme programming do you think that this
improves?

A. Communication
B. Simplicity
C. Feedback
D. Respect
E. Courage
 Extreme Programming

Mentality of Sufficiency
How would you program if you had all the time in the world?

• Write Tests

• Restructure your code often

• Talk to fellow programmers and with the customer often

 Extreme Programming Practices
Primary Practices
Part 1 Part 2

Sit Together Stories

Whole Team Weekly Cycle
Informative Workspace Quarterly Cycle
Energized Work Slack
Pair Programming Ten-Minute Build
Continuous Integration
Test First Programming
Incremental Design

Corollary Practices : Refer to the resources section

 Extreme Programming Practices
Primary Practices

Sit Together
Whole Team
Informative Workspace
Energized Work
Pair Programming

All members are accessible to

each other
 Extreme Programming Practices
Primary Practices

Sit Together

Whole Team
Informative Workspace
Energized Work
Pair Programming

All the required skills are

available to plan, develop, build,
test & release
 Extreme Programming Practices
Primary Practices

Sit Together
Whole Team

Informative
Workspace
Energized Work
Pair Programming

c
Visual & Information
 Extreme Programming Practices
Primary Practices

Sit Together
Whole Team
Informative Workspace

Energized Work
Pair Programming

c
40 Hours
Sustainable
 Extreme Programming Practices
Primary Practices

Sit Together
Whole Team
Informative Workspace
Energized Work

Pair Programming

c
Pair Programming
 Extreme Programming Practices
Primary Practices

Stories
Weekly Cycle
Quarterly Cycle
Slack
Ten-Minute Build
Continuous Integration
Test First Programming
Incremental Design
 Extreme Programming Practices
Primary Practices

Stories

Weekly Cycle Week 1 Week 2 Week 3 Week …

Quarterly Cycle
Slack
Ten-Minute Build
Continuous Integration
Test First Programming
Incremental Design
 Extreme Programming Practices
Primary Practices

Stories
Weekly Cycle
Quarter 1 Quarter 2 Quarter 3 Quarter …
Quarterly Cycle
Slack
Ten-Minute Build
Continuous Integration
Test First Programming
Incremental Design
 Extreme Programming Practices
Primary Practices

Stories
Weekly Cycle
Quarterly Cycle

Slack
Ten-Minute Build
Continuous Integration
Test First Programming
Incremental Design
 Extreme Programming Practices
Primary Practices

Stories
Weekly Cycle
Quarterly Cycle
Slack

Ten-Minute Build
Continuous Integration
Test First Programming
Incremental Design
 Extreme Programming Practices
Primary Practices

Stories
Weekly Cycle
Quarterly Cycle
Slack
Ten-Minute Build

Continuous
Integration
Test First Programming
Incremental Design Asynchronous Integration and Synchronous
Integration
 Extreme Programming Practices
Primary Practices

Stories
Weekly Cycle
Quarterly Cycle develop code -> write tests -> run tests
Slack
The practice of Test-First Programming follows the path of:
Ten-Minute Build
Continuous Integration Write failing automated test -> Run failing test -> develop
Test First Programming code to make test pass -> run test -> repeat
Incremental Design
 Extreme Programming Practices
Primary Practices

Stories
Weekly Cycle
Quarterly Cycle
Slack
Ten-Minute Build
Continuous Integration
Test First Programming

Incremental Design