At Made by Many, sprint planning is a key ritual that the full core team attends on day one of a new sprint, especially during the Proof of concept and Go to market phases of projects. Sprint planning is standard practice in technology teams across the industry, but it takes on a special significance for us because of the composition of our teams and the work we do. We privilege the disciplines of design, technology and product/strategy equally, so successful planning is where each voice has been heard and a consensus reached. We also aim to work collaboratively with our clients, who ideally play a central part in these sessions.

At Made by Many sprint planning is held for three main reasons:

Having this session means that the team can launch into a new sprint with renewed energy and focus without needing to continually pause to question scope and priority.

Sprint planning happens with all members of the core team in the room so that decisions can be made based on group discussion. With the centre of gravity being so focused on talking and decision making, it's important that these sessions happen face to face. Typically, the core team will be comprised of the cross functional team unit at Made by Many, and key and empowered team members from the client.

Working in small, co-located teams means that the team brings shared knowledge and understanding of the team goals, user needs and current situation. Where the team isn't fully co-located, sprint planning is a key moment when core members come back together again to ensure that there is shared understanding around decisions being made in a forum where everyone can participate in challenging scope and priorities.

In planning, we aim to break stories down into small chunks so they can be completed more quickly, become easier to estimate and to improve the flow of the sprint. Stories can be split in a variety of ways e.g. front end versus back end.

There are always a number of factors to take into account e.g. is it essential for a product to work? Is there a clear and evidenced user need? Is there a key business requirement? Stories are prioritised in context as part of a discussion within the team. We use a variety of techniques to do this e.g. 'buy a feature’ or 'MoSCoW'.

We typically use story points to estimate the effort each story will take; the estimates are based on perceived complexity. These help in determining team 'velocity' but it's important to note that these do not equate to time. We tend to use planning poker cards on the Fibonacci scale to surface the estimated effort level from each team member. This is a great way to flush out discussions about different approaches that may either speed or slow delivery.

We build flex into our process so that we can continually learn and iterate. There's a shared understanding that changes made outside of sprint planning need to be accepted by the impacted team and communicated openly among core team members. If there are too many disruptive changes being made outside sprint planning, that’s a trigger for the team to look again at the process: is sprint planning in its current form still doing its job or could it be more powerful if the format changes in some way?

We have many tools at our disposal to plan the work a team does – we assess the needs of each project on a case-by-case basis and decide what makes sense for the team and stage of the project. It's important to remember to experiment to find the best approach for the situation and to keep optimising over time.

On a recent project scaling an employee app we had built from an MVP used by 50 people to a fully scaled service used by 14k staff members, our sprint planning process changed dramatically at different project stages.

Early on in the project, there was a broader team objective (to discover what should be in the app MVP) and therefore sprint planning was key for the team to reflect on the many options available to us and to reach consensus about what to focus on next. That planning then allowed the cross functional team to focus on the agreed priorities for the next two weeks with very little change to the priorities that emerged from sprint planning.

However, when we started scaling the app the nature of the development work in particular changed. Rather than rapid build cycles for each epic, we needed to focus on some large scale technical challenges that sometimes spanned multiple sprints e.g. integration work with our client’s legacy systems and independently verifying the service was secure enough to go live.

At that time the team had clear overarching priority (to scale the app) and, while maintaining clear communications with the rest of the team, were empowered to make a call on the next best thing to work on. Scrum sprint planning sessions therefore soon became more of a hindrance than a help for the team because they invited a prioritisation discussion from the wider team when it was already clear what the priorities were. They just needed to be given as much time as possible to focus on the development work itself.

Therefore, we collectively decided to switch from Scrum to Kanban, which successfully created a more efficient team dynamic. This gave us more time to focus on delivering a high quality and delightful product to our end users; something that really paid off when we saw the fantastic reaction from them when the product went live to the full business.