Scrum Puzzle #1
It seems it has been a very long time since I did a blog post. I have good reasons. Since my last blog post I have:
- Attended my first Agile Alliance Conference: Agile 2011
- Presented 2 talks at Agile 2011
- Had my first official paper published as part of the Agile 2011 conference proceedings
- Helped Organise the second South African Scrum Gathering in Cape Town and Johannesburg
- Co-trained CSM/CSPO courses in 3 continents
- Submitted my CST application (waiting anxiously for feedback…)
In the last 3 months I have learned a lot of new stuff about Scrum and Agile. I have also been faced with the reality that many people in South Africa have not had the opportunities I have had to be exposed to all these ideas and thinking. I see a lot of people doing Scrum (or at least trying) and not understanding the reasons they do the things they do. This brings me to my latest idea: Scrum Puzzles. One of the best ways to learn is to apply your knowledge to concrete examples. I will create some scenarios which I commonly see in teams and post them. I’ll let you mull over them for a week. You can post your solutions and reasoning in the comments. After a week I will post my solution focusing mostly on the why. I don’t claim to be the expert or that my solution will be the only one, but I do want to expose the reasoning behind why that would be the approach I select. Not sure how many puzzles I can come up with, and how long I’ll continue this for, but if you like the idea, leave a comment so I am encouraged to continue 🙂
And so, Scrum Puzzle Number 1:
In a retrospective a Scrum Team identify that they failed to deliver their only story in the sprint which was a 40 point story. They acknowledge that although they completed nothing in the sprint, the entire team was not busy because only 2 developers could work on that particular story at a time. Their recommendation for future sprints is that they should plan for 40 point stories to take 2 sprints, and therefore take more stories into the sprint, which would allow the other developers to have something to work on, and would mean that they won’t deliver nothing again in the next sprint.
Over to the audience…. As this team’s ScrumMaster what would you do?