Surely you're here because you understand the importance of a successful Sprint planning, so we won't bother you with cliches about its importance or cruciality. You want actionable tips and best practices that will help you have an effective Sprint planning, so here they are.
Set the Sprint Goal
Coming up with a Sprint goal is an essential part of every Sprint planning. It should be specific and measurable and the result of a discussion between the Product Owner and the Development Team.
In order to help you decide on the Sprint goal, ask yourself the following questions:
- What do we want to achieve? This includes not only the isolated Sprint but also its contribution to the product as a whole.
- How can we achieve that goal? The team must go through each item and make sure everyone understands its requirements and can foresee possible impediments. This contributes both to the estimation and the Sprint goal clarity.
- How can we check whether we have achieved that goal? In other words, the definition of "Done", which is unique to your team and it's your job to make sure you're all on the same page.
Another important aspect to take into consideration is whether the goal you want to set is challenging enough. You don’t want to create a goal that is too easy to achieve only to have a successful Sprint. After all, Scrum is all about the continuous improvement from iteration to iteration, and setting the bar too low won't contribute to the product nor the team. Make it challenging enough to bring out the best out of your team.
Once you Sprint goal is set, it will provide guidance to the Development team and help them set priorities to achieve that goal.
Arrange planning preparation meeting
Even though this is not a mandatory step, it can help a lot before the actual Sprint planning. You can discuss all the tasks that you intend to include during the Sprint planning with your team members.
The key to the success of such a meeting is to make sure that every task is clear and precise. If that is not the case, discuss openly why you think that might pose a problem and how to solve it. This way, prioritizing, creating subtasks and estimation that are done during the actual Sprint planning are much easier to complete.
Now that you've taken the time to set the Sprint goal and clarified all tasks, it is much easier to prioritize tasks that will help you fulfill that goal.
There isn’t a right or wrong way to decide on the priorities, as long as your team members participate in an active discussion and decide together what will be done during the Sprint. This can be done by team members simply discussing what they want to achieve by completing that task and what, according to them, that successful completion might bring.
Some teams prefer tackling the bigger tasks first and leaving the smaller ones for the end, while others prefer completing the smaller tasks first so they have more time to focus on the complex ones. Your workflow may be unique in its own way, as long as the tasks are in line with your goal and everyone's in sync.
Once you've decided on priorities and which tasks you want to complete, it is time to create smaller tasks or subtasks that will help you complete them. This is necessary due to the fact that some tasks are simply too complex to be tackled as a whole and dissecting them into a series of smaller ones will help focusing on each properly, as well as give a bird's-eye view of all required processes which you otherwise would have encountered much later (or even too late) in the production.
To help you check whether you can divide your tasks into smaller ones, ask yourself:
- What will I do first?
- What will I do next?
- And after that?
The goal is to make sure that there are no tasks that exceed a full day of work. If you keep working on one task for 2 or more days, you won’t be able to follow the progress. Also, if you need help with something, it is much easier to collaborate with others if the tasks are smaller and others can quickly jump in and help. Having to explain at length what you've been doing in the previous few days will waste time that can be spent on completing tasks.
It should also be pointed out that agile project management sprint planning should never involve planning too much ahead as this belittles the whole point of being agile. This can be hard to accept if you had worked on more traditional projects in the past, but you will only waste time trying to create all subtasks days ahead. New information will definitely come up and it will render your preplanned subtasks obsolete, meaning you only wasted time.
Don’t take on too many tasks
It is easy to get too confident and take on too many tasks. While the Sprint goal should be a challenge for the team to fulfill, taking on too many tasks is counter-productive. Failing to deliver what the team agreed on, sets the stage for frustration and disappointment.
This can be solved by estimating how much time will be spent completing each task. You can and should use your previous experience completing similar tasks:
- What was the initial estimate?
- Did you deliver in that time?
- Were there unforeseen impediments?
- What are the chances of encountering them again?
- What other impediments can you predict?
Remember, there is no shame in scaling down and you shouldn't feel frustrated or unproductive. You'd rather have a realistic sprint that is fully complete than an optimistic prediction without the realization. Create smaller tasks and reestimate from there.
Agile project management sprint planning (including Scrum Sprint planning) is one of the biggest moves away from the traditional projects and it can take a while to find the balance, but it is more than worth it.
What are your tips for an effective Sprint planning? Would you add any tip that we haven’t included?