Dec 16
Forgive me Scrum Puzzlers for taking so long to post a new puzzle. I’ve been busy with a side project which will very soon become a lot more than a side project. In exactly 2 weeks I will be self employed! I have started Growing Agile with my good friend and fellow agile enthusiast Sam Laing. We are looking forward to a whole new adventure next year, which I imagine will inspire quite a few Scrum puzzles. Anyway onto my solution to puzzle #4:
Most people seemed to get the concept that the team own the task board in the responses to Scrum Puzzle #3 but a few wanted to be helpful to management by allowing for some consistency or a key to make the board more understandable.
My approach is a much less forgiving. I think that the task board is only there for the team, and does not need to communicate anything to management or anyone else. There are other mechanisms in Scrum for management to know how the team is progressing and how they can help. The problem with giving in to this request, is that it opens the door for abuse, even from the most well intentioned managers.
Well looks like everyone got that changing the sprint length is a bad idea. Here are the key learning points for me in Scrum Puzzle #2:
1. Velocity is not linear, all it tells you is how many points a team usually complete in a fix period. As soon as you change that period you no longer have data to make any prediction. You cannot assume that if a team do 30 points in 2 weeks, that they can do 15 points in 1 week. The team may for example do all the coding in the first week and all the testing in the second. So after one week they would deliver 0 because nothing is tested. I’m not saying this is how all teams work, or even how teams should work, all I’m saying is that knowing only the velocity for a 2 week sprint you cannot know anything about where the team will be after 1 week.
Wow, I’m overwhelmed by the great response to the first Scrum Puzzle. I loved some of your responses. I especially liked Matthew’s example of moving the boulders. That’s a great way to teach the principle.
Here is my solution:
There are 2 key learning points in this puzzle. Number one is the value of small batch sizes. There are numerous exercises to demonstrate this. Check out the penny game as an example. Most of you got that the stories really need to be broken down smaller. This is often difficult for new teams, but there are techniques you can use to do this. See my previous post on breaking down user stories. If we don’t have small batch sizes, then it takes longer to complete work, progress is less transparent, feedback cycles are longer. All of these are things we are trying to avoid in Scrum, so any solution which makes the batch size larger is generally not a good idea.
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:
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:
Theme: Linen by The Theme Foundry
