As mentioned in my last blog, it's essential to get the whole team on the same page when estimating development tasks. Some agile teams prefer to estimate in elapsed time (typically Scrum teams do this), other agile teams estimate in ideal days (typically XP teams do this) and yet another alternative is to use relative complexity points.
Mike Cohn's latest book Agile Estimating and Planning (which I heartily recommend) does a great job of explaining the pros and cons of these different approaches. I love the real-world examples Mike uses to get his points across (shifting dirt with a wheelbarrow, eating cookies, getting to the airport, etc).
When explaining estimating in ideal time, the example I use is route planning software. We understand that this gives us a journey duration which assumes perfect cruising speed with no stops. The journey times generated are simply a guide to the best achievable time when traveling within the speed limits and we adjust our departure time accordingly, probably setting off a little earlier allowing a buffer for delays and stops. Our estimate of the buffer for our journey is only a best guess, we have to accept that we may arrive early if the roads are clear or late if we hit severe delays.
The XP Game is a excellent tool to use teach teams about agile estimating. Although this is now rather at odds with the latest edition of XP Explained in which Kent Beck recommends that teams estimate in real time.
Chartering workshops can be a good way to help the whole project team get clear on their approach to estimation. For example, a team I worked with recently agreed the following operational guides on Story Estimation and Story Completeness:
The development team will estimate stories in Ideal Days, defined as "uninterrupted elapsed time that excludes meetings/sickness/days-off and does not include buffering". It is understood by the whole team that ideal days are not equivalent to man-days.
For a story to be considered to be “Done” (complete and therefore counted in team velocity) it should be checked by UI designer, customer team and QA within iteration. However, it is agreed that usability testing with end-users will be completed outside iteration boundary. Estimates for stories include time for QA testing to be completed within the iteration.
Working Agreements are made by the team to fit their circumstances and can be changed during the project if they don't work out. The important aspect of these agreements is that the assumptions made about how agile practices will be implemented have been discussed and that people are not working with different mental models of what is and is not the team's approach.
I just finished reading Collaboration Explained by Jean Tabaka. In this neat book, Jean has created some useful guides to assist you in facilitating meetings held by agile software development teams. She also includes a section on Guerilla Facilitation, techniques that you can use as a meeting participant rather than "official" facilitator when the meeting hits problems.
Sadly, I am all too familiar with guerilla facilitation! I have attended many meetings as a developer where I can't stop myself from saying: "Can someone please remind me of the reason we are having this meeting?", "Perhaps we have talked about this long enough now?", "Do people need a break?", etc. In my experience, a key item to check when you join an agile planning session is what units people are using (ideal time, complexity, elapsed time) in their estimates and any assumptions in their estimates (is testing included or not), this helps resolve many heated disputes. Another useful tip, where team members don't understand a point that someone in the meeting is making, is to ask that person to give a concrete example.
There's an interesting book by Jim and Michele McCarthy called Software for Your Head which introduces a protocol for checking in and out of meetings. Checking Out basically means that when the meeting is not fulfilling any useful purpose for you then you physically leave the meeting. This is preferable to mentally checking out of the meeting - turning your mind to other topics but remaining in the room - because it becomes immediately clear to the remaining participants that the meeting flow has become stuck in an eddy. To get up and leave an unproductive team situation has also been called "The Flounce" by Michael Feathers (when describing one of Hill's coaching moves at Workshare). I am not sure I would be brave enough to do this, although I've been tempted once or twice!