Our experience of trialling a new sprint planning process
The new process helped us to improve delivery and spread the preparation evenly within the team
We tried out a different sprint planning process halfway through a recent client project in its public beta phase. Since then, we’ve successfully shifted into supporting the application, and had some time to reflect on this new way of planning our sprints and the lessons we’ve learned along the way.
While it might seem like we haven’t changed a lot, it had a significant impact.
The results and what we’ve learned (tl;dr)
It’s taken us several iterations to tweak the new process. Altering ways of working requires both individual and team behaviour change, and that’s an inherent part of agile delivery.
Essentially, we replaced a 1.5 hour sprint planning session with two 60 minute sessions, split the complex tasks better, and asked the team to contribute more. The new process helped us to improve delivery and spread the preparation evenly within the team. Developers are more engaged in planning and estimating the work they’ll soon be doing. And it helped us plan the activities more realistically, with the team having ownership and accountability for their work.
How we used to plan our sprints
Our 10 day long sprints would start on Wednesdays. Before changing the process, we’d have a (1.5 hours long) planning session on Wednesday (day 1). This session would be preceded by a (1 hour long) pre-sprint planning session on the Monday to agree high level goals for the upcoming sprint with the client, and usually without all the developers.
On Wednesday, we’d meet for the full planning session with the client and dxw development team to estimate and prioritise the cards. Most of the sprint and planning backlog preparation was done by the Technology and Delivery Leads.
Our existing process could be fairly long, complicated, and labour intensive. As the project progressed, we also felt it wasn’t engaging the whole team as well as it could. Around the same time, a colleague shared an internal blog post on various sprint planning options, giving us a nudge to iterate our planning process and increase its effectiveness through greater collaboration.
What we’ve changed
As well as sharing the sprint planning workload across the team more equally, we wanted this deeper form of collaboration to result in:
- a greater shared understanding of the problems being tackled and the associated technical issues
- a clearer technical plan for delivery
Moving to 2 card writing sessions
With the project reaching its final stages, the main process change was to replace the sprint planning session on Wednesday with 2 “card writing” sessions. Acknowledging diverse needs and ways of working, we kept each (morning and afternoon) session to 1 hour to stay focused. We initially retained the pre-sprint planning session, but it soon lost its value and was cancelled as we’d have separate roadmap reviews with the client.
To be as productive as possible within the 60 minute sessions and involve all developers in the planning, we asked them to add and write cards in advance. We encouraged each developer to block time in their diaries before the Wednesday sessions to do this. This empowered them to step away from the current sprint activities to plan the next sprint. It also gave the developers a chance to think about and raise questions or concerns before estimating the work during the Wednesday sessions.
As a result, during the sessions, we could dedicate time to discussing each card, adding more detail and estimating it. While it was helpful to have the space to dive deeper into the detail, we’d often end up discussing just a couple of cards during the first session, and a few more in the afternoon one. We soon realised it was okay when that happened, even though it was tempting to try to cover more.
By the end of the second session, we had estimated and prioritised the work we’d talked about, using a Zoom poll to submit our estimates anonymously (planning poker). Sometimes, all the developers unanimously agreed based on the length and complexity of the work. This was fairly rare!
Mostly, the team votes differed. Perhaps unexpectedly, this was really helpful as we could then discuss the reasons for varying scores until we became more aligned in grasping the work and comfortable with how it’d be tackled. Not always easy and straightforward but very valuable.
We found that what we could cover in those 2 hours was likely to be a true reflection of how much work we can complete in a sprint. After the sessions, we’d move the remaining cards back to (the top of) the planning backlog. We were able to pull them back into the sprint when we were delivering more quickly than expected.
Highly complex features
Another useful change we made related to highly complex features. To tackle those better, we split them into 2 parts. First scoping the work and agreeing it with the client during one sprint, before starting to build it in the sprint that followed.
We found this particularly helpful when the client is still developing an in-depth knowledge of the application. Or where there are multiple client stakeholders with competing priorities that need to be managed. By splitting the work across sprints, the teams can be empowered to deal with complexity without negatively impacting on the pace of delivery.
Was it worth the effort?
Looking back, it was certainly the right decision to change our sprint planning. Albeit doing so in the final months of the project, needing several iterations to get it right, and initially increasing the workload for some (if not all) team members. The changes we made improved our delivery by involving the whole team, expanding the understanding of the problems we were tackling, and having a clearer technical plan.
Trialing the new sprint planning process was a great learning experience for us all, individually and as a team. We’ll reflect on the lessons learned in how we plan our future sprints across different projects and encourage others to try out these process tweaks too!
