Keeping iteration/sprint planning meetings short
Iteration planning meetings can be a real drag. I have been in meetings that have dragged on all day: with estimating in particular seeming to last an eternity. It is particularly painful when this is all happening on a conference call with a globally distributed team (more on that in another post maybe). This is what the process was like at Huddle when I first introduced agile. We would have Iteration Retrospective, Iteration Demo and Iteration Planning all pretty much back to back. Iteration Planning would start with estimating all the highest priority stories, and adding them to the iteration until the iteration was full. On a bad day all if this could take the best part of a day, and was the part of the iteration that everyone dreaded - not to mention the amount of time it took up.
Over the last year we have refined this process. Firstly the retrospective now happens at the end of the day before. We start iterations on a Tuesday, so the restrospective is 5pm on the Monday, with the demo first thing on the Tuesday morning. Secondly, and most importantly, we have taken estimating out of planning. We set aside a 30 minutes time-boxed slot every day, and if there are unestimated stories on the backlog we use this time to estimate them in priority order until they are all done or we have used up our 30 minutes. This means that the core iteration planning meeting can be done in well under an hour. We have two teams taking working from a common backlog, and everyone attends the planning meeting. Each team says what they think their capacity is for the iteration (looking at previous velocity, and planned absence etc.); we then go through each story on the backlog in priority order, with teams volunteering to take them on, until neither team has capacity to take on any more. At least one person in each team has seen the story before, so there is no need to discuss the details at this point; this means that it really does take 30-45 minutes, including a bit of time to rebalance stories between teams to make sure the teams are not dependent on each other, and there is a suitable UI/back-end development balance in each team.
Once the meeting is done, each team will elaborate the stories they are assigned, breaking them down in to tasks, and planning the work within the iteration. But this is something that each team does by themselves at their own pace after the main planning meeting, rather than a big formal meeting with the whole development team present.
It’s just worth a quick note on attendees for the daily estimating session. Obviously it’s a big drain on time to take everyone out for half an hour a day, so we have a rota. We have to balance total time taken up with continuity, so our Systems Architect is in every session, along with a rotation of two back-end developers, one UI developer, and a QA analyst. We have learnt that it is worth noting who was in the estimating session on the story card; there have been been a few cases where the team working on it have said “who the hell estimated this”, and it’s been handy to be able to answer that question!
Finally, bringing forward the estimating process means that the estimates can inform our Product Manager’s prioritisation more easily. Obvious we need to balance this against spending too much time estimating things that we don’t plan to do for a very long time - in the spirit of Lean, there is a lot to be said for, “just-in-time” estimating, and we do our best to strike a sensible balance.