If your team is not focused on delivering intermediate project milestones, they are missing what’s really of value. It’s easy to miss the forest for the trees if you’re only focusing on task-level points estimates and velocity tracking.
I’ve become frustrated with how burn charts focus on showing progress through an entire backlog and don’t clearly show the importance of incrementally delivering chunks of value.
Burn Charts Are Not Enough
Atomic has been experimenting with several approaches to help us focus, report against, and manage scope against intermediate milestones.
Staging Backlogs
We’ve been staging our backlogs with near-term tasks and future epics stretched out across many iterations. We call out milestone deliveries as pseudo tasks in the iteration when the milestone should be complete. The team has flexibility and doesn’t feel pressured to call something complete at an iteration boundary because milestone tasks span multiple iterations that include calendar buffeing for risk and iteration.
Gantt Charts
We’ve been using range estimates and ballpark SWAGs to establish Gantt charts that call out milestone delivery dates. We keep the Gantt charts big and visible in the team space. We report on variation every 2-3 weeks or as neccessary using a simple spreadsheet.
Milestone Progress Tracking and Prediction
We’ve been associating every task in our backlog with a milestone, and we track our time down to 15 minute increments against milestone buckets. In addition a burn chart, we’ve been creating a milestone progress chart that shows each milestone’s base hours estimate, buffer hours estimate, actual hours spent, and predicted hours remaining.
The milestone progress and prediction chart allows teams to see how they are progressing through a major chunk of work, how much buffer they might use, and if they need manage expectations on scope or delivery date.
Reporting progress at the milestone level is more compatible with clients’ expectations on progress reports. It’s rare that our clients have to manage scope or priorities at a task level or worry about slight velocity changes after any given week.
Getting Rid of Iterations and Story Points?
I’m very intrigued with Eric Huddleston’s thoughts about the downsides of iterations and Joshua Kerievsky’s recommendation to stop using story points.
Keeping a Weekly Cadence
I agree with Eric on many of his points regarding the downsides of rigid iteration-based planning and delivery. I believe that Atomic’s buffered milestone approach removes many the downsides and maintains the upsides of finer-grained (weekly) cadence and synchronization. Tracking implementation performance and updating stakeholders only takes about one hour each week. Milestone delivery cadence varies by milestone size, and the synchronization process takes longer as we may spend time further defining scope for the upcoming milestone.
Leaving Story Points Behind
I’m extremely tempted to try Joshua’s recommendation and run an upcoming project without using story points. Joshua’s explanation of periodic release planning matches very closely to Atomic’s range estimate approach in terms of method and granularity as well as our application of evolutionary design. If we abandoned story points I’d still like to organize tasks into weeks of work, keep tasks at a gut-level feel of similar granularity, and track what we are getting done each week. Joshua points out that Don Wells described such a method in 2001 in the Extreme Programming group:
We have been counting items done. Each week we just
choose the most important items and sign up for them up to the number from
last week. It turns out that we get about the same number of them done
regardless of estimated effort. We have 1 week iterations, so we tend to
break things down a bit at the iteration planning meeting.Perhaps the effect is that we have learned how to break things down to the
right size. I don’t know yet, but the point is we get about 8 things done
each week, no estimation required. The only problem with this simplification
is relating our pace back to the big picture.
I think Don’s simpler method could be used in conjunction with big picture tracking by:
- Decomposing milestones into items left to do.
- Tracking average hours spent per item done.
- Predicting hours left remaining for each milestone based number of items left and average hours per item.
- Accounting for partially decomposed or whole milestones as chunks of team time remaning.
I suspect Atomic’s current approach using milestone progress tracking and prediction would be adaptable to the point-free approach.
How are you experimenting with agile project management? What pain points are you feeling from your current approach?