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?
Coaching teams to do better scrum 
I love the idea of scrum puzzles – perhaps people can also leave comments with puzzles of their own? I will mull this over and leave my comment next week 🙂
I like the idea Karen! I’ll definitely be back.
-Mark
The focus always needs to be on delivering functionality at the end of the sprint. If i were the SM I would:
1. Determine the teams velocity (in this case most likely 40 points).
2. Break each story down into 1,2 or 3 point sized stories in order to have more granular approach to the whole sprint.
3. Determine which of those smaller stories only a limited number of developers could complete and negotiate with the PO to re-order those to the top of the sprint backlog so that the impediments could be removed as soon as possible. Conceptually I would just about treat the developers delivering this functionality as a separate team although practically they’re not.
4. Determine the highest ordered story that can be done by developers in parallel and allow the remainder of the developers to start on those stories until the impediment stories are completed upon which time the team can revert to “usual” team behavior.
5. Facilitate the daily stand up so that the developers that are working on the impediment stories are grouped together and the remaining developers are grouped together (almost like an internal scrum of scrums) and handle the WIP board similarly.
Great idea, Sam! I look forward to reading everyone’s approaches.
Cool! I’m in 😉 I like puzzles.
An observation – I believe taking 1 story into a sprint is a bad idea. 1 story fails = 100% failure. I believe when I trained the recommendation was at least 5 stories so 1 failure = 20% failure. In the teams I work with we’re generally pulling in 10+ stories in a 2 week sprint but we’re generally very granular.
So my first attempt would be break it down. And root cause analysis on why that is impossible.
I’m going to assume there is actually a valid reason why the story can’t be broken down.
So next step – can we upskill the team so that the entire team can solve the problem in one sprint instead of just 2 team members over 2 sprints. If not – lots of whys and root cause analysis.
So assuming we have the large story, still at 40 points and still with only 2 devs able to work on it. This is sad.
Options
– increase the sprint length – crappy… but the team could request to do that.
– run the story over 2 sprints – hmmm… crappy.
What I have done in the past, that I’m not 100% happy with, is to let a single dev go off and do a large scale refactor in 1 sprint by themselves. This gets merged back into the trunk. It has the risk that it won’t be complete in the sprint. But the rest of the team moves on and does work happily on the main trunk – the other 4+ stories. The other option is to stage this across several sprints while running both solutions in a large scale refactor side-by-side – which if we _were_ deploying every sprint would be required – we used to do that at Hybyte and I know e-bay does this. But if you aren’t releasing to production this is potentially inefficient and wasteful because the side-by-side solution will never reach production. Now that I’ve written that I suspect the better answer seems to be the staging solution where you say – yay – I’ve done a bunch of work but you see nothing different which is a sign of success – and potentially demo writting to both places or whatever the change is – to show that both solutions are active. This becomes a coding problem – not a story / business problem.
But then again – I have no idea as to what the _actual_ story is and why it can’t be broken down, etc so this might not actually be valid.
That was fun. Thanks for the thought experiment. I look forward to the other solutions!
I’d kick their ass! The coaching way – I’d ask in the retrospective “how did we go that Sprint?” there should be lots of realization that we failed our sprint and our Goal was not met. If no one thinks this is the case then I would revert to Teaching mode about what Sprint Goals are for, what the planning is (supposed) to involve and that the entire team is accountable for achieving the Goal of a Sprint – therefore it is up to the team to say – No we can’t bring that story in to the Sprint – we obviously need to break it up differently so we can all help accomplish the Goal – do something at least so we get something of potentially useful functionality out the end of our Sprint. We let teams fail, but also need to be that safety net at the end of the fail fast cycle of a Sprint to Coach, Teach, Mentor or Facilitate Scrum – come-on were ScrumMasters – that’s what we are here for – do your job! Then they will do theirs, better hopefully!
Great that your doing this Karen
I like your approach, it is very must a more leadership style of getting the team to self organize in order to solve the problem. Thanks for your answer post!
You need to coach the team on the value of small increments of work. Large stories tend to have vague acceptance criteria, are not very testable and don’t pass the basic INVEST criteria. I would ask the team during the Retrospective why they were not able to complete their sprint commitment. I would ask them how clear and accurate their 40 point story estimate was. I would ask them what plan they had at the start of the sprint and how that plan changed over time, as more information and knowledge about the increment of work was discovered. Also, I would ensure that their discoveries were the basis of a discussion with the Product Owner, to help build an appropriate understanding of the level of detailed analysis the team needed at the outset.
To help hit home the point of the value of small increments of work, I would have the team do a quick exercise outside. I would ask them to move a 500 pound boulder (when they try to move it they fail). Then, I would ask them to move the 50 ten pound rocks that are in a nearby pile. I would then ask them to describe why moving 50 ten pound rocks is easier, more efficient and smarter than moving a 500 pound boulder. I would ensure they get that constraints of size on work items makes for efficient teams. Then I would tell them that the 500 pound boulder really weighed about 2,000 pounds. They would understand that like icebergs, large stories come with a depth and mass that is probably not well known and is obscured by what you know only based on what you see at the surface.
As their Scrum Master, I would ensure that a well-groomed, organized and appropriately constructed product backlog existed prior to the next Sprint Planning session. I would work on ways to ensure the Product Owner took more responsibility for providing the required level of detail and to decompose larger stories into smaller and smaller bits of work.
I would also ensure that my failure, surely, as a Scrum Master that allowed my team to commit to a 40 point story was also owned by me, that I took responsibility and ensured I would not allow the team to proceed on to the next iceberg.
Scrum Puzzle sounds great 🙂
In sprint planning I would just hand out scrum poker cards up to 13 story points. They should find out how to cut big stories in more smaller parts to get things done in one sprint and to get more different things to do for mor developerd in the dev-team. They should feel the need of getting things (single tasks) clearer in the beginning and feel the power of getting things done. They also should share their knowledge (for example by pair programming) to enable more people developing the needed things in future sprints…
It’s gratifying to know that my immediate thought on this puzzle was echoed by most responders 🙂 So, I agree: The User Story needs breaking down.
This addresses the problem the Team identified (only 2 Devs were working). It also means that the Development Team will be able to produce potentially releasable product (a requirement for a Sprint). Coincidentally, (but never to be underestimated) it will also improve morale as now there will be the impression of progress.
The facts:
Planned: 40
Achieved: 0
The problem: Only 2 developers can work at the same time.
The conclusion: Story too big and only 2 can work on one story at a time.
The action: Big stories will not be completed in a single sprint and take on more stories for the rest of the team.
Personally, I believe the team have identified the problem but may have not come to the right solution. From experience there is usually a bigger problem under the surface to the problem they identify.
How to find them? 5 whys works effectively. Ask the team why we have this problem. Then for each answer ask why.
An example:
Our football team keeps losing.
Possible solution: Replace the team or shout at them.
Using the 5 whys.
1. Our football team keeps losing. Why?
2. Because they score more goals than us. Why?
3. Because our keeper is letting in the goals. Why?
4. Because the defence keeps letting their strikers through. Why?
5. Because our centre back is really our second goalkeeper. Why?
6. Because we do not have enough defenders on our team.
The solution of the final why would be: Get a new centre back.
The solution after the 5 whys is an action that is likely to solve the problem than the first one.
So my answer is to discover the root of the problem and let the team find out and resolve it. There is no definite action to resolve the problem above since it depends on the team that works on it.