Imagine you are working with someone new to iterative work, they ask “How long should my sprints/iterations be?“ In my experience, they have just been introduced to a scrum framework that recommends sprints between two to four weeks. To be safe, this person tells their team to do three week sprints/iterations as it is neither too fast nor too slow. They start to think “now we have a way to force people to be focused”. This is a trap in logic as it ignores your system of work.
Working with teams that move into sprints/iterations is always troublesome without understanding why they are used. People who grow up in a project management environment focus on making people sprint. Whereas a Lean-Agile approach focuses on having the product/service sprint. Where project management focuses on task achievement, lean-agile focuses on value.
To help you plan your sprint length, let’s look at the two approaches.
Project Focused Sprints/Iterations
The people sprint, so we focus on managing people as the problem.
When a team migrates from projects to sprints/iterations, the first reaction is to move the tasks from the project plan into their backlog tool as a way to track the work. They want to make sure the team members are accountable and people are working towards the sprint dates. In this case, you will usually see the project divided up into sprints where the value delivery is at the end of the project as seen below.
As a result, the focus of sprints turns into a focus on how to:
- Optimize resources (aka people)
- Pressure the resources (aka people) to respect the dates committed (usually by someone else)
- Tell stakeholders their project is being worked on as it is a priority (same priority as all other projects)
- Tracking work and ensuring people spend time on your project
But when people first start sprints/iterations, they think the purpose is to pressure people to get their work done and keep them accountable. In this case, the backlog will usually be filled tasks like:
- Setup detailed review of document
- Provide current baseline KPIs
- Preview customer issues to present to stakeholders
- Create specifications for …..
- Barry to confirm stakeholder buy-in
But our work is valuable because we are doing projects!! We know that each project has value, why else would we do it? This approach has you focus on the people and the tasks over the pipeline of value. This can start to look appealing if you have many projects in parallel where you feel like you are delivering incrementally like below:
Sprints by dates do not respect the Complexity belief that we are working a Complex Adaptive System. Rather, this approach looks for ways to make complex problems easy rather than make it easy to work on complex problems.
Customer Focused Sprint/Iterations – Managing the Work
The product sprints, so we focus on managing the flow of value as the problem.
In this scenario, you are focused on the system that creates the value for your customer(s). As a result, you look at the lead time and cycle time for a request to go from a customer need, through your system and deliver that value. The cycle time is used as a baseline for the delivery of value from the system.
But scrum says to work in two to four week sprints!! Yes, the purpose of working in sprints/iterations of this duration is to change the way you work. It is not to cut up the existing process into small chunks or tasks. The reason you do sprints is to deliver small chunks of value. So, if you work in a domain where a single request takes three months to complete based on your context, your sprints are three months.
There is nothing wrong with that !!
The reason people do sprints is to look for opportunities to improve their system and optimize for delivery, not pressure people. This is built into the Agile Manifesto’s principles.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
http://agilemanifesto.org/principles.html
In this way, the sprint duration is based on the product or system, not some arbitrary recommendation from a guide that does not account for your context. This approach allows you to focus on value over making sure people are busy.
So what do we do if we are in sprints now?
Evaluate your cumulative flow diagram and see when features, capabilities, technical stories are delivered. This is the cycle time to deliver and organize around that. If you feel that this is too long, then start to ask how to take on less work, how to remove waiting from the system or event just look at how to do more collaboration.
Sprint duration should be an indication of your system of work, not a method to create pressure for people on the team. Embrace your system of work and look to optimize the customer experience over making nice sprint reports.
Lean-Agile with Paul 
One thought on “How long should my sprints/iterations be?”