Most of the teams do not release product each Sprint due to various reasons – some of them are business-related, technicalities heavily influence others. Taking the Sprint’s length into consideration helps find the right pace at which the team may use the empiricism – inspection and adaptation loop.
Heartbeat of work
Always look on the value side of Sprint’s duration
Monty Python-ish
For me, Sprint’s length is a rhythm at which:
- we, as a Scrum Team, would like (in the ideal world) to deliver value to our customers and to validate, if the results of our work, have generated an expected outcome;
- we, as a Development Team, can produce potentially releasable product increment that is usable and can provide meaningful feedback data (although we can always make releases more frequent)
- I, as a Product Owner, would like to be able to change the direction of product development.
So “how often do we want to gather feedback from our users and adjust our direction?” should be a valid question when deciding on a Sprint’s length. If you look at the Sprint’s length that way, you focus on the value.
Each product is different. The Sprint’s length should be defined based on your situation. Sprint’s length is usually a result of a game between figuring out what is more important – the volume of feedback or its quality. The answer is somewhere in-between.
There is no other way to calculate the real value of the product than to give it to end-users and to gather feedback. Feedback may be derived from metrics that were built in the product or collected as information from real users, e.g. in the form of a questionnaire.
Market’s interpretation
Scrum Guide provides only one limitation to the length of the Sprint – one month or less. During this time, the Scrum Team should create “Done”, useable, and potentially releasable product increment. The most common Sprint’s duration for many Development Teams is two weeks. It is a good starting point if you do not have any idea where to start. Remember, you always can adjust the Sprint’s length to better suit your needs. Shorter sprints may be valid in the rapid-changing environment (i.e. start-up or R&D project), where each output may generate several outcomes to the business. Longer iteration is better if the team works on a stable product and the changes in the product development’s direction are not so often.
The last thing which should have an impact on settling your Sprint’s length is the ability of the team to produce the potentially shippable product increment. The common misconception is that we should release our work after each Sprint. We should aim at as frequent releases as possible, but it should always be a business-driven decision.
Product release
What if the produced, potentially releasable product increment is not production-ready? Without it, we cannot get feedback from real users. We also do not know if our product has the assumed value. However, we can still inspect the results of our work and adapt our approach in the next Sprint thanks to Product Owner’s contribution. Product Owner should be able to fill the gap between these two worlds. With the help provided by stakeholders, we should answer the question if we are going in the right direction (check also Stop Being A Product Owner… Be Like Steve Jobs!).
On the other hand, nothing within the Scrum framework forbids the Scrum Team to release product more often. Sprint is just a minimal boundary for when to deliver a “Done” increment. However, the Scrum Team should be able to release working software anytime during the Sprint, as long as the Product Owner is involved in the decision to release it. It shortens our feedback loop and improves our ability to adapt to the fast-changing world.
DevOps
Of course, nothing is done without consequences. To increase the team’s ability to release we need to work on DevOps tools – Continuous Integration (CI) and Continuous Delivery (CD) (i.e. static code analysis tools, automation tests, release management tools). Anything that can help us improve the transparency of our process and the state of the increment.
Improving the deployment process is a great way to shorten Sprint’s length. Thanks to CI/CD we can spend more time on actually delivering value and decreasing the cost of the release (i.e. package preparation, writing changelogs, manual testing, technical documentation preparation).
Should I change the Sprint’s length or keep it still?
Sprint is the time-boxed event. It takes exactly the agreed duration. You can always adjust your Sprint’s duration to the reality of your product. You need to remember that changing the Sprint’s length may have an impact on:
- the rhythm of work – using consistent durations of Sprints will enable habits and rhythms to develop in the Scrum Team;
- metrics – you can easily capture a series of data of time-boxes which are easily analysed by the team;
- ability to deliver the increment – sometimes it may be quite challenging to fit the work into the Sprint or tempting to squeeze more work into the Sprint. The Scrum Team should always think about how to break down the work to fit within their rhythm of work;
- team’s self-organisation – too long iterations may impact the team’s ability to self-organise and create mini-waterfalls within their flow.
Remark
Scrum Team can change the Sprint’s length on the Sprint Retrospective. It is the right place where you can make this decision.
As you can see, Sprint’s length is not our decision to make. It is the decision which is made by our environment. However, we should always be aware that we can change it to fit our purpose. Sprint duration is a pulse at which inspection and adaptation of product and process happen. Try to use it as a guide to improve your ability to learn. Remember also that current Sprint may be your last – so keep focus and try to get as much from it as possible.
References
- The DevOps Handbook – Kim, Humble, Debois & Willis
- Myth: In Scrum, new features are delivered only at the end of the Sprint – Christiaan Verwijs
- I do continuous deliver, why should I Sprint? – Martin Hinshelwood
