Agile Estimating & Planning

Agile Estimating & Planning
V. Lee Henson CST

1

An Introduction To Estimation &

Copyright 2012 AgileDad LLC Licensed for Classroom Use Only. 2

Founded in 2007 - Salt Lake City, UT

Specialize in Public & Private Certiﬁcation Workshops
& Courses

Deep understanding of Agile & Traditional Project
Management, (PMP), RUP, Lean, Kanban, Scrum, (CST),
XP, & PMI-ACP

Proven Applied Agile Principles in Software, Hardware,
Financial, Insurance, Construction, Medical,
Marketing, Legal, Entertainment, Research, Military,
Government, Retail, Education, Law Enforcement, and
many more...

3

V. Lee Henson CST

Certified Scrum Trainer

Project Management Professional

PMI- Agile Certified Practitioner

Certified Lean Agile Professional

Motivational Speaker & Executive
Coach

Author of The Definitive Agile
Checklist

Inventor of Rapid Release Planning

Information Technology / Psychology

4
Copyright 2012 AgileDad LLC Licensed for Classroom Use Only.

Objectives:

Learn about the Agile Planning
& Estimation Mindset (Why?)

Learn best practices when it
comes to Agile Planning &
Estimating techniques (How?)

Do all we can to be open
minded & enjoy the session!


Defining Agile:
✤ ag·ile [aj-uhl, -ahyl] -
adjective

1. quick and well-coordinated
in movement; lithe: an agile
leap.

2. active; lively: an agile
person.

3.marked by an ability to think
quickly; mentally acute or
aware:


The Agile Manifesto
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 & Interactions over processes & 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.


Agile vs. Plan Driven


Scrum vs. Waterfall


Agile Software Development:

Agile software development is a conceptual framework for software engineering
that promotes development iterations throughout the life-cycle of the project.
Agile minimizes risk by developing software in short amounts of time. Software
developed during one unit of time is referred to as a sprint, which may last from
one to four weeks.
Each sprint is an entire software project: including planning, requirements
analysis, design, coding, testing, and documentation. A sprint may not add
enough functionality to warrant releasing the product to market but the goal is
to have an available release (without bugs) at the end of each iteration.
At the end of each sprint, the team re-evaluates project priorities.


A Sobering thought...


A Sobering thought...

It is possible to ﬁnish
on schedule
and under budget,
but still not deliver
anything of value.


Agile Really Means:
Customer satisfaction by rapid, continuous delivery of useful software
Working software is delivered frequently (weeks rather than months)
Working software is the principal measure of progress
Even late changes in requirements are welcomed
Close, daily cooperation between business people and developers
Face-to-face conversation is the best form of communication
Projects are built around motivated individuals, who should be trusted
Continuous attention to technical excellence and good design
Simplicity
Self-organizing teams
Regular adaptation to changing circumstances


Learning Lean Principles:

Higher Quality: “Designed-to-ﬁt” product
with ﬂexibility to change.
Increased Throughput: Iterative and
incremental project and product “chunks” with
earlier value delivery.
Reduced Waste: Lean, efficient processes
with lower costs and higher productivity.
“Measure Up”: Fewer, but more meaningful
measures


Roles - Who Is ‘The Team’?
Most Agile methods profess the
use of 3-5 different roles.

Many teams adopting Agile
struggle to determine where
their traditional roles ﬁt into an
Agile landscape

Every role ﬁts into 3 Simple
classes:

Customer

Facilitator

Implementor

The 3 C’s of a Good User Story:

1) The Card - The topic of the backlog item, the high level
description of the desired system behavior.

2) The Conversation - Detailed requirements are only
discovered after the backlog item has been pulled into a sprint.
This is a dialog between the product owner and the
development team.

3) The Conﬁrmation - Criteria that insures the backlog item
was completed to the speciﬁcations of the product owner. The
customer will evaluate the competed backlog item against the
acceptance criteria, and if all tests pass, approve the backlog
item by the end of the sprint.

Writing a Good User Story
Description Template:

As a _________________________ I would like to
__________________ so that ________________________________.

Example: As a (role or persona), I would like to (execute an
activity), so that I can (see or achieve a value or beneﬁt).


Product Backlog Design:

High
Each Sprint implements All possible system features
The highest priority features are captured in a stack rank
ordered list called the
Each new feature is product backlog.
Prioritized & added to the stack

Features may be reprioritized
New features can be added
At any time to the backlog at any time.

Features may be removed Features in the backlog have
At any time
a gross estimate of effort
and or value.
Low
Features

Breaking Down The Work:


The Index Card:
Business Priority MoSCoW

H-M-L Title - The title should be 10 words or less. M-S-C-W

Description- As a ________
I would like to ______________________________
so that ______________________________.

XS - S- M
- L - XL

PO T-Shirt Size

What About Business Priority?
We all know the business has a
3 point ranking scale for priority
of backlog items: High, Really
High, or Really Really High.

The business needs to use tools
to help them understand that
not everything can be of the
highest priority.

With the understanding that we
Two websites to assist with priority: would not be doing the work if it
http://dotmocracy.org were not important, which items
http://www.innovationgames.com have the greatest urgency? Can
we arrange them into High,
Medium, and Low categories?


Time vs. Relative Complexity:

Let’s paint the room!

How many hours will it take?

Why all of the different answers?

Have any of you painted before?

Compared to something else
you have painted, would it be
easier to determine how difficult
it would be to paint the room?

Is it easier to reach consensus?


Planning Poker - Does It Work?


Let’s Use a T-Shirt Size...
Smaller Than XS = a Task.

Extra Small = 1

Small = 2

Medium = 3

Large = 5

Extra Large = 8

Larger than XL = an Epic


Understanding MoSCoW:
MoSCoW = more than a Russian Capital

Must Have

Should Have

Could Have

Would Like

Every iteration should have a mix of
the above types of items.

Stake holders LOVE the Would Likes.

The Product Owner drives the product
backlog and creates the rank order
based heavily on the MoSCoW ratings.


Understanding Velocity:

The rate at which a team can produce working software

Measured in non-time-referent terms (e.g., Story Points) per Sprint

More accurately stated, it is measured in terms of the stabilized
number of Story Points a team can deliver per sprint of a given
length, and with a given deﬁnition of Done.

Used for estimation and planning

Can be artiﬁcially increased by cutting corners on quality

Must have stabilized to be reliable

Should not be used as a measure of comparison across teams

Lean concept of Limiting Work to Capacity


Velocity - An Example:

Example: Team A is working in 2-week
sprints on work that it has estimated
together. Team A has been working together
for several sprints, and consistently delivers
between 18 and 23 points of working
software every sprint.

We could reasonably expect Team A to
deliver roughly 20 points per 2-week sprint,
and so we consider that to be the team’s
velocity for planning purposes.

If there are eight 2-week sprints in a release,
we can extrapolate that Team A has the
capability to deliver 160 points in a release.


Connecting The Dots:

Size (complexity) is estimated
A story is estimated to be 3 story points in relative
complexity

Velocity is measured
“Team A can deliver 20 story points in a 3-week
sprint”

Duration is derived
- “Based on Team A’s measured velocity of 20
story points per sprint, it will take Team A 3
sprints to deliver 60 story points.”


In Other Words...

Backlog Item estimates answer the
question “how big?”, rather than “how
long?”

Size estimates and observed Velocity,
used together, are answer the question
“how long?”


Five Levels of Agile Planning:
• A great place to start is by analyzing the levels of Agile Planning and
assessing if each party played in their respective sandbox.
Product Vision
Yearly by the product owner

Product Roadmap
Bi-yearly by the product owner

Release Planning
Quarterly by the product owner and team

Iteration Planning
Bi-weekly by the team

Daily Planning
Daily by the team and individuals


Vision & Strategy
✤ Executives & high level managers are
responsible for creating & adhering
to a corporate or more global vision.

✤ Product Owners & other managers
with the help of executives form the
strategy to achieve the vision.

✤ The team is responsible for doing
everything possible to execute on the
vision by completing the work from a
rank ordered product backlog.

✤ The Strategy is the most overlooked
portion of the project preparation.

✤ Without both a vision & strategy the
project will certainly fail.


The Product Roadmap:
✤ The Product Owner:

✤ Helps determine when releases are best
needed.

✤ Determines what functionality will be
sufficient.

✤ Focuses on value derived from the release

✤ The Delivery Team:

✤ Sees the entire vision in consumable chunks.

✤ Learns about next plausible steps.

✤ Learns the business priorities.

✤ Provides technical input to the roadmap.


Value of Rapid Release Planning:

✤ Allows for planning for a series of iterations at a high level,
reducing waste in planning detailed tasks for requirements we
are uncertain about.

✤ Allows for communication of the entire scope of the release to
project teams and stakeholders around a high level plan.

✤ Protects the ability to remain ﬂexible and ‘agile’ by embracing
changes in requirements.

✤ Serves as a guide, a baseline, and is expected to be updated
based on collaboration and the emerging product.


Value of Release Planning Realized:
✤ Understand the need for human and
other resources as the macro release
level; understand possible decision
points for make vs. buy, integration,
etc.

✤ Provides the customer and leadership
with an idea of how a large project is
progressing.

✤ Involves the team in its creation, which
means more buy-in, accuracy, and
empowerment.

✤ “I know things in a project are going to
change, but in my agile projects, I know
this information much sooner which
allows for good decision making.”

✤ ~ Joe CEO


Sprint Planning - Six Steps
✤ 1) Schedule items into a sprint making certain not to exceed the teams
projected velocity. (If you did Rapid Release Planning, this step is done)

✤ 2) Review Team member capacity to ensure that people will not be over
allocating themselves.

✤ 3) Detail Planning - Breakdown the work into tests and tasks. (No
estimating or signing up for the work should take place during this step.)

✤ 4) Member Planning - Allow team members to sign up for the work they
choose and give an estimate in hours as to how long each task will take to
complete.

✤ 5) Review open issues and impediments that may put any item in the sprint
at risk. Replace items as needed with approval from the product owner.

✤ 6) COMMIT to the sprint as a team! (Let’s do this!)


The Daily Standup Rules:
✤ Daily 15 minute or less ✤ Do not be late...
meeting
✤ Fines go to a reputable charity
✤ Same time same place
everyday ✤ Team stands in a circle
✤ No problem solving ✤ Chickens around the outside
✤ * No Electronics of any kind ✤ Chickens follow the same rules
✤ No pen and paper to record ✤ Stick to the three questions
✤ Team rules posted on the wall ✤ Always end on time


Sprint Review

✤ The team meets with the
product owner to validate
any work that was not
marked as accepted during
the sprint cycle

✤ The product owner often
asks to see the working
product to validate that it
meets acceptance criteria
and is ready for demo


Sprint Demo
✤ The team presents what it
accomplished during the
sprint.

✤ Typically takes the form of a
true demo displaying new
features and architecture.

✤ All interested parties can
attend

✤ No Powerpoint or Remote
Desktop for the demo.


Importance of the Demo
✤ Always start with a list of incomplete features. This helps
maintain trust by not hiding undone work.

✤ Show all of the completed work an accept feedback on the
outcome.

✤ The team & customer should have a chance to respond to
delivery.

✤ The end goal is collaborative decision making about the future
of the product.


Sprint Retrospective
✤ Inspect & adapt at the end of
every sprint.

✤ Attended by the team,
ScrumMaster, and Product
Owner.

✤ Facilitated by the SM or other
objective third party.

✤ ScrumMaster prioritizes
improvements based on team
direction.

✤ The team devises solutions to
the most vexing problems.


✤ You now hold the keys to success!

✤ You have been educated and empowered.

✤ Visit often and drink from the well!

http://www.agiledad.com/

Thank You!
Lee@AgileDad.Com- Twitter @AgileDad - LinkedIn leehenson@gmail.com


Agile Estimating & Planning

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Agile Estimating & Planning

Ähnlich wie Agile Estimating & Planning (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Agile Estimating & Planning

Hinweis der Redaktion