We talk a lot about Agile here at Somar Digital. One of the keys to our success with the Agile methodology has been making sure that we have highly productive and efficient sprint planning sessions. This blog will define exactly what we mean when we talk about sprint planning, who is involved, and a few other key things we keep in mind when we plan our agile sprints.
What is Sprint Planning?
Sprint Planning happens before the Sprint kicks off and is used as a session to determine the work that needs to be done. Each Sprint needs to have a goal. You need to be able to answer the question: why is this Sprint valuable? The Product Owner should have a good idea of this but also the project team should also be able to work out was is manageable in the two weeks it takes to complete a Sprint.
Who is involved?
Sprint Planning includes the project team (Scrum master, developers, and sometimes the designers) as well as our client product owner. The Sprint Planning session is a great chance for everyone to come together to get on the same page and figure out a common goal that everyone can work towards. The team works through the backlog of tasks and prioritises which ones are most important and what can realistically be achieved over the two weeks.
How do we estimate how much we take on per sprint?
An entire Agile project, like a website redesign and build, can include multiple Sprints to complete. So figuring out how much work can get done per Sprint is a balancing act between a Product Owners business requirements and what the project team can get done. During a Sprint planning session the project team will make estimates based on how long they think it will take to complete a task. A task can range from anything from implementing the dev environment to building search functionality into the website. The Product Owner will prioritise the most important tasks and then the project team will estimate how long each task will take to complete so that we can work out what can realistically be achieved during the Sprint.
What happens when we under or overestimate a Sprint?
We like to make relatively conservative estimates so that we don’t promise more than we can deliver for our clients. We also don’t want to rush through a sprint. We’d rather take on a little bit less so that we put more time into each component of the website and fine-tune it so that it meets your business requirements. It also means we can put more time into testing so that when it comes to launching the project it isn’t riddled with bugs, which could have a whole lot of negative carry-on effects down the road.
On the other hand, if we still have time at the end of a Sprint and the Product Owner has signed off all of the Sprint tasks then we can start pulling more tasks from the backlog. Because many of the tasks in the backlog should already have time estimates from previous Sprint planning sessions it's easy enough for the project team to be smart about what tasks they can pull from the backlog and finish within the Sprint timeframe.
Conclusion
At Somar Digital we’ve had plenty of experience running Agile projects and have fine-tuned the process over the years so that we get the most out of our sprint planning sessions. The last thing we want to do is overpromise and underdeliver.
If this blog has helped you to understand agile sprint planning sessions a bit better and you’d like to get in contact with us about your next digital project you can click on the link below. We’re always keen for a chat :-)
