Next episode of Scrum answered series is dedicated to Sprint.
Can I once change length of the current Sprint?
Yes, you can, but you should avoid it at all cost as this is one of the most destructive activities you may apply to Scrum team, no matter whether you want to shorten or prolong the Sprint. Sprint is a heartbeat of the Scrum, a rhythm in which the team works, delivers and plans. People use to adjust to the rhythm – they’ve already learned how to plan for Sprint length or how many Refinements they need to prepare the backlog for the next one.
Changing the rhythm, you introduce dissonance, increase the risk of making mistakes and destroy the opportunity to properly inspect and adapt.
Also, many things rely on the stable Sprint length, e.g. velocity – number of Story Points delivered per Sprint. When you change length of the current Sprint and then come back to the previous rhythm, you lose predictability and introduce the unnecessary new complexity into planning for Sprint to come. Transparency is the next thing which suffers as it’s way harder to judge whether achieving the Sprint Goal in a prolonged Sprint really was a success. It’s actually hard to answer – I would say that it is a failure that the Sprint was extended, no matter the reason.
What Sprint length is the best?
There is no good answer as it is very dependent on your working environment, team maturity and product characteristics.
According to the Scrum Guide, Sprint should last no more than one month to reduce the risk and complexity. That way you could say that the shorter Sprint is the better as it brings less risk. On the other hand, during a single Sprint the team should be able to create potentially releasable product Increment which brings value to the end customer. Therefore, the longer the Sprint is, the more value you can create.
Then how should you choose the best sprint length? Confront it with your environment and consider pros and cons of each approach. Doing so, remember that the Sprint length should be stable, but it doesn’t mean it’s unchangeable. It’s also something you should inspect & adapt within the Agile fundamental principle to get better over time. If you realize that longer or shorter Sprints may bring more benefits to the team, just consider changing Sprint length for all future Sprints. Never change the length of an already started Sprint!
Shorten Sprint length when…
… requirements are not stable.
In a dynamic environment, where requirements change very often, it is good to have short Sprints, even 1 week long. Why so? This should help you to keep requirements stability inside the Sprint.
You should also work more with the Product Owner and stakeholders to increase stability inside iterations. Whenever requirement is changing, just create a new request and schedule it for the next Sprint, instead of disturbing the team’s work now. Short Sprints also allow to benefit from frequent feedback from users, of course only if you can release product every Sprint. If not, then you are not ready for that.
… the team is dealing with many different topics during one Sprint.
This is one of the symptoms that your Sprint lasts too long. Having shorter Sprints decreases team’s capacity inside one Sprint, so it will be much easier to have only one topic at a time to work on. This will help to define proper Sprint Goal and create shared responsibility for the outcome of the Sprint.
Shorter Sprints require also more discipline, so they should be helpful with setting priorities and defining what is important and what is not.
Also, Product Owner will need to make tough choices on what should be included in the next Sprint and what should not, as it will be way harder for her/him to smuggle topics of lower importance.
… team becomes more mature.
Shorter Sprints require more discipline and technical excellence than long ones. There is no time for any waste, if your iteration lasts one week and a task is blocked because of a dependency for two or three days, you probably won’t finish it.
They also require huge maturity in software factory configuration and automatization – remember that after each Sprint you should have a potentially releasable software.
This means that during the Sprint not only the development needs to be finished, but also analysis, documentation, testing and the release procedure. For mature team having short Sprints can be a very good challenge which will encourage them to further improve their methods of work, while the same time should increase flexibility of the organization.
… the product is new, the risk is big and the team is not sure what they should do.
During initial stages of the product development, when the risk is big and product vision is not stable yet, shorter Sprints should work better, giving you opportunity to act more dynamically, easier introduce changes and gather feedback. Also, Product Owner is given a chance to stop product development earlier. This limits financial risk to the cost of one Sprint – the shorter Sprint is, the less money you will lose.
Prolong Sprints when…
… you are not able to create meaningful Increment in one Sprint.
Every Sprint should deliver potentially releasable Increment which brings value for the end customer. Whenever your Sprints are so short that you are not able to deliver anything meaningful, it means that probably you should make them a bit longer. Otherwise your feedback loop won’t work efficiently – people present on Sprint Review won’t see any progress and they will just stop coming, because it will be waste of their time. Users also like to see changes with every new update or version – make sure that you fulfil this need.
… the team is new.
Make sure that you don’t start with 1-week Sprints having a fresh team. As I mentioned previously it requires strict discipline, mutual understanding and great collaboration between team members to run short iterations efficiently. As short sprints are ‘harder’, you should not risk that a young team will fail at their beginnings. Instead of that give them a chance to make good progress within longer 2 or 3 weeks iterations, in order not to destroy their enthusiasm and drain energy. Give the team space for learning and making mistakes, while still having possibility to succeed with a Sprint Goal.
… product is mature.
Whenever you have clarity on further product development plans, longer Sprints may be a better choice. With the product getting more mature, its complexity increases, and the roadmap becomes more stable. What is more, further development of already launched product with thousands of users becomes more time consuming than implementing new features of a brand-new idea. Time needed to deliver the same value in mature product is usually bigger than in green field, because there will always be some technical debt (see here) or dependencies that will slow down the development. Prolonging Sprint length of a mature product allows you to mitigate that and still sustain the prime rule – every Increment should provide meaningful value for end users.
Is there any suggested Sprint length then? No, but two-weeks Sprints are the most common as they represent a good compromise between risk and complexity reduction versus meaningful value delivery.
What is Sprint 0?
Sprint 0 is a warm-up concept for newly formed teams, or experienced teams starting to work on a new product. During this Sprint you should prepare working environment, train people, build initial Product Backlog and prepare to the Sprint 1 Planning. I don’t know whether you noticed that or not, but the Scrum Guide gives us no clue how to create Product Backlog from scratch: expectation is that Product Owner will come to the team with already existing Product Backlog. In reality, this doesn’t happen often though, and Sprint 0 addresses this to some extent. Personally I don’t like this idea – I believe it is better to start from Sprint 1 and just set proper Sprint Goal, like: “Initial Product Backlog is created”.
Should you have any other questions about Sprint, feel free to ask leaving a comment. Stay tuned for the next Scrum topic.