Agile Estimating and Planning

Course Book

“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”
― Abraham Lincoln
Agenda

Module 1 – Introduction to Agile Methods

Module 2 – Introduction to Estimating and Planning
Module 3 – Planning: Traditional VsAgile
Module 4 – Levels of Agile Planning
Module 5 – Planning Techniques
Module 6 – Estimating Techniques
Module 7 – Planning Requirements
Module 8 – Monitoring and Tracking
Module 9 – Workshop: Planning a Product

2
 But before…

Let’s define the goals for this training.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 3
Module 1

Introduction to Agile Methods

“The measure of intelligence is the ability to change.”

― Albert Einstein

4
 Origins

1900: TPS -> Lean

1970: “Waterfall”

1986: Scrum

1996: RUP

2001: Agile

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 5
 1900…: TPS -> Lean

History
• Beginning of 20th century: Jidoka (automated supervisory functions) – Sakichi Toyoda
• 1934: JIT (Just In Time -­­ Kanban signals) – Taiichi Ohno
• 1936: Kaizen (Good change -­­ Continuous Improvement) -­­ Taiichi Ohno
• – …
• TPS (Toyota Production System) –> Lean (US)

Facts about Toyota (“The Toyota Way” by Jeffrey Liker, 2004)

• $8.13 billion profit in 2003, larger than the combined earnings of GM, Chrysler and Ford.
• Has the fastest product development process in the world (12 months or less to design while
competitors require 2/3 years)
• Recalled 79% fewer vehicles in the US than Ford and 92% fewer than Chrysler.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 6
 1970: “Waterfall”

“…the simpler method has never worked on large

software development efforts…”
in Managing the Development of Large Software
Systems by Dr. Winston W. Royce, 1970

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 7
 1986: Scrum

“In today's fast-­­paced, fiercely competitive world of commercial new product development, speed and
flexibility are essential. Companies are increasingly realizing that the old, sequential approach to
developing new products simply won't get the job done.” in “The New Product Development Game” by
Hirotaka Takeuchi and Ikujiro Nonaka, 1986

Six characteristics:
Built-­­in instability
Self-­­organizing project teams
Overlapping development phases
"Multilearning”
Subtle control
Organizational transfer of learning

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 8
 1996: RUP (Rational Unified Process)

6 best practices:
Develop iteratively, with risk as the primary iteration driver
Manage requirements
Employ a component-­­based architecture
Model software visually
Continuously verify quality
Control changes

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 9
 1996: XP (Extreme Programming)

Rules about: Planning rules:

Planning User stories
Managing Release planning
Coding Small releases
Designing Iterations
Testing Iteration planning
*All Registered Trademarks and Service Marks are the property of the Project Management Institute 10
 2001: Agile

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

All of the 12 Agile Principles define the way we need to plan and estimate Agile products:
Continuous delivery
Welcome changing requirements, even late in development
Face-to-face communication
Working software is the primary measure of progress
Technical excellence
Simplicity
Self-organizing teams
*All Registered Trademarks and Service Marks are the property of the Project Management Institute 11
 2001: Scrum

Events
Product Refinement
Sprint Planning
Daily Scrum
Sprint Review

Pillars
Transparency
Inspection
Adaptation

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 12
 What is agile?

In one sentence
• Everything we can do to continuously deliver maintainable value within a mutable
environment

What problems to solve?

• Products complexity
• Mutability
• Team’s motivation and communication
• Deliver the right value sooner

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 13
 Agile & Lean

Agile
Individuals and interactions over processes and tools
Working software over comprehensive documentation Lean
Customer collaboration over contract negotiation Eliminate waste

Responding to change over following a plan Amplify learning

Decide as late aspossible
Deliver as fastas possible
Empower the team
Build integrity in
See thewhole

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 14
 Lean: Seven Muda (Waste)

Manufacture Software
Over Production Too many features within a MVP
Time on Hand Too many features to review

Transportation Operational waste to move releases between environments

Processing itself Right people and tools

Movement Too many dependencies and processes

Defective products Fixes and testing support \ Technical debt

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 15
 Agile: From theory to practice

Mind-set Act

A g ile Fra m e wo rks Te c hniq ue s To o ls Methodology De live ry

SAFe
DAD
DSDM
LeSS
Nexus

Scrum
Kanban

XP Agile Scrum, DSDM, Iteration, Choose the Define the Apply the
Manifesto DAD, XP, Backlog, techniques rules process
Kanban, SAFE Boards
Agile
Agile, Lean: Premises, Values, Principles
Lean XP: Practical techniques to improve software quality
Scrum, Kanban: Framework to define a team cadence
LeSS, SAFe, DAD, DSDM, Nexus: Framework to scale Agile

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 16
Module 2

Introduction to Estimating and Planning

“Plans are of little importance, but planning is essential.”

― Winston Churchill

17
 Why we plan?

We need to ensure that we are always working on the most important thing we need to do.

We need to coordinate with other people.

When unexpected events occur we need to understand the consequences for the first two.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 18
 Planning premises

Priorities: The Team must choose the best possible features to implement.
Resilience: The Team must react as positively as possible to the inevitable setbacks.
Transparency: The Team must not over commit, or they will slow down. The team must not under
commit, or customers won't get value for their money.
Inspect and Adapt: The Team must figure out clearly where they are and report this accurately, so
that everyone can adjust their plans accordingly.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 19
 What are customers afraid of?

They won't get what they asked for.

They'll ask for the wrong thing.
They'll pay too much for too little.
They must surrender control of their career to techies who don't care.
They won't ever see a meaningful plan.
The plans they do see will be fairy tales.
They won't know what's going on.
They'll be held to their first decisions and won't be able to react to changes in the business.
No one will tell them the truth.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 20
 What are the developers afraid of?

They will be told to do more than they know how to do.

They will be told to do things that don't make sense.
They are too stupid.
They are falling behind technically.
They will be given responsibility without authority.
They won't be given clear definitions of what needs to be done.
They'll have to sacrifice quality for deadlines.
They'll have to solve hard problems without help.
They won't have enough time to succeed.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 21
 What is an estimate?

Are you sure about what an estimate is?

How much time does it take to go the reception and ask for a pen?

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 22
 Estimate Definitions

A tentative evaluation or rough calculation

A preliminary calculation of the cost of a project
A judgment based upon one's impressions

Is that what usually executives ask for?

Executives are often asking for a commitment or for a plan to meet a target.

Estimates != Targets != Commitments

When you're asked to provide an estimate, determine whether you're supposed to be estimating or
figuring out how to hit a target.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 23
 Estimation and Planning: Relationship

Estimation is not planning, and planning is not estimation.

Combining the two tends to lead to poor estimates and poor plans.
The presence of a strong planning target can lead to substitution of the target for an analytically
derived estimate.

EXECUTIVE: How long do you think this project will take? We need to have this software ready in 3
months for a trade show. I can't give you any more team members, so you'll have to do the work with
your current staff. Here's a list of the features we'll need.
PROJECT LEAD: OK, let me crunch some numbers, and get back to you.
v
Later…
PROJECT LEAD: We've estimated the project will take 5 months.
EXECUTIVE: Five months!? Didn't you hear me? I said we needed to have this software ready in 3
months for a trade show!

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 24
 What is a good estimate?

The process is called estimation, not exactimation.

—Phillip Armour

The one that at a certain moment can be more accurate and will help the Team to make valuable
decisions.

Don't intentionally underestimate. The penalty for underestimation is more severe than the penalty for
overestimation.

Include all necessary software-development activities in your estimates, not just coding and testing.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 25
Module 3

Traditional Vs Agile Planning

“Tradition becomes our security, and when the mind is secure it is in decay.”
― Jiddu Krishnamurti

26
 Planning – Agile Vs Traditional

Agile Traditional

Bottom up discovery Top down management

Continuous and frequent delivery Large big bang releases

Shared ownership and cross functional

Document oriented
teams

Welcome change Resistant to change

Management escalation when problems

Teams solve the problems
arise

Emergent and simple analysis and design Big upfront analysis design

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 27
 Traditional planning

Plan activities, not deliverables

Rely on strict sequencing
Time over runs are passed to the next phase
Assert that the end result is known
Changes are evil

End up with unreal plans…

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 28
 Agile Planning

A good Agile plan is

• Clear
Can I explain to my mom?
• Reliable
• Simple
• Available
• Honest
Plan constantly, not just in the beginning.
Planning is an activity, not just a document.
Do not try to control change, encourage it.
Always be transparent.
Focus on historical performance, not hyper-optimal scenarios.
Changing the plan does not mean changing the timing.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 29
Module 4

Levels of Agile Planning

“Life is what happens to you while you are busy making other plans.”
― Allen Saunders

30
 Levels of Agile Planning

Company Vision

Business Strategy

Product Strategy

Product Roadmap

Release Plan

Iteration Plan

Daily
Plan

*All Registered Trademarks and Service Marks are the property of the Project Management Institute
 Frequency of Change

Company Vision
Less
Business Strategy
Frequent
Change

Product Strategy

Product Roadmap

Release Plan
More
Iteration Plan
Frequent
Change
Daily
Plan

*All Registered Trademarks and Service Marks are the property of the Project Management Institute
 Level of Accountability

Company Vision

Executives
Business Strategy
Department Leaders
Architecture

Product Strategy
Customer
Advocates
Product
Product Roadmap
Management
Partners
Product Owner Release Plan

Implementation
Iteration Plan
Team

Daily
Plan

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 33
 Artefacts of Agile Planning

Company Vision
Mission or Vision Statements

Business Strategy
Business Plans / Revenue Targets

Product Strategy
Architecture

Product Roadmap
Product Backlog

Release Plan
Agile Teams
Iteration Backlog
Live Here
Iteration Plan

Daily Task List

Daily
Plan

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 34
 Our Main Focus

Product Release Plan

Product Backlog

Iteration Backlog

Daily Plan

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 35
 Blueprint for PMP® Exam Preparation Success

Programme Ownership Delivery Ownership

Portfolio Ownership Product Ownership

Inspection
Vision Service Epic Story Task
(Review)

Iteration / WIP Adaptation

Company’s Vision Services Backlog Product backlog
Backlog (Priorities)

Iteration / WIP
Vision Wall Programme Wall Product Wall
Wall
Adaptation
(Visibility)
Roadmap

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 36
 Inception Phase - Example

1 to 3 days 1 to 5 days 1 to 10 days N Increments

Incremental
Initiation Feasibility Foundation
Delivery

Vision Benefits Enough

Alignment Value Services
Product Portfolio Product
Sponsor Owner Owner
Portfolio Program Technical
Owner Owner Owner
Program
Enough
Owner Funds
Architecture
Product Technical
Sponsor Owner
Enough
Infrastructure
Operational
Owner

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 37
 Inception Phase Events - Example

Initiation

Initiation Product Workshop

Feasibility Product Workshop Technical Workshop Commercial Workshop Agile Training

Foundation Product Workshop Technical Workshop Product Planning Agile Training

Incremental Delivery Agile Events

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 38
 Agile Product Flow - Example

PRODUCT FLOW
Ready for
Ready for Ready for
Elaborating
Product
Refinement Sprint UAT Live
Product Lead
Ready for Ready for In Sprint Ready for Time
Technical Sprint Live
Planning Planning

Development Cycle Time

Live Cycle Time

Elaboration Cycle
Time

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 39
 Agile Development Flow - Example

DEVELOPMENT FLOW

Developing Reviewing Testing UAT

Ready for Ready for Ready for Ready for

Dev. Review Release Release

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 40
Module 5

Planning Techniques
Delivering What Matters

“Remember : don’t let the uncertainty about your future paralyze your present.”
― Stefanie Weisman

41
 What do we need to plan?

Roadmap
Product Backlog
WIP\Iteration

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 42
 Product Workshop

Define what Define the

Why? problem or need benefits

Link with the

Define the main
What? services
needs and
benefits

Not in the
How? scope

Not in the
When? scope

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 43
 Product Workshop

Define what Define the

Why? problem or need benefits

Link with the

Define the main
What? services
needs and
benefits

Emergent
How? architecture

Main Rough estimates

When? dependencies (usually t-­­shirt
size)

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 44
 Product Workshop

Link benefits with

Why? technical
dependencies

Define
What? roadmap

How? Not in scope

Align roadmap
with team's
When? capacity

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 45
 Main goal

Keep an ordered Product Backlog

Depending on the complexity of the product, we need to have less or more product planning.

How?
Continuous review of the Roadmap
Continuous review of the Product Backlog

Main technique: use just a sequential order

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 46
 Define Priorities – Other Techniques

MoSCoW Priority
Must Very High
Should High
Could Normal
Won’t Low
Very Low

WSJF (Weighted Shortest Job First)

- The job with the highest WSJF is the next most important job to do

Scale: Fibonacci

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 47
 Planning requirements

Product Refinement

Goal: Understanding the requirements

Output: More detailed estimate (usually story points)

Stories may need more analysis or they become ready for Sprint Planning

All the team members should be included

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 48
 Planning the stories

Scrum/XP
Sprint Planning – Defined cycle
Goal: What and how much we can bring to an iteration
Output: List of stories and tasks, usually with further estimates

Kanban
Planning – Whenever the team decides to do it
Goal: What can be ready to be developed
Output: List of stories and tasks usually with less details, estimates

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 49
 Planning Ownership

Product Owner owns what needs to be done and in what order. Therefore, he\she decides what will
be in the product Refinement.

Development Teams own how stories need to be done, so they are the ones deciding what can
be included in each sprint.

Therefore, POs need to make sure the stories are solid enough to be developed, but
Development Teams need to be open to a level of uncertainty as well.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 50
 Planning in a nutshell

Business to define a vision

Business to define the needs and benefits
Business to define roadmap involving technical input
Business and technical teams to refine and order the backlog
Technical teams to really plan the work to be done

Do this continuously – Shorter cycles the better

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 51
 Multiple Teams for the same Product

Keep just one Product Backlog

Have a session to distribute stories across teams. This session should be before Product
Refinement. Usually PO\BAs and the Scrum Master run this session.

Keep a good balance:

Improve performance Vs Sharing knowledge
Exciting work Vs Boring work

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 52
Module 6

Estimating Techniques
Making Informed Decisions

“All you need is a product vision and enough top priority items on the backlog to
begin one iteration...”
― Ken Schwaber
53
 Long term estimates

To be used during Product Workshops and Technical Planning sessions:

Quarters or Trimesters: roadmap view

Weeks: 1 week, 6 weeks…
T-Shirt Size: Small, Medium, Large, Extra Large, Extra Extra Large

Initial rough estimates help the business to order the Product Backlog.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 54
 T – Shirt Size

Can be linked to weeks (example): Can be linked to story points (example):

Small: 1 to 2 weeks Small: 1 to 3 story points

Medium: 2 to 4 weeks Medium: 5 to 8 story points
Large: 4 to 8 weeks Large: 13 to 20 story points
Extra Large: 8 to 20 weeks Extra Large: 20 to 40 story points
Extra Extra Large: 50 weeks Extra Extra Large: 100 story points

When starting a new product it is difficult to make a relationship between t-shirt size and
weeks\story points.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 55
 Short term estimates

To be used during Product Refinement and Work Planning sessions:

Story points
- Fibonacci: 1, 2, 3, 5, 8, 13, 20, 40, 100
- Should be defined during Product Refinement

Days
- Examples: 0.5 days, 1 day, 2 days…
- Option for Work Planning for stories and\or tasks

Hours
- Examples: 1 hour, 2 hours, 10 hours…
- Option for Work planning for stories and\or tasks

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 56
 Estimates and Iteration Planning

If using story points Product

- Pre-requisite Backlog
- Keep track of sprint velocity (how Backlog
Iteration
many story points are done in an
Backlog
Iteration) average
- Keep planning until you reach that
average

If using days or hours

- Pre-requisite
- Understand team’s capacity in days
\hours
-Keep planning until you reach the number
of days\hours the team can do

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 57
 Iteration: Snapshot technique

Day 1 Day 2 Day 3 Day 4 Day 5

John Story A Story B Bug 1

Mary Story C Story G

Ricardo Story T

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 58
 Planning Poker

A moderator (usually the product owner or an analyst) reads the description.

After discussion, each estimator privately selects a Planning Poker card representing his or her
agile estimation.

Once each estimator has made a selection, cards are simultaneously turned over and shown so
that all participants can see one another’s estimate.

If the estimates differ too much, people can talk more and re-estimate again.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 59
 Estimates - Review

Velocity Based Commitment Based

User's average velocity over time or Team commits based on what they believe to
user’s velocity of last iteration be true right now

Most useful with long historical record Likely to lead to realistic expectations

Unreliable in what can be

Uncover future impediments now
accomplished

Assumes conditions are constant

Forces team to be deliberate in their thinking
across iterations

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 60
 Estimates - Review

Programme Delivery
Ownership Ownership

Portfolio Product
Ownership Ownership

Inspection
Vision Service Epic Story Task
(Review)

Company’s Services Product Iteration\WIP Adaptation

Vision Backlog Backlog Backlog (Priorities)

Vision Programme Product Iteration\WIP

Wall Wall Wall Wall
Adaptation
(Visibility)
Roadmap

Trimester, Quarter, Months

T-­­Shirt Size or Weeks

Story Points or Days

Days or Hours

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 61
 Tasks breakdown

Can be related with: Technical Task

Technical tasks Create database table 2h
Definition of Done
Write stored procedures 8h
Test Model 4h
Automate the build 5h
Product Backlog Item Schedule DB Backups 2h
As a Hotel owner I 5
want… Definition of Done
As a vacation planner 8
I want… For each story Analysis 2h

As a traveller I 5 Frontend Development 10 h

want… Backend Development 8h
As a traveller I want 13 Integration 4h
Test 2h

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 62
 Velocity

Velocity is a measure of the team’s rate of progress.

It is calculated by summing the number of story points assigned to each user story the team
completes during the iteration.

If the team completes 3 stories each estimated at 5 points, their velocity is 15.

Because story points are a relative measure, it does not matter if the team works on two 5 point
stories or 5 two point stories.

By summing the total story points estimates of all desired features, we can come up with a
total size estimate for the project.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 63
 Capacity model

Based on the current velocity and the refined backlog with rough estimates (t-shirt size or story
points), try to better understanding when some epics\stories can be done.

In simple terms:
Team’s velocity in average is 50 story points
We estimated 233 story points in the Product Backlog
Therefore, 233 / 50 = 4.2 = 5 Iterations

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 64
 Levels of contingency

There isn’t a rule, but:

Some features are more complex than others
Some features have more external dependencies
When reaching a major release, capacity decreases
Down the line, changes will be more normal

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 65
 How to communicate?

Product Backlog

Confident this will be delivered

50% will be delivered

10% will be delivered

Delivered in the next release

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 66
Module 7

Planning Requirements

“… I am Convinced that I shall never see a man whom I can really love. I require so much!”
― Jane Austen

67
 A requirement is…

A feature, behaviour, or constraint to be added to a system

A prelude to a conversation
A request for someone to do work
A request for software to change

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 68
 Effective requirements

NASA IEEE
Complete Interfaces
Consistent Functional Capabilities
Correct Performance Levels
Modifiable But can I Data Structures / Elements
Ranked
explain it to Safety
my mom?
Traceable Reliability
Unambiguous Security/Privacy
Verifiable Quality
Constraints & Limitations

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 69
 Invest

Independent

I Negotiable
N
Valuable
V
E Estimable
S
T Sized Appropriately

Testable

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 70
 Typical hierarchy

Business need A

Theme/ Theme \Service n..

Service 1

Epic 1 Epic n…

Story 1 Story n..

Task 1 Task n….

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 71
 Requirements hierarchy: Example

Reduce calls to the

help desk

Account
Manager Online FAQ

Updating
Accounts Single Sign on

Simplify UI Improve
form validation rules

UI
Development Integration Test

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 72
 Story

A short & simple description - 3Cs

Card

Story information is lightweight. It fits onto a single index card.

Conversation
When the story is selected for a Sprint, further details are finalized in
conversations with the Product Owner or Business Analysts.

Confirmation

Confirm the feature was implemented properly.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 73
 Story Template

As a traveller, I want to As a vacation planner, I

reserve a hotel room, want to see pictures
so that I can stay of the hotels, so that I
As a <Role> indoors. can plan better deals.

I want <Feature>

So that <Benefit> As a user with As a hotel owner, I

reservation, I want to want to see a report of
cancel my reservation, all cancellations, so
so that I can get that I can review
refund. them.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 74
 Stories - Benefits

They are simple to write and understand.

Software requirements is a communication problem.
They elicit detail in conversations.
Requirements analysis is effective when performed collaboratively.
They promote inclusive culture.
Full intent can rarely be modelled or represented 100%.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 75
 Stories - Good sign

Focus shifts from writing to talking.

Stories are understood by customer and developer.
At estimation time, they are the right size.
Participative design is occurring.
Emphasis is on the user’s goal, not the system’s attributes.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 76
 Acceptance Criteria

Acceptance Criteria for a Story specify exactly how it must behave, look or respond to be regarded
as “Done”.

Suggested format:

Given <some preconditions> When <an action is

performed> Then <this will occur>

They are a much finer grained requirements definition than the Story.
They help form the basis of functional test cases.
They assist the developers and testers when estimating the Story.
They can be supported by other information like screenshots or UI wireframes, design
documents, or anything that provides more detail about what should be implemented.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 77
 Acceptance Criteria: Example

As a user with reservation, I want to cancel my reservation

so that I can get a refund.

Given I am a premium member, when I cancel under 24

hours, then I incur no penalty.

Given I am a non-premium member, when I cancel under

24 hours, then I pay 50% penalty.

Given I am a site member, when I cancel my reservation,

then I am emailed a confirmation.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 78
 Types of stories

User story: from a persona (role) perspective

Technical story: generic technical work to support several user stories. Usually they are
related with NFR (non functional requirements)
Spike: investigation – usually time boxed
Refactor: refactoring work to reduce technical debt

Define your own types but keep it simple…

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 79
 What about bugs?

Fact 1: It is impossible to predict how many bugs we will have.

Fact 2: But we can reduce the probability of them happening.
Fact 3: Majority of the bugs are “business” ones instead of technical ones.
How to reduce bugs:
Involve the technical team as soon as possible when creating the stories.
Promote shared ownership.
Creating a Story: BA and PO are the owners, but testers and developers need to provide feedback
When developing a story:
Before: “3 Amigos” – Conversation between BA\PO, developer and tester to mainly review the
acceptance criteria
During: short feedback loop… showing what is being done
After: PO\BA available to review right after it is done

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 80
 Technical bugs

Reduce technical debt and share knowledge

• Code Reviews
• Pair Programming
• Don’t “give” a story to the expert

Automation
• Unit tests
• Automation tests
• Right balance between low, medium and high tests

Keep planning NFRs and including them in the Agile lifecycle

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 81
 Bugs and an Iteration

Bugs indeed affect the Iteration. If a bug appears unexpectedly and requires 5 days from a developer,
probably one or more stories won’t be done during that Iteration.
Define the right priority of the Bug.

Example:
• Blocker: must be fixed right away. Hotfix must be deployed.
• Critical: must be fixed during the current iteration and deployed in the next release.
• Major: must be developed during the next couple of Iterations.
• Nice to have: fixed when the team has capacity.
• Not a bug: not to be fixed.

When a bug appears and it is blocker, critical or major, try to get a rough estimate and understand
what stories need to be removed.
Some capacity models already include a percentage for bugs.

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 82
Module 8

Monitoring and Tracking

Because it’s important to be on track

“Attitude is an accurate monitor of where we fall on the spectrum of pride and

humility”
― Erwin Raphael McManus
83
 Product Burn-up Chart

Displays outcome of each iteration

Increase in scope/
added new features Indicator of performance relative to
goal

Feature Completion Graph

Story Points

7 Iterations

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 84
 Iteration Burn-down Chart

Displays Remaining Work on

Sprint Backlog

Updated Daily
Story Points

Indicator of Sprint Progress

10 Day
Iteration

Days

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 85
 Continuous Delivery

Ideal Mini
Waterfall

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 86
 Release Burn-down Chart

Displays Remaining Work on

Product Backlog

Indicator of Release Progress

Story Points

Updated at the end of iteration

7 Iterations

Iteration

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 87
 Velocity Chart

Projection Based on Velocity

40 Mean (Best 3) = 37
Mean (Last 8) = 33
Points 30 Mean (Worst 3) = 28

20
10
0
1 2 3 4 5 6 7 8 9 Sprints

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 88
 Kanban Cumulative Chart

Understand continuous flow…

Keeping it simple but including the status will keep the flow transparent
Look for patterns
Scope decreased Scope increased
600

500
Story Points

400
Done
300
Doing
200 To Do

100

0
Week 1 Week 2 Week 3 Week 4 Week 5 Week 6

*All Registered Trademarks and Service Marks are the property of the Project Management Institute 89
End of Agile Estimating and Planning

90
Thank You and Good Luck !!!

www.knowledgehut.com | [email protected]

91