I’m thinking about the planning and estimation process deeply, because it’s taken up a lot of my time on fixed-price projects.
I think my biggest problem at the moment is trying to square the circle of the 4 purposes for the planning and estimation we are currently doing, in order of detail : scoping, horizon planning, just-in-time planning and change control.
Scoping and change control are the most important to the project board, horizon planning is most important for setting deadlines for deliverables to and within the project team, and JIT planning allows us to define work at an individual level over a sprint.
Scoping has and, I believe, will continue to be a horse trading exercise, allowing us to talk in broad terms about including and dropping functionality, based on workload, risk and timescales.
These scopes are defined mainly from the initial bid and budget and have undergone minor changes.
The horizon planning is the key deliverable from last week’s planning meeting and today’s requirements discussions : making sure we set deadlines for delivery of documentation and components to an agreed timescale.
JIT planning is the bit the whole team should be involved in. It’s how we break down the tasks and decide what and how much we do in the next sprint, at a level of granularity that minimises crossover of tasks between developers, and therefore maximises parallel execution.
Change control requires estimation at a lower level of detail so that we can identify any difference in expected effort between our current plan and the results of any workshop. This must be done before the use cases, but to a similar level of detail, and we will need to add a step during the production or review of those use cases to highlight variations, so that we can suspend delivery of those use cases until the change has been managed.
I understand why, for political reasons with certain customers, the change control detail is necessary, but I prefer to ensure the wider team remain focused on the horizon and JIT planning, to shield them from the politics that may cause disruption within the team.
Lots of good quotes in this collection of articles : InfoQ – Agile Planning and Estimation http://www.infoq.com/resource/minibooks/emag-agile-estimation/en/pdf/Agile-Project-Estimation-and-Planning-eMag.pdf
Why Is Scrum So Hard?: http://youtu.be/q3t8twm3aUk