Here are notes I took during a recent Agile training program at work. Not sure if any of this will be of any value or use to anyone, but here are they none-the-less.
Problem and Our Goal
Plans go wrong because tasks finish late more often than early, because they are not independent of each other (if one task takes longer, it effects all other dependent tasks)
Padding a project estimate with local buffer (typically at the end as just in case time) – but procrastinate by wasting local buffer in the beginning of project start. (because of over confidence) Realty of work takes longer and entire project is late.
Lateness is passed down (task can be late because any previously dependent tasks are late). Only way it can be done early is if ALL tasks previously completed early.
Planning Onion:
Daily plan
*Iteration (sprint planning – look ahead a few weeks)
*Release (3-6 month look ahead consists of multiple iterations/sprints)
Product (road mapping – product evolution over time, backlog contains user stories)
—-
Portfolio (what is expected of the company – whats missing overall)
Strategy (company strategy)
A good plan leads to reliable decision making!
Planning should enable us to make the right decision!
“Its better to be roughly right than precisely wrong!”
KNOW: Accurate vs Precise!
(Birthday in September is Accurate. Sept 27 is Precise!)
Precise is not always accurate.
Always be accurate, try to be precise.
“Do the planning, throw away the plan” (benefit is in the activity of planning, not the actual plan – i.e. plan is too concrete, needs to be flexible and able to change/evolve)
Agile planning:
More focused on planning than plan
encourages change with plans
spread planning through the project
Iteration Planning
Creates a list of tasks based on user stories from Product Backlog. Product owner prioritizes user stories, team determines sequence of tasks to complete.
Looking ahead another iteration is ok to determine synergy for completing random tasks from future iterations. Dependencies, etc.
Working slightly out of order can improve throughput!
Product Owner -> ScrumMaster/Coach -> Team:
Product backlog
Team capabilities
Velocity
==> Iteration goal (point of this sprint) & iteration backlog (actual list of tasks to be completed this iteration including estimates per task)
Planning meeting:
Determine teams capacity
Refine the iteration goal
Define commitment
Acquire confidence
Velocity: (all at once approach)
The amount of work a team has or will complete in an iteration.
(sum of estimated hours per task – predicted Velocity)
(after a sprint, add the hours for historical Velocity)
Historical velocity is used to determine capacity for future sprints (Yesterdays Weather)
Or historical average velocity per sprint.
Defining the commitment is building a collection of tasks who’s estimate total the determined velocity.
Commitment-Driven Planning (alternative to Velocity)
Taking each backlog item, estimate it, commit to it, and move on until the commitment has been filled.
How full should an iteration be?
(account for Corporate overhead – plannable time, and unplanned time – fires, random tasks, etc.)
Build up commitment 1 user story at a time until reached a full iteration.
With each user story you must ask – “Can we commit?”
Which is better?
Velocity is useful only over the long term!
Velocity is not idea to plan single sprints.
Story Points & Ideal Days
Estimating by analogy (compare task to something you know you’ve already completed)
Estimate size; derive duration
Ideal time:
How long something will take if:
its all you work on
no one interrupts you
everything you need is available
versus elapsed time (all of the time accounting ideal time and corporate overhead, sleep, non-work time, etc)
**Advantages:
Easier to start with
Easier to explain to others
More palatable to management (time is a normal concept)
Forces confrontation of time wasters
Story points:
(an alternative to ideal time) to measure product backlog items.
Estimates effort over time (how much effort or bigness is the size estimate for this user story).
Relative size is what matters (easy tasks are worth fewer points than complex tasks which are worth more).
Story point values are estimated relative to other related and similar tasks.
Use ranges on estimating story point values for vague items.
Re-baseline – adjust the scale of the metrics determined for the story points (typically after 5-12 items have been estimated).
**Advantages:
Prevent incorrect conversion to calendar days
Promotes cross functional behavior
Points dont decay
Points are a pure measure of size
Time estimates are not additive (your time is not the same as my time)
(but point values are the same for everyone involved)
Points prevent unit confusion
velocity is always the sum of units on the product backlog (NOT the iteration backlog)!
Story points ARE an estimate of time (amount of work)
Estimating Product Backlog:
Triangulate by comparing new story to two existing stories.
Disaggregate – break a user story into smaller stories
*Dont take this too far!
(Golfer can easily estimate score for 18 holes of golf, but if they guessed per hole the total would be completely wrong)
The Right Units — its not necessary to use every number with Story points. The difference between 1 and 2 is 50% but the difference between 17 and 18 is 5% etc. => 1,2,3,5,13, 20, 40, 100 etc.
Planning Poker:
Each estimator gets a set of cards with the point values
Product owner reads a user story and its discussed briefly
Each estimator plays the card (hidden from play)
Everyone reveals at the same time – if they all match thats the number.
Differences are discussed and reveal rounds repeated
*Should involve the entire team – Product Owner, ScrumMaster/Coach, Team.
**During planning poker, the team is determining the values directly for estimates.
Anchoring – the tendency for estimates to cluster around an irrelevant value.
(i.e. when a $500 item is on sale for 80% off – you are tricked into thinking its a great deal! – the $500 is the Anchor)
Planning Poker avoids anchoring by having everyone reveal cards at the same time (versus in order).
Release Planning:
Confidence interval = the low-high range of the average sorted velocities (after you remove outliers and 8 worst and 8 best).
Forecasting Velocity (when no historical data is available):
Plan an iteration using Commitment-Driven Planning
Sum the Story points from the Product backlog after the iteration has been determined
+/- 15% to determine Velocity Range
Fixed Date Plans:
Determine how many iterations there will be by due date
Estimate teams predicted velocity range
Use the velocity range * iterations to partition backlog into: will have, might have, won’t have
“By the end of June, team can deliver 150-180 story points”
Balancing Risk:
Delivery risk (low vs high) / Expectation Risk (low vs high)
Fixed Scope Plans:
Sum the product backlog
Estimate velocity
Determine length of project (project size / velocity = # of iterations)
“Based on the size of the backlog, the project will take 6-8 iterations to complete.”
Fixed Price = (both fixed date and scope)
Determine project as both fixed date and fixed scope – overlap the ranges for both scenarios and determine if the hard target falls within that range to determine risk.
- Estimate velocity
- Fix the scope
- divide fixed scope by velocity range
- Fix the schedule
- determine number of iterations