A deeper understanding on…

The Sprint

Road to PSM III — Episode 10

“Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.”
— The Scrum Guide.

During a Sprint the team is focussed on what is most valuable now. they also strive to become a little bit better each sprint. They improve 
a. the product, b. their work environment and c. themselves.


Every Sprint, the team gets together on regular, consistent intervals. Consistency reduces complexity. In repetitive (iterative) cycles Increments are created. This routine enables continuous improvement; transparency, inspection and adaptation. This should eliminate, to an extend, the need for other meetings. With Scrum, teams don’t idly sit around a table, but actively work together to do inspections and create actionable short term plans. Counter to disciplinary segregation, they are cross-functional and collaborate throughout the day when needed. This is a great counter to meeting-cultures.

Though a team strives to deliver “done”, working Increments, this is not to say these are final once delivered. A powerful mechanic of Scrum is the ability to continuously improve. In my experience I noticed several teams had a ‘deliver and forget’ habit. Once they finished work in a Sprint on a Product Backlog Item, they never returned to it. After the Sprint Review, they weren’t collecting feedback, inspecting its use, nor suggesting or attempting improvements. Often they weren’t inspecting how what they delivered was used and experienced, because they were already focussing on the next new shiny thing. At times they’d even joke about it being better that they (or the client) didn’t know. 🙈

At times I noticed teams extending Sprints to process feedback or fix defects, or finalise something that isn’t yet “done”. Have they forgotten about the incremental nature of Scrum?


The Sprint and its events have a Timebox.

A timebox is an agreement made upfront about the duration of a certain activity. The maximum duration for a Sprint in Scrum is a calendar month. Teams are free to determine the interval, but it is advisable that these remain fairly consistent.

“Sprints have consistent durations throughout a development effort.” — The Scrum Guide.

A timebox cannot be changed once in progress. Many Scrum Teams determine the timebox of a sprint in a number of weeks (one to four) and adjust the timebox for its events accordingly (save the Daily Scrum). Scrum doesn’t prescribe this, but does say that with shorter Sprints, their timebox tends to be shorter too. It is a common practise. So with a one week Sprint, the timebox is generally two hours for a Sprint Planning, one hour for a Sprint Review and fourty-five minutes for a Sprint Retrospective.

A steady routine enables fast habituation. Excellence is an art won by training and habituation. We are generally used to a weekly rhythm. In my personal experience this makes a single week Sprint, although ambitious, feel very natural and practical to exercise. Every week is consistent with the moments of events. Not all teams will be able to deliver qualitative working increments in this timeframe, but figuring out how to do this might be one of the most valuable exercises a team can engage in. A Sprint has to be short enough so a team can adapt to changing conditions. It also has to be short enough so the work can easily be integrated. Big increments will make integration complex and increases the risk of technical debt.

The timeboxes for Sprint Events only have a maximum duration, no minimum. This means they might end sooner. Over time Scrum Teams should learn to have more effective and meaningful events. A popular argument teams make for example, is that they feel the Daily Scrum is mundane as they are already aligned. If this is truly the case, then nothing prevents them from having only a three minute Daily Scrum in order to confirm if they indeed are aligned.

Sprint Cadence

Sprints are consistent and continuous. The timebox for a Sprint may not be shortened or extended. It’s a heartbeat that ought to remain consistent. When teams consider meddling with its rhythm, they might just be ignoring the underlying defect or anti-pattern. Teams should use the Sprint Cadence and take their responsibility to inspecting what is actually going on. Why is the team considering this? I’ve witnessed all sorts of reasons or excuses for Sprints to be extended, but these three being by far the most common:

  • The Sprint isn’t “Done” yet. Which exposes the anti-patterns if the use of the Forecast or the Sprint Goal.
  • Essential members are indisposed, thus it makes no sense to continue. Which might just indicate a lack of team commitment, sense of responsibility in self-organisation or cross-functionality.
  • The Product Owner (or team) need more time to do pre-requisite work for the next Sprint, like processing feedback, updating the backlog, finalising designs or putting in place technical infrastructure. This might indicate the team has isn’t effectively engaging in Backlog Refinement or utilising the events.

If your Sprint Cadence is unstable, I reckon that ultimately your product will be too.

The Sprint Goal

Every Sprint has a clear purpose and thus a goal that is collectively formulated by the entire Scrum Team. This goal may not be altered during the Sprint. Also, quality goals do not decrease!

So as long as the Sprint Goal is not put at risk, the team may respond to change. Changes are valuable. A team will learn to calmly and professionally react to newly discovered complexities.

Good Sprint Goals can aid the team in creating a selection of coherent Product Backlog Items. This selection is called a Forecast. The Sprint Goal enables a degree of flexibility in what the Development Teams will choose to implement.

Sprint Goals may be ambitious (it’s a goal after-all) and promote collective collaboration. Each member should be able to contribute to the Sprint Goal. Note that the end of the Sprint isn’t a deadline for the Sprint Goal. A team commits to putting in a reasonable effort to try and achieve it within the Sprint’s timebox. It can (and perhaps should) be the case at times that a team won’t make it. A team may have performed splendidly, yet still failed to reach it. I’ve often worked with teams who at times didn’t meet their Sprint Goal. They were superb teams, who set great and challenging goals and always strived hard to try and meet them. Not meeting them was disappointing at times given the effort they put in. But the learnings from a retro were even more valuable. Consider the distinction of ‘the ability to deliver commitments’ vs ‘the commitment to strive to achieving Sprint Goals’.

Forcing teams to meet goals, even to work overtime if they are challenged, will not motivate teams to set ambitious goals, on the contrary. This said, each member should at least consider the goal it sets for itself to be achievable. Not every Sprint Goal needs to be ambitious. Remember:

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” — The Agile Manifesto.

The Sprint Goals shouldn’t result in exhausted, demotivated developers; on the contrary! Development Team members should find the Sprint Goals motivating. With motivating Sprint Goals, the teams will put in the extra mile on their own account. They make their job worth it. The goal should help the team to better understand why they are putting in the effort. A great Sprint Goal could enable teams to deliver lots of value with limited effort. So when designing Sprint Goals, consider:

“Simplicity — the art of maximizing the amount of work not done — is essential.”— The Agile Manifesto.

Continuous Improvement Goals

Not commonly known to teams is that they don’t only have a Sprint Goal, but they too have improvement goals, which are formulated during the Retrospective for which an actionable plan is created in the Sprint Backlog.

“To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous Retrospective meeting.” — The Scrum Guide

When members of a Scrum Team indicate that they don’t really care much about either formulating or realising these goals, the team might lack creativity (or empowerment). This may be the case when Product Backlog Items in general don’t really have any coherence, or the team isn’t truly collaborating cross-functionally. In these cases it may be advisable to set goals that promote creativity and cross-functional collaboration first.

Interactive Scenarios.

I’ll introduce a little experiment. I’m a little doubtful if this will work here at the bottom of the lengthy post far into this elaborate series, but let’s see.

I’ll share some scenario’s which you can share your thoughts on. These scenarios hint at possible anti-patterns or environments where Scrum isn’t practised or understood properly. Feel free to share some more. Drop them as a comment or message me in Slack.

With these scenarios, take note that it is often best to refrain from passing verdicts as one can only best assess a situation once they are in it. That said, these scenario’s provide some interesting thought-experiments.

Just select the scenario you wish to comment on and click the comment bubble icon.

  1. During a Sprint, the team realises an item it selected in the forecast is much more complex then estimated. With approval from the Product Owner the Development Team changes it for an item it thinks it can finish.
  2. A Development Team couldn’t finish an essential item needed for demonstration during the Sprint Review. They suggest to postpone the review until the item is ready for demonstration.
  3. A Product Owner suggests to postpone the next Sprint as he/she needs more time to process feedback and update the Product Backlog.
  4. On a Friday, a Scrum Team ends the Retrospective way before the timebox expires. They are happy about the previous Sprint. They are done with their improvement plan for the next Sprint. The Sprint is over and the next Sprint Planning is planned Monday morning. They decide to go home early.
  5. The timebox for the Sprint Planning has expired. The Scrum Team doesn’t yet agree on an actionable plan for the Sprint. They decide to extend the Sprint Planning event.
  6. The upcoming Sprint Retrospective is cancelled. A team always hosts this on a Friday, but it happens to be a national holiday. The Product Owner argues that, due to this holiday, the team is already pressed for time. He argues that they already have many retrospectives, so surely they can miss one.
  7. Late in the Sprint the Product Owner asks the team to pick up a new urgent item. The Development Team argues it can only take on this new challenge, if it drops their only team improvement goal. The Product Owner argues that the needs of the client outweigh the needs of the team.
  8. At the end of the Sprint the team hasn’t been able to deliver a satisfactory working increment. It contains a lot of defects. The team argues it didn’t have time to check all the DoD’s, and already explains many of the DoD’s haven’t been met to begin with. It received a lot of critical feedback from unsatisfied stakeholders. During the review, under pressure from stakeholders, the team agrees to extend the Sprint to finalise the increment properly.
  9. The Development Team decides to drop some Definitions of Done for the iteration in order to meet the Sprint Goal. They argue that this current Iteration doesn’t need to meet all those strict criteria for it to work.
  10. The Scrum Team didn’t finish all the Items it selected for the forecast. The client argues that the team should finish all the items as agreed and postpones the next payment until they have.

In the next episodes I will deep-dive into a powerful ability of the Product Owner: the authority to cancel Sprints.

Sprints reduce the risk of cost to its timebox, but there is much more to explore on this subject. So I’ll also dedicate an episode on some of the commercial scrum conundrums.

Did you like the article? Then it would be awesome if you’d clap 👏🏻. I am also very keen to learn what you think about this topic.

Do you want to publish in Serious Scrum? Connect with us on Slack to make it happen!

We run a Serious Scrum channel on Slack. You’re all invited. Feel free to reach out and connect with us on Slack to share your thoughts.