Agile Planning, Estimation, and Tracking Syed Rayhan Co-founder, Code71, Inc. Contact: [email protected] Blog: Company: .

Agile Planning, Estimation, and Tracking

Agile Planning, Estimation, and Tracking

Syed Rayhan

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

2www.Code71.com www.ScrumPad.com

Copyright 2009 Code71, Inc.

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



What to Expect

Focus

Context

Build a base for Agile planning

Contrast Agile planning with Traditional Planning

Address typical questions asked

Key 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

Prioritization is not importantPrioritization is key activity of planning

Planning becomes a prioritization exercise

Critical path is eliminated through time boxing

Critical path is important

PredictiveEmpirical



How to do prioritization?

Informal

MoSCoW

Ad-hoc and intuitive

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

Formal Priority = Business Value/Complexity

ROI (= Business value – Cost) based prioritization

Kano Mandatory, Linear, Exciter

Threshold, Performance, Excitement



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 time 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

bsen

ce o

f a

featu

re)

Lik

eN

eu

tral

Dis

like

Q#1 (Presence of a feature)

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



Formal

BV

High

Complexity

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



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



Estimation

Relative

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

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?



Definition of “Done”

design+code+unit test functional

test

architecture load test

code reviewdesign review

regression test



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?



Rules of thumb

• Tasks should be 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



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 sprint

Definition

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.

You don’t get credit for partial 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

Retrospective

Sprint Review

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

Team meets at the end of each sprint to discuss-1) What is working well? 2) What needs improvement? and 3) How to improve/fix the process?

tracking impediment

s



Burndowns

• Time spent

• Time remaining

Track Remaining

hours

Track done

Daily time entry



Other charts Tracking

actual time spent

Tracking release



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

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

Agile Planning, Estimation, and Tracking Syed Rayhan Co-founder, Code71, Inc. Contact: [email protected] Blog: Company: .

Documents

tracking planning section

sprint planning

agilescrum slide

planning waterfallagile

excitement slide

qa section

waterfall project planning

sprint ideal slide