Design rules 🙂 Not only in product development but also in Sprint Planning 2. A team that worked with me last week did everything to understand what they really have to do in their Sprint Planning 2. The walked through the code base during the planning session. All 8 team members learned a lot. They understood their code base better and they identified together what they will need to modify in order to create the necessary results.
And believe me – we are not stuck to the idea of creating tasks. That is a side effect of a good Sprint Planning 2. It is not its purpose.
So what do I coach teams to do in Sprint planning?
- Go to Backlog Item 1.
- Re-understand what is wanted by looking at your flipcharts.
- Answer questions like:
- What interfaces do we need to write.
- What architecture do we need to create.
- What tables do we need to update.
- What components do we need to update or write.
4. When the team has a clear understanding about the necessary changes or additions they can then go to the next backlog item.
And after all this very intense work, your create some tasks so that you know what needs to be done on the next day.
Very simple, or?