Scrum - prepare your meetings
Posted: | More posts about Scrum
"But Scrum involves so many meetings - we already have meetings like all day and don't get to coding anything." - "However we do need transparency and communication to build great software." - "Actually scheduling and re-prioritising items during scrum planning takes so much time." Does that sound familiar to you?
What if you could fit Sprint Review and Planning I for a team of three people doing three week sprints into one hour? Impossible? Well, not quite so. As always there is a very easy trick: Be prepared.
Before the review re-visit all items you have accomplished. Get the application into a state that makes it easy to demonstrate all new features to your product owner. If you are a team working on internal projects with many internal clients - get one of them to test our the new features early on (as in way before review) and get their input onto the table.
Get a list of all items up on a whiteboard. Then with the PO work you way through these items, either demonstrating them or referring to what the "real client" said about the feature. After that compute the velocity of your past sprint.
Then go over to the list of still to be done items. (You did estimate them in separate estimation meetings already, didn't you? You also got the prioritised by your PO beforehand, didn't you?) According to the computed velocity simply check out what you can do in the upcoming sprint.
After that team and PO are done. Guess what: Working with pen, whiteboard and paper did speed up our process considerably. After all, these are meetings of at least four people: Don't want to waste working hours of four people by not using the fastest and most flexible planning method.
So - who's responsible for getting all this information up? And - if using a digital planning tool, who is supposed to get it back into the tool? Trivial: It's the scrum master's job to provide all help and tools to the team to make it a high performing team. It's way better to spend 2 extra hours preparing and "tidying up" the sprint planning than have four people spend 2 hours (total 6 vs. 8 hours) in a sub-optimal meeting.
Together with estimation meetings for me this means that each sprint one to two days go into organisational work. Still this is very low overhead compared to what the team is able to accomplish in that time.