5 Best Practices for Agile Sprint Planning
If you’re managing an Agile development project, you’ll break your dev team’s work cycle down into what’s known as “sprints”—typically, two-week cycles in which your team has identified a number of features that they plan to complete within that time frame.
In order to run a successful sprint, you need to be very organized and have a strong understanding of what’s feasible to build with the team you have within a given period of time. That’s why a sprint planning session is so crucial for laying the groundwork for an agile development project. This meeting may only take an hour or two, but it will set the foundation for the project and help you visualize goals at each stage of sprint completion.
At Tivix, we hold a sprint planning session at the start of each project, just after completing the prototyping stage. At this stage, we have a strong idea of what we want to accomplish, but need to nail down the details of how to prioritize tasks and who is responsible for what. Here are our guidelines for a managing successful sprint planning session:
1. Keep it casual
A sprint planning session should involve a small team: the project manager, dev and design team members who’ll be working on the product, and the product manager if the product is internal. So don’t worry about putting together a presentation—just bring your laptop or some paper and a pen for taking notes. Make sure there’s enough coffee and snacks on hand, and focus on having a collaborative chat with your teammates.
2. Estimate what you can fit into the scope of an upcoming sprint
Once you’ve all had a chance to get comfortable, start taking a look at the master list of features that you’ve built into the project scope, and consider which ones you’ll be able to include within the upcoming sprint. It can be helpful to look at historical data for similar projects, but errors can pop up at any time and cause delays to projects, so it’s generally a better strategy to under-promise and over-deliver.
It’s also important to ensure you’re factoring daily life into the sprint—are there any upcoming holidays, or will team members be taking days off? Pay attention to past team velocity as your benchmark, but be sure to allow a range of potential output within the sprint cycle.
3. Prioritize your goals
At Tivix, we use a prioritization framework called MoSCoW to help us determine how to order our sprint tasks. This stands for:
- Must-have – these tasks are essential to complete within the sprint cycle.
- Should-have – these tasks are just as important as must-haves, but generally not as time-critical, so we’ll slot them in if time is available.
- Could-have – these are desirable features, but not critical to the release, so they’ll be included within the cycle only if time and resources are available.
- Won’t have – these tasks are deemed as unimportant. They’ll either be slated for a future sprint cycle, or may be dropped from the project requirements altogether.
By using the MoSCoW method, we’re able to carefully outline what we plan to, and hope to, achieve within the course of each sprint.
4. Plan for uncertainties
After outlining priorities, take a deeper look at the risks involved in each of the features that you plan to build in the upcoming sprint. Talk to each member of your team about concerns they may have with building out particular features, and ensure that you build time into the process to accurately address and remedy any problems that may come up.
If one feature can be more easily built after more foundational features have been completed, consider moving it to a later stage. Pay attention to your team and learn from their experience.
5. Map out the sprint
Finally, once you’ve come to a consensus on the types of features you will, might, and won’t build in the upcoming sprint cycle, it’s time to map out the sprint cycle. Break your tasks down into separate “user stories”, expressing which actions a user will be able to complete when the feature is finished. In some cases, you may need to include sub-tasks for actions that are dependent on one another or should be completed as part of the same process.
A project management system such as JIRA, Pivotal Tracker, or Basecamp can be an important part of this process, helping you to break down each task and identify who’s responsible for completing it. You can typically include estimated hours within the task to help monitor each team member’s bandwidth on the project. Such a tool provides a clear, online dashboard that everyone involved in the project will be able to access and use for communication as the project proceeds.
Once you have your user stories mapped out, it’s time to regroup with your client or internal team lead to showcase your plan. Next? Start building.