How can we estimate an end date for a project using our whiteboard system?

Question

We are a dev team of 8 without an official PM. Up to now we have organized our workload by always having around 20-40 upcoming tasks pinned to a whiteboard. Basically, it's a table with people's names as headers and their tasks in their columns.

This is helpful, as it's clear what everyone is working on and will be working on soon. However, one problem we face is knowing when a series of tasks are going to be finished.

Planning everything in Excel seems fairly inflexible. As soon as one task shifts, it seems like a lot of rework.

Is there a method that combines the simple whiteboard planning approach and its flexibility with a method to predict release dates and ideally supports a good method of dealing with changing estimates for the individual tasks?

Answer 1

Estimate Delivery Milestones from Throughput

You have half a solution already. While your scheduling process isn't particularly agile, you can extend what you're already doing by calculating cycle times and using that to estimate your release schedule.

At the risk of oversimplifying, you an get a reasonable estimate of your release date by doing the following:

1. Track the average time it takes the team to complete each unit of work. (NB: This basic data can also be used to calculate lead time, cycle time, takt time, and other related metrics.)
2. Count up all the work needed to reach a milestone or release.
3. Multiply the total work units needed to achieve your objective by the average time needed to complete units. In other words, cycle_time * backlog_items = lead_time for each milestone.
4. Apply fudge factors for external dependencies, if any.
5. Use the result as a forecast against which you will track progress, not as an iron-clad guarantee.

This is the informal basis of most Kanban and Lean metrics. It's a relatively lightweight system to layer on top of the scheduling process you already have, and generally yields "good enough" results without a lot of process overhead spent chasing false precision.