Déjà vu What is a good sprint plan?

I observed a Sprint Planning meeting the other day where people wanted to reuse the task stickies from other sprints as they claimed to be more or less the same in every sprint. It actually was a Déjà vu moment. While having lunch with a old friend he said the same issues came up in his team.

So I decided to write this little post although I feel a little ashamed to write it. The Scrum guide states in Sprint Planning part two

‘Having selected the work of the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint.’ 

The Scrum guide also states that

‘By the end of the Sprint Planning Meeting, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment.’

Ok, so how do I achieve that? How do you know you have a good plan? What does a good plan look like?

A POOR SPRINT BACKLOG

A poor Sprint plan describes what work needs to be done. Remember that the what question is the goal of Sprint Planning part one. The result of Sprint Planning part two should be a sprint plan that describes how the works needs to be done!

Lets look at an bad sprint plan example.
For a user story you’ll probably need to do some coding, testing and other things as described in your Definition of Done. If a team plans what it needs to do then the tasks could be e.g.
Task 1: Code UI
Task 2: Code Server side
Task 3: Write test cases
Task 4: Execute test cases
etc.

Obviously having such a task list does not make any sense unless your team members have a bad memory and forget what they are supposed to do. A team that comes up with a plan like the one above could easily reuse the plan for every sprint.

The whole purpose of the Sprint Planning meeting is to create a detailed and shared understanding of how the sprint is going to be delivered. At least for a good part of the Sprint. The tasks are just a possible side effect but not the purpose of the Sprint Planning meeting!
The team needs to understand what they need to modify, extend and create in order to achieve the necessary results. The team builds on the work they did in Sprint Planning part one where they e.g. walked through the UI prototype or modeled the UI using screen sketches, wrote acceptance criteria, draw flow charts or whatever other Agile modeling techniques they used.

A good sprint plan could have the following tasks
Task 0: Extend page flow A->B->C with …
Task 1: Extend Service X to cope with new ….
Task 2: Sit with Domain Expert to come up with …
Task 3: Update Repository XY with …
Task 4: Create new table A, B, C …
Task 5: Pair test/develop initial FitNesse tests for …
Task 6: Create new component Z for …
etc

So if you can reuse your stickies across sprints there probably is something very wrong with your sprint plan.