agile planning estimation

Copyright 2010 Code71 Inc. All rights reserved.http://www.code71.com http://www.scrumpad.com

Agile Planning, Estimation, and Tracking

Syed RayhanCo-founder, Code71, Inc.Contact: [email protected]: http://blog.syedrayhan.comCompany: http://www.code71.comProduct: http://www.scrumpad.com

www.Code71.com www.ScrumPad.comCopyright 2010 Code71 Inc. All rights reserved.2

Agenda

Recap

Estimation

Section 2

Section 4

Section 3

Tracking

Planning

Section 5

IntroductionSection 1

Q&ASection 6


My Background

Expertise

Career

Iterative incremental development

Technology planning and architecture

On-shore/Off-shore software development using Agile/Scrum

Interests

Co-founder, Code71, Inc., CSP, Agile Coach and Trainer 14+ years of total experience Co-author of “Enterprise Java with UML”

Cultural aspect of self-organizing team Scrum for projects delivered remotely Agile engineering practices Lean Startup


What to Expect

Focus

Context

Build a base for Agile planning

Contrast Agile planning with Traditional Planning

Address typical questions asked

K ey Takeaways

How to perform sprint planning and estimation How to perform release planning an estimation How to track progress against plan How to adjust plan as project evolves

Teams and organizations are adopting Agile/Scrum

Teams struggle with making the transition from waterfall to

Agile/Scrum


Agenda

Recap

Estimation

Section 2

Section 4

Section 3

Tracking

Planning

Section 5


Q&ASection 6


Waterfall Project Planning

Project can be accurately planned in details


In reality, software projects are like…

forecasting weather- rain or

shine?


Planning

WaterfallAgile

All or noneIterative, incremental

Priorit ization is not importantPriorit ization is key activity of planning

Planning becomes a prioritization exercise

Crit ical path is eliminated through t ime boxing

Crit ical path is important

PredictiveEmpirical


How to do prioritization?

Informal

MoSCoW

Ad-hoc and intuit ive

Must have, Should have, Could have, Would not have

FormalCalculated Priority = Business Value/Complex ity

ROI (= Business value – Cost) based priorit ization

K ano Mandatory, Linear, Exciter


MoSCoW

Must haves

Should haves

Minimum Usable SubseT for production (a.k.a. Minimum Viable Product)

Important, but absence of it would not make the product useless

Could haves

Optional, if fund and t ime are available

Would not haves

Out of scope, defines the boundary of the product

Pros and Cons?


Minimum Viable Product (MVP)

Release#1 R#2 R#3

Expanding scope of MVP Release every sprintideal


Kano Analysis

Survey

Q#1 Rate your satisfaction if the product has “this” feature?

Q#2 Rate your satisfaction if the product does not have “this” feature?

Answers: A) Like it, B) Neutral, C) Dislike it

Additional Question for trade-off analysis

How much extra would you pay for “this” or more of “this” feature?


Kano Analysis

Like

-

Neutral Dislike

?

E I

L T

L

?

-

Q#2 (A

bsence of a feature)

LikeN

eutral

Dislike

Q#1 (Presence of a feature)

- disregard, ? probe further, I indifferentE exciter, L linier, T threshold


FormalBV

HighComplexity Priority

Low

Medium

Medium Low

Low Low

Medium

Medium High

Low Medium

1

4?

8

7

5?

6?

Pros and Cons?Low High 9

High Medium

High High

2

3?


Release Planning

• Set a release goal

• Determine scope through prioritization

• Determine a release date

• Define sprints

• Allocate stories to sprints

• Product backlog grooming

• Ideally release every sprint


Sprint Planning

Capacity Scope Estimation

• Load factor

• Availability factor

• Holidays

• Vacations

• Set a sprint goal

• Take stories from the top of the product backlog

• Total points = Velocity

• Task breakdown

• Estimate tasks in actual hours or days

• Assign task owners

• Assign a story owner

• Verify estimate against capacity


Rules of thumb for Sprint Planning

• Tasks should be between 4 -16 hours

• For a two-week sprint (most popular sprint length)

• 2-4 hours planning

• 1-2 hours of sprint review

• 1-2 hours of sprint retrospective

• Allocate a fixed hours for production support or other unavoidable routine work (10-15%)

• 10% for product backlog grooming


Sprint 0

• Project initiation sprint

• Business case

• Environment setup

• Architecture

• Team setup

• Team norms

• Training


Integration / Stabilization Sprint

• One or more sprints needed to stabilize a release before final rollout

• Ideally a product is always ready for rollout

• Final integration and regression tests

• Load test

• Any last minute bug fixes

• Production environment setup

• Any other steps (organization specific) needed before production rollout


Rules of thumb• A team size of 7-9

• 1 and half medium stories per developer

• 1 Tester for every two developers

• Do not change sprint length

• Prefer 100% allocation over partial allocation of people


Agenda

Recap

Estimation

Section 2

Section 4

Section 3

Tracking

Planning

Section 5


Q&ASection 6


Unit of Planning


How do we know when we are done?

design+code+unit test functionaltest

architecture load testcode reviewdesign review

regression test


Estimation

Relative

Absolute

small medium large

12 oz 16 oz 20 oz

3 5 8


EstimationRelative

Story points

Absolute

Hours/Days

Used for Release planning Used for Sprint planning

Why relative estimation? Velocity, suitable for longer horizon

Accuracy is not important Accuracy is important to some extant

Eliminates bias Does not eliminate bias

Cannot be compared with another team’s

Supports comparison


Relative estimation using “Planning Poker”

Decide on scale Fibonacci scale (1, 2, 3, 5, 8, 13, 21…)

Identify a reference story set Use most understood story as a reference story for each level on the scale

Estimate the restEverybody estimates individually, then reveals as a team, hence the term “Planning Poker”

Challenges?


How to resolve disagreement in estimation?

Consensus

Majority

Ask the outliers and discuss as a team to agree on an estimate

Pick the one that was chosen by the majority

Choose the highest

To err on the side of caution

Pros and Cons?


Velocity

• Velocity without a quality metric is not useful• Velocity of two teams are not comparable• Velocity changes with team composition• Velocity increases with team’s tenure• Velocity is not productivity• Do not include bugs and rejected stories

Points delivered by a team per sprintDefinition

Keep in mind

• Used to determine sprint scope • Used to calculate approximate costs of a release• Used to track release progress

How to use?

How to calculate? Rolling average of 4 weeks, Max, Min, Lifetime average


Agenda

Recap

Estimation

Section 2

Section 4

Section 3

Tracking

Planning

Section 5


Q&ASection 6


How do you track progress?

50% done

3 stories done, 5 stories remaining

Vs.

Y ou don’t get credit for part ial work

Waterfall

MS Project

ScrumPad

Agile


Tracking progress

Track remaining hours, track done/remaining points by day

Sprint Burndown

Sprint Burnup

Metrics

Release Burndown Track remaining points by sprint

Track time spent by day

Velocity, Bug find rate per sprint, Bug fix rate per sprint,Test coverage


Tracking progress

A 15-minute standup meeting where team answers the following;

1) What did I do yesterday?2) What am I going to work on today?3) What is impeding my work, if any?

Daily Scrum

Sprint Review Team meets with the product owner and stakeholders to show the work done in the current sprint and solicit feedback.

tracking impediments


Continuous Improvement (Inspect and Adapt)

Retrospective

Team meets at the end of each sprint to discuss-

What is working well? What needs improvement? And How to improve/fix it?


Burndowns

• Time spent

• Time remaining

Track Remaining

hours

Track done

Daily time entry


Other charts Tracking

actual time spent

Tracking release

progress


Let’s test our understanding

Difference between relative vs. absolute estimation? How to do resource allocation?

Do you still need a Gantt chart?

How to handle shared resources? How to plan for production support work?

How to plan for fixed bid contract?

What is velocity? Who does planning?

How to improve estimation? How do you ensure team delivers what they plan to deliver in a sprint?


Recap

Prioritize product backlog on an on-going basis

Estimate backlog in story points for release planning

Estimate backlog in actual hours or days for sprint planning

Pick a suitable sprint length and stick with it

Allocate people to a single project in a single sprint

Staff the team in the beginning and keep the team in place through out the life

of the project


Recap contd.

The team should be cross-functional- include testers, Sys admins,

DBA, SMEs

Team should be physically or virtually collocated

Know your team “velocity”

Use open space

Use appropriate information radiators


Q&A

Please contact for on-site training or Webinar:

Contact: [email protected]: http://blog.syedrayhan.comCompany: http://www.code71.comProduct: http://www.scrumpad.com

agile planning estimation

Technology

planning section

release planning

sprint planning tasks

estimation section

tracking section

recap section

agenda section

hours of sprint retrospective