Upload
kirk-pressman
View
217
Download
0
Tags:
Embed Size (px)
Citation preview
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
3www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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
4www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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
5www.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
6www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
Waterfall Project Planning
“.”
Project can be accurately planned in details
7www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
In reality, software projects are like…
forecasting weather- rain or
shine?
8www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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
9www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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
10www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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?
11www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
Minimum Viable Product (MVP)
Release#1 R#2 R#3
Expanding scope of MVP Release every sprintideal
12www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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?
13www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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
14www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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?
15www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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
16www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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
17www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
Sprint 0
• Project initiation sprint
• Business case
• Environment setup
• Architecture
• Team setup
• Team norms
• Training
18www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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
19www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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
20www.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
21www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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
22www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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?
23www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
Definition of “Done”
design+code+unit test functional
test
architecture load test
code reviewdesign review
regression test
24www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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?
25www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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
26www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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
27www.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
28www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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
29www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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
30www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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
31www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
Burndowns
• Time spent
• Time remaining
Track Remaining
hours
Track done
Daily time entry
32www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
Other charts Tracking
actual time spent
Tracking release
33www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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?
34www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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
35www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
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
36www.Code71.com www.ScrumPad.com
Copyright 2009 Code71, Inc.
Q&A
Contact: [email protected]: http://blog.syedrayhan.comCompany: http://www.code71.comProduct: http://www.scrumpad.com