Lightweight Planning
It was not appropriate to deploy to the ‘real’ customer every iteration for a few reasons, so we bundled new functionality into several releases, each being 2 – 3 months long.
We would have release planning meeting at the beginning of every release, and normally also halfway through to keep track of how we were doing. Such meetings were typically between 1 and 2 hours long. The process would be:
– One of the BA’s would read out the ‘release level’ stories one by one
– For each story each developer would write down an estimate in rough ‘ideal days’
– Once all the stories were read out each developer would sum their estimates
– We would then go around the room and all the totals would be written on a whiteboard.
– From this, we would see a basic idea of how much work the team thought there was
This process was not at all in depth, but it was only meant to give a ‘finger in the air’ estimation. Keeping the meetings short also kept the developers from falling asleep. 🙂
Before each iteration planning meeting (IPM), the project manager, the 2 BA’s and 2 of the developers would have a quick look through the upcoming stories to pick candidates to discuss at the IPM. This decision was not final – it was just an optimisation so that we’d have a first cut of stories to discuss in the IPM proper.
The IPM itself would normally be about an hour long. The sequence of activities would normally be:
– The Iteration Manager (one of the developers) would describe the results of the last iteration in terms of completed stories, total ‘ideal days’ completed, and stories remaining (‘hangover’).
– The team would estimate the remaining ideal days for each of the hangover stories.
– The Iteration Manager would give a rough amount of how many ideal days were left for new stories, based on velocity and how many pairs we had for the next iteration.
– One of the BAs would then describe a story. At this point a combination of 3 things would happen:
+ A discussion would spark up
+ The team would split the story (e.g. because of size)
+ The developers would estimate the story
– Once the story was estimated, another story would be played and the process repeated
– This story description / estimation process would continue until we were pretty happy we had the right amount of work for the iteration based on how many ideal days we thought we needed from the beginning of the meeting.
This process is very similar to what Martin Fowler describes here. Its not particularly precise, but we found it was good enough for our project to work, and at the same time meant that we weren’t bogged down by process.
Related to our planning processes were our tracking processes. These were also kept simple, and were based solely on completed stories (i.e. completed and remaining stories per iteration).
Lesson number 3 is then:
Keep your planning processes lightweight, and adapt them to suit the team and the project
Mike Roberts