Scrum - prepare your meetings #
“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.