When talking about sprint planning, we often think about setting a SMART goal and a clear sprint backlog. Nevertheless, to have a good plan for the sprint, we need more than just a formal meeting.
In this article, I am going to give you some simple tips on how to effectively prepare for sprint planning event. Hopefully they could make it easier for your team, especially those that are new to Scrum/Agile, when it comes to the preparation for the next sprint.
1. Getting your backlog ready
When a good chef prepares for their special menu, they pay a huge amount of attention to the ingredients. Similarly, when a good team prepares for their sprint, the main ingredients – in this case – the product backlog item(s) should be at the best state. Specifically, the PBIs should meet the Definition of Ready (DOR) and been prioritized in appropriate order.
Depending on the nature of the work, each team may have their own criteria for the definition of ready. Some teams may not even have a well-defined DOR at all. However, there are a few guidelines that I personally find applicable for most of the case when it comes to the DOR/ getting your backlog ready below:
- The PBI(s) have enough details to start the (development) work and dependencies are identified. Normally, if the PBI is a user story, we would recommend that the story meets the INVEST (Independent – Negotiable – Valuable – Estimable – Small – Testable) principle. Clearly defined acceptance criteria are also recommended.
- The team have reviewed and understand the PBI(s) and give them proper sizing (estimation).
- The team have identified the possible technical solutions/ approach to resolve the PBI.
- The PBI(s) have been prioritized in the correct order in the product, with the story with the highest priority in the top of the list.
2. Knowing the team’s capacity and velocity in the new sprint
When planning for the new sprint, the team should consider capacity and velocity. While velocity mainly focuses on the measurement of how many user stories the team has delivered in the past, capacity is the estimation of total amount available for the next sprint. There are a few common questions that we could ask when deciding on the planned scope for the next sprints, such as:
- How many stories point, in average, have we delivered in previous sprints?
- Are there any factors that will impact our next sprint’s capacity? Some examples: public holiday, planned personal leave, member change,…
- Do we want to reserve some spare capacity for other items (eg: high priority defects, training/ development activities)
I’ve seen some cases where team based their planned capacity on the average velocity of past sprint. However, this may not always be the best strategy, especially when the team is newly formed. Before the team reaches its “stable” stage, we normally want to see a gradual increase in velocity over time when the team get used to working together and the product. Picking the “right” amount of user story requires the entire team’s commitment. Also, you need to balance between stretching your capacity and avoiding overloading your team member.
3. Identify dependencies, potential risk and plans for resolution.
When a team prepares for their next sprint, we need to identify any risks, dependencies and solution to these issues. Some examples below are quite common for software development team.
- Example #1: the team needs to complete PBI A to enable the completion of PBI B.
- Suggested solution: we could try pair coding between the 2 developers to minimize dependency. Otherwise, we can defer PBI B to later in the sprint. The developer in charge of PBI B can pick up other sprint work in the meantime.
- Example #2: A member in the team has personal leave plan for a few days in the sprint
- Suggested solution: we should consider how their plan fit with the progress of the sprint. If the member’s absence cannot accommodate for some high priority ticket, it might be a good idea to have that work covered by other developers. Otherwise, we could have another developer cover the work for the days when they’re unavailable. Thus, we will not let the PBI staying idle in the board during any member’s leave day(s).
- Example #3: Too many PBIs will be ready to test at the same day and may overload the test engineers
- Suggested solution: we could swap the work among developers in the sprint. In doing so, we aim to deliver some ticket to testing side earlier. Ideally, we prefer tickets ready for test gradually in different days in the sprint rather than in the same short period
From my experience, team members sometimes focus too much on their specific tickets and forget about the whole sprint’s goal. Thus, it’s crucial that each member in the team understand that they are responsible for the entire sprint’s success or failure, not a few single items.
4. No hidden work
It’s important to ensure that everything that your team is going to build is visible in the sprint backlog. For instance, if your team is going to have some transition between an existing member and a new member, or a training session, it is best that we reflect that by using task(s) in the sprint backlog. Thus, we could improve on the work transparency, and will not forget any of the planned work.
I hope that the tips mentioned above could help you and your team to prepare better for sprint planning. If you have any other advice/experience that you think could be helpful for other people, please leave your comments below.