Eve, the newly minted ScrumMaster was facilitating her first sprint planning for the Jalapenos team on Project Lhasa. She had worked hard with Lilia, the Product Owner, beforehand to make sure the product backlog was well organised, prioritised and understandable and the team had reacted well. The first part of the sprint planning meeting included some planning poker to estimate the top 20% and some good conversation emerged between the team and Lilia. The team committed to 28 points of product backlog (8 items) and were now in the second part of the meeting, where the team work out how they are going to turn those 8 items into potentially deployable functionality.
Clinton, Tania & Kurt were around the whiteboard with a stack of post-its, scribbling down tasks while sketching out how the design is probably going to look while Malinda, Darren and Jessie were working out some of the infrastructure items they were going to put in place. The number of post it notes was growing well and the teams were estimating them as they went; the energy in the room was high.
As things started to quieten down, Eve reminded the team that it was up to them to sign up for tasks and nobody was going to assign work to them and so, with 45 minutes left until the timebox for sprint planning ended, perhaps they might want to have a look at the sprint backlog (essentially made up of post it notes) and start signing up for the tasks so that they had a plan for the sprint. Eve also asked if they needed any help.
The team seemed fine and set about signing up for tasks. There were a few post-its that a couple of people on the team both wanted but they worked things out amicably without the need for any intervention and it was generally a smooth process. Looking at the sprint backlog as a whole there were probably around 50-60 items in all and the team comfortably managed to put the initials of the person signing up to the tasks on to the post-its within the time limit. By the end of the sprint planning session the team had verified that they were indeed happy with the commitment of 28 points worth of product backlog that they had made and also had a pretty detailed sprint plan in front of them. They went home that evening content and ready to get going the next day.
As the sprint progressed, not quite as smoothly as they hoped it might, Eve noticed some interesting behaviours from the team particularly in the daily scrums. Every morning, the team would look at the sprint Burndown and answer the three questions, but they never seemed to deviate from the sprint backlog, even though the sprint seemed to be slipping away from them. Whenever Clinton, for example, finished his current task he would automatically move on to the next task that had his initials against it. When Eve told the team what she was noticing, the response from Jessie was “Of course. Why wouldn’t we?”
Teams find planning very difficult – not just in Scrum, but in general – mainly because the future is full of uncertainty. There are techniques that we can use to help us remove some of the uncertainty and we can make some helpful assumptions about the things that we know we don't know. But there are also a lot of things we don’t know that we don't know, which cause us problems and anxiety. When faced with this uncertainty, teams tend to respond in one of two ways: they either do no planning and just see what happens, reacting to situations as best they can when they arise; or they over-plan in an attempt to plan out the uncertainty.
At every level of planning we must battle these opposing forces to land somewhere sensible in the middle where we have done just enough planning and leaving just enough opportunity for the plan to emerge. Sprint planning is no exception. The point of sprint planning is to answer the two questions:
What from the product backlog, as a team, can we commit to getting “done” in this sprint?
How, as a team, are we going to turn those items into a potentially deployable increment of functionality.
Eve was right that it is up to the team to determine how they will organise themselves, how they build the design and who will do what task but that does not all need to be completely decided in the sprint planning session. In fact, in my experience, it is often best if we make it very explicit that some of that information is going to come out during the sprint. By having all of the items on the sprint backlog with people’s names or initials against them in sprint planning, you are very likely to end up with a situation like the Jalapenos found themselves in. In these situations, the team is not self-organising to meet the team’s commitment. Instead, the individuals are ensuring that the commitments they each made are OK. This is not the same thing.
When the team got to the end of the sprint, and the sprint goal was not met, 4 of the team members were able to say “but I did all of my tasks”. This, of course, may be useful to them in terms of their performance management system but, from a project perspective, it was useless. The team had failed.
The team only needs to detail out enough of the sprint backlog for them to be relatively comfortable in making a commitment for the sprint. The rest will emerge during the sprint and in fact the process of the team consciously evolving the sprint backlog over the course of the sprint is a healthy practice for a new team to get into. It almost forces collaboration, self-organisation and evolutionary design habits.
Only plan as much detail as you need in sprint planning and encourage team members to collaborate throughout the sprint. Look at how the team is setup and whether it actually encourages teamwork or individual success.