Scrum Pain
In the previous post I went through what I liked about scrum. I have found parts of scrum painful though …
Planning
Sprint planning is usually a 2 hour meeting at the start of each sprint to decide what work needs to be done and who is going to do it. The whole team is included in this meeting, so, if the team contains 7 people then that can equate to nearly 2 days of total time. The thing I struggle with is do we get 2 days worth of value from that meeting? If we have a well ordered backlog, why should it cost 2 days to work out what needs to be done and who should do it?
A sprint rarely goes to plan anyway. Estimates are always a little out, resulting more often than not in work rolling work over to the next sprint. Unexpected unplanned urgent work also comes in to the sprint. Of course you can have a buffer in the plan for underestimation and unexpected work, but that isn’t ideal.
I really do struggle to justify the investment of sprint planning.
Daily stand up
Everyone already has a good idea what everyone is doing - that’s what the sprint planning session was for and that’s what products like JIRA are for. As a developer, if I’m blocked by something that someone else on the team is responsible for, then I will communicate with them there and then - I won’t wait for the daily stand up.
For a team of 7 spending 15-20 mins in this meeting every day equates to roughly 2 hours per day which is well over 2 days in the whole sprint. Again I struggle to justify this investment and another meeting that interrupts developer flow.
Story pointing
People inside the dev team have difficulty understanding what a story point is - they naturally want to equate it to time. People outside the dev team have difficulty understanding what a story point is - they want to equate it to time! So why not just estimate in time?