As a team transitions to using Scrum and Agile, finding the proper sprint duration is likely something they will not give enough thought to. The team will likely just pick an arbitrary duration and set about to make that work. That is certainly one way to do it, but there is a real danger that this initial sprint duration becomes the norm without a second thought. I would caution against this idea. I find that it is important to understand how the scheduling works for sprints, and what a sprint of a given duration actually contains.
Planning the Sprint Duration
If you are doing Scrum correctly, there are a couple standard practices you will adhere to:
- Sprint planning – where your team sets out to estimate and sign up for work that can be completed in the next sprint
- Sprint retrospectives – where your team will analyze what happened in the previous sprint for ways to improve or things that worked well, these meetings typically go for two hours per one week of sprint
{{cta(‘d173b5b6-18d9-4d5d-9383-d06f0cfdfa78′,’justifyleft’)}}The reason sprint planning should be this long is because your team should be using this time to identify all the tasking that needs to be accounted for the completion of a story, as well as come up with any potential issues that may arise. Sometimes if you do not give your team long enough to sort out their thoughts, unexpected issues may arise in the sprint that prevent them from completing their tasks.
Sprint Retro is, in my opinion, more important than sprint planning. Although you get great input from developers about process and tasking in the planning meeting, I find that the retro has the ability to solidify good practices and highlight things that frustrate your team. It’s very important to not only understand what is holding your team back, but get to the things that they are NOT telling you on a daily basis.
Sprint Duration in Practice
If you take into account the suggested length of these meetings and place them into your sprint, you start to see a bigger picture. At a two week sprint, you are basically losing an entire day to complete these activities. If you go any longer than two weeks, you will lose over a day.
You need to make sure the team is comfortable with that much time being taken out of the time they can actually code in a sprint. Even though it is proportionate, it does not feel as though it is.
At three weeks, you would imagine calling your dev team together one day for a six hour planning meeting. Then asking them to come back the next day for a lengthy retrospective. When looking at utilization of your development team resources, make sure you are counting “Fingers on Keyboards” time and not the meeting time. They should be engaged in the meeting, not finishing their work.
The calendar below represents what a normal sprint cycle looks like if you scheduled a 4 hours for the planning meeting and sprint retrospective:
Other Factors to Consider
There are a few more factors to take into account. If your user stories are not clear, and not deliverable in the context of your sprint duration, you may need extra time to break them down. Or you may find that your planning meeting is very rushed. One way to combat this is to lower your sprint duration.
This forces the team to talk about fewer items to be delivered. With fewer items being considered for the sprint, the conversation can become about only the items that are important, and will not be hurried along because there are other things to talk about.
Looking holistically at the life of your sprint can help determine the ideal time. If you would like to have very small, targeted conversations, a short sprint is for you. This typically works on projects with less complexity. For very complex projects with many dependencies, longer sprint cycles seem to work better. Mileage may vary. It seems that the perfect sprint duration is actually the combination of all the factors above. Being mindful of these constraints can help you make a smarter decision about planning, and get you out of using a sprint duration because “it’s always been that way.” The object is to be efficient and deploy meaningful change, not do what has always been done.
What sprint duration technique has worked best for your project team? Share your wisdom with us in a comment below!
While you’re here, make yourself at home and check out our blog home page to explore other fixes we’ve solved in our day to day work and best practices we follow using our favorite technologies. To make your life even easier, subscribe to our blog to get instant updates sent straight to your inbox:
