This article was written by members of the DB Results Agile COP: Jasmine Nguyen, Soumya Misra and Ben Brumm.

At DB Results, we use agile methodology with many of our customers to provide predictable delivery. We run a monthly Agile Community of Practice (CoP) with our internal consultants to share what we’ve learnt across client sites, and to ensure we’re continually putting our best foot forward. In a recent Agile CoP we explored the ups and downs of sprint planning and sprint retro experiences. Collating experiences and learnings from the consultants, here are some key considerations for your next agile ceremonies to help you run smooth, efficient and effective sessions!

SPRINT PLANNING

Sprint planning is a crucial agile ceremony that sets up the expectations and action plan for the next sprint, which is typically 2–3 weeks of work. The sprint planning session is timeboxed and the whole team is involved, including the product owner, scrum master and the agile team, to dictate the scope of the sprint. Here are our top sprint planning tips.

Ensure your backlog is ready for planning

By ensuring the preparation work is done (i.e. backlog grooming), the team should be prepared to pick up backlog items and know what their deliverables are for the sprint. This is not the time to write all the backlog items in sprint, but to consider how the tasks fit to meet timelines and people’s capacity.

Everyone needs to be prepared

The product owner (PO) should be aware of external timelines and communicate priorities for the team. It’s the PO’s responsibility to know which key tasks should come into sprint planning, and what features and goals need to be achieved for the sprint. By leading with direction, the sprint planning runs more efficiently as the PO is clear what takes precedence.

The rest of the team, led by the scrum master, should have ownership of the sprint planning and will control the finer details of the session. They should be ready to bring additional detailed stories to submit, or pitch new tasks to the sprint without requiring permission from the scrum master.

It’s important that sprint planning is collaborative. One consultant highlighted that they saw team members leave sprint planning after they finished their individual contribution; this impacted the overall team awareness and made it difficult for people to be engaged throughout the sprint.

Bring everyone to the table

At times, people across the team may be working on different initiatives or projects, which can make it difficult to keep the whole team involved.

• People may not be engaged if the planning does not concern their piece of work. This is an opportunity for the PO to reiterate that keeping up to date on the overall work allows for people to jump in to assist if there are capacity issues. Additionally, team members often have diverse skillsets. Sprint planning is a great opportunity to leverage each other’s strengths and upskill fellow colleagues.

• People on different pieces of work may use different jargon. One solution for this is to have a shared dictionary that explains what terms mean, stored in an accessible shared location or on a tool like Confluence. Once the team is speaking the same language, team cohesion and engagement should increase.

• If all else fails, there’s nothing wrong with separating sessions! Sometimes, it’s just too hard to combine planning sessions, especially if there are initiatives that only concern a few members of the team. Although dedicated sessions create the most efficient results, the PO should keep the invitations open to other team members if they are interested in sitting in. It is also important to create high-level awareness across the team so that everyone is aware of what is going on.

Decide how to pick up tasks during a sprint

There are a couple of approaches on how to take on tasks during a sprint. One option is a “pool approach”, where team members pick up stories when they are ready. Another is using subtasks in Jira to show that there is movement during a sprint. However, one consultant, who had been acting as Scrum Master, saw resistance when introducing subtasks because of the overhead in preparing the subtasks beforehand. The Product Owner should state their preference on how they like to manage work, and it is up to the team to determine a structure that works best for them.

Estimating for the sprint

A common concern for sprint planning is estimation – specifically, how do you estimate when there is unexpected leave or sick days which result in delayed tasks? An effective solution used on one project is assigning a “buddy” to each team member for their respective tasks. Through this practice, a buddy is expected to stay up to date on the other person’s tasks. If a team member has to take unexpected leave, their buddy is able to step in and drive the deliverable.

There are pros and cons with this practice; however, if delivery is a big emphasis for the team then this may be an effective way to minimise the risk of unexpected events within the team.

SPRINT RETROSPECTIVES

Sprint retrospectives, affectionately dubbed “retros”, are a great opportunity for the team to reflect on how they are working before starting the next sprint. In the moment of reflection, the team is able to foster a culture of shared understanding by acknowledging each other’s successes and areas of improvements. By giving an opportunity and dedicated time for the team to raise any issues, improvements can be made by the team before the next sprint planning.

Use “liberating structures”

Liberating structures are simple techniques which replace or complement conventional practices. They are designed to reshape organisations so that everyone is included in decision-making, not just the people in charge, which encourages everyone to be invested in the end decision. You can read more about liberating structures here.

Make sure retros aren’t the only time to provide feedback

Even though it is important to use retros as a dedicated time for the team to think and reflect, ensure that you build an environment with open communication throughout the sprint if there are any issues.

The product owner should encourage open communication, and the team can speak to the scrum master if the PO is not available. Ideally, issues can be worked out during the sprint and not brought up for the first time in retro.

Hold retro actions accountable

Too often, retros are just seen as a ceremony that the team needs to sit through. To address this, when actions are created assign someone to take responsibility, and ensure team members hold each other accountable. This way, there is effort in improving towards the next sprint.

Open the retro board early

Sometimes the nature of the sprint keeps the team going and going, with no real time to stop and take a breath. By ensuring the retro board is available a couple of hours beforehand (especially easy in today’s increasingly virtual environment), people will have more time to place their thoughts and the quality of input is greatly improved.

Find the right retro tool

Some of our favourites are:

• Funretro
• Trello
• Miro
• Microsoft Planner
• The 4Ls: Loved, Loathed, Longed for and Learned
• Program Increment Planning (PI Planning)

Sprint planning and sprint retros are two of the most important ceremonies in the agile delivery world. Sprint planning sets the scene for the sprint to come and establishes what’s expected from the team, while sprint retros give the team a chance to reflect on the sprint that’s passed and improve for next time.

We’d love to hear about any of your best and worst experiences with sprint planning and retros, whether you were facilitating or participating. Let us know on LinkedIn!