AgileAndProjectPlanning
What's Planning For?
To answer the questions: what should we build, and in what order?
A project that delivers all features on the initial plan is not necessarily a success!
A good planning process should:
- Reduce risk
- Reduce uncertainty
- Support better decision making
- Establish trust
- Convey information about the intended implementation route
What's The Problem?
Agile methods are highly adaptive and as a result do not fit well with the common organisational practice of long-term Gantt charts stretching over a course of years.
From the Agile practitioner's point of view, the demands of planners often ask for information that is simply unknown - and so supplying it is actually more likely to be counter-productive than anything else.
From the planner's point of view, the Agile practitioners refuse to provide projections that are necessary for budgeting processes.
The Problem With Traditional Planning
Consider that:
- nearly two-thirds of projects significantly overrun their cost estimates
- 64% of features included in projects are rarely or never used
- The average project exceeds its schedule by 100%
Problems with traditional planning:
- ACTIVITY based not FEATURE based
- Focus on the completion of activities rather than the higher-level goal of feature delivery
- Reviewing activity based schedules will spot missing activities but not missing features
- Activity based scheduling causes schedule problems:
- Activities don't finish early (Parkinson's Law)
- Activity chains then mean the delays are passed onwards down the schedule
- Delays in one activity imply delays in future similar activities - but this is often not reflected in plan updates
- Multitasking
- Likely when work is apportioned in advance
- Likely when insufficient slack in plan
- Features Not Developed by Priority
- Time pressure then leads to features dropped at random
- Poor levels of realised value
- Ignores Uncertainty
- Estimation requires cones of uncertainty around projects
- Iterative approaches can then shrink the cone size
- Estimates Become Commitments
- The structure of traditional planning fosters unfounded implicit assumptions of commitment
Agile Plans
Agile Planning:
- Is focused on gaining value from the process of planning itself, not just the end result
- Encourages change (does not mean dates change, but if not then scope will)
- Results in plans that are easily changed
- Is spread throughout the project
Planning is a process of setting and revising goals that lead to a longer-term objective.
Agile planning is concerned with the 3 innermost parts of this list:
- Strategy
- Portfolio
- Product
- Release (months?)
- Iteration (weeks?)
- Today
Agile Estimation
Functionality is defined in User Stories.
You pick a scale (Story Points, Ideal Days) and give each User Story an estimate.
You then measure Velocity per iteration as a way of establishing how many story points you can get through.
(When starting out Velocity will need to be estimated)
Estimation Scales:
- Story points are relative: say in a range 1-10.
- Ideal Days are another scale of estimation that can be used. Best done in aggregate rather than trying to split down between all actors. Note that Ideal Days need to be scaled to actual days via Velocity, just as much as Story Points do.
Story Points are more abstract, a purer measure of relative size. Cohn recommends them over Ideal Days, even if Story Points are easier to get started with.
Best to use a relatively tight, coherent scale without too much nuance. Eg 1,2,3,5,8.
- Stops people wasting time on a futile quest for perfect estimates
- Can also add "epics" (large stories) or "themes" (collections of stories) with larger scale, Eg 13,20,40,100
Estimates should be made collectively, not individually!
- Planning poker: each selects cards, turn over at once, discuss, re-iterate until converged
- Most useful at inception, need to thrash out how to deal with new stuff as it comes in
Re-Estimation:
- When relative size has changed
- Eg when post-iteration retrospective indicates wrong story point/ideal day count
- Go over related tasks and re-evaluate
- One _can_ re-estimate remainder of partially completed stories - but best to keep stories small so this isn't an issue
Prioritising
Aggregate User Stories into Themes and prioritise those:
- Value
- Cost of development
- Benefit of learning/knowledge from developing
- Risk removed by developing
- Chance to gain feedback from users
In risk/value terms, order work thus:
- High Risk, High Value first - since risk elimination has value in itself
- Low Risk, High Value next
- Low Risk, Low Value last
- High Risk, Low Value avoid!
Splitting and Combining User Stories
Each story much be a complete feature: eg don't split into coding UI + writing middle tier + ...
Don't add work onto stories if not of clearly equivalent priority
Can be useful combining multiple tiny stories
Scheduling
Compare and Contrast
| What | Release Plans | Iteration Plans |
|---|---|---|
| Horizon | 3-9 months | 1-4 weeks |
| Items in plan | User Stories | Tasks |
| Estimated in | Story Points or Ideal Days | Hours |
Release Plans
Work to releases to get stable aggregate functionality release points
Either date-driven or feature-driven is OK - but know which of the two you are!
Get an iteration chart up - Magic Whiteboard?
Iteration Plans
Will get more detailed design discussions here
Need a theme/goals to aid story selection
More detailed dive into each story, don't allocate to people at this point.
Estimate in hours as we are talking concrete implementation work at this point.
Task Estimation should be a group endeavour, not "who's doing the work"
- we don't even know that yet anyway
- others will have something to contribute
- avoids ego problems in admitting mistakes
- checks collective understanding of task
Try and use cards on a wall, not someone typing things in (as they become an information block/pinch-point)
Include meetings in task list
Complex tasks may require a "spike" first to enable final estimation of overall task
In terms of task size, try to aim for an average of one task per day
Perhaps best to ask for commitment as each new user story's total task hour count is added to the total, rather than committing based on velocity.
- 50-75% of people's actual time at work is a sensible upper limit
- Velocity OK for release planning but better to use more definite hour info for iteration level
Iteration Review Meetings
Held after each is finished. May get good new ideas that go to high priority.
Discuss priorities for next iteration.
Cycle Lengths
Ideally we'd have at least 4-5 iterations per release.
Do not try and change priorities inside an iteration (another good reason to keep them short!)
Keep iterations short, maybe every 2 weeks: with 1 week you're always having a deadline breathing down your beck and with 4 weeks things are a bit slack in the middle.
One idea: 6x2 + 1 where the "1" is dev catchup: refactoring, test automation, experiment with something new, some work on upcoming large features
Velocity Estimation
Can (in order or preference):
- Run an iteration (eg just don't estimate for first iteration)
- Use historic (need to be sure you're comparing like with like)
- Forecast (eg breakdown to tasks and hours and run with that). Ensure you have something like a 60% to 160% cone of variation around this
Buffering
Two forms:
- Feature buffers: identify core mandatory set of features, then rest (another 25% to 40%) is additional to that
- Schedule buffer: should be a single project-level buffer
- Variance-based: take 50%, 90% estimates: buffer is sqrt( sum( square( 90% est - 50% est ) ) ).
- Simple: take half sum of 50% estimates
- In any case should be at least 20% of project duration
You can combine the two.
You need clear communication around buffers or people will be suspicious of estimate padding etc. A buffer does not represent padding but an attempt to restore error bars around estimates that have been stripped of them.
Multiple Teams
See Ch 18 of Cohn for ideas
Try to co-ordinate on a per-iteration basis still, reorganising if necessary to maintain this level of simplicity- eg try to avoid having to buffer work *during* iterations from one team to another.
Do a rolling lookahead plan for 2-3 iterations in advance to allow information sharing.
You will need more detail on user-stories with cross-team impact.
Progress Monitoring
Releases:
- Burndown charts (which can include scope as a bottom-of-bar indicator)
- Parking-lot chart (a snapshot, reporting by theme)
Iterations:
- Task board with stages
- Iteration burndown (does need at least 2-week-long iterations!)
- DO NOT TRACK INDIVIDUAL VELOCITY
Gantt charts:
- Feature-based, iteration-based: NOT task based
- Each feature is full iteration length
- Don't show individual allocation
General:
- Communicate in ranges (eg not current mean velocity for releases, look at range over project)
- Write an end-of-iteration summary: maybe 30 minutes for a 2-week iteration
- See Cohn for an example
Advantages Of Agile Planning
- Replanning occurs frequently
- Estimating size + duration is separated
- Can tune plan precision to level: release / iteration / daily
- Feature-based, not task-based
- Small stories improve flow
- No hangovers of work in progress
- Team-level tracking
- Uncertainty acknowledged and planned for
Agile Guidelines For Estimating And Planning
- Involve the whole team
- Plan at different levels
- Keep estimates of size and duration separate by using different units
- Express uncertainty in functionality or date
- Replan often (by iteration)
- Track and communicate progress
- Acknowledge the importance of learning
- Plan features of the right size
- Prioritize features
- Base estimates and plans on facts rather than projections
- Leave some slack
- Coordinate teams through lookahead planning