Get certified - Transform your world of work today


A Sprint Is More Than Just a Timebox

13 May 2014

Jai Singhal

The whole is more than the sum of its parts. -- Aristotle

A sprint in Scrum

A sprint is a constant duration identified for delivering a product increment. This product increment is the sum of previous product increments and the backlog items done in the sprint. The product owner can decide to ship this increment to the customer, if so desired. In the Scrum framework, it is the sprint where the work is accomplished and the concept-to-cash aspect is realized. The Scrum rules bind Scrum roles and responsibilities, Scrum artifacts, and Scrum ceremonies. A sprint provides the basic boundary within which all Scrum components are exercised and come to life.

The Scrum team gains technical and business domain knowledge rapidly in sprints through collaboration and continuous learning. This enables team ownership and sharing as team dynamics quickly emerge and stabilize. The ScrumMaster ensures that Scrum rules, principles, values, and practices are upheld throughout the Scrum project life cycle.

Heart of Scrum

Jeff Sutherland and Ken Schwaber have referred to the sprint as the "heart of Scrum" in their recent guide on Scrum, released in July 2013. While that is true, the sprint goal provides the necessary alignment in a sprint. For the sprint to be of value, the product backlog has to be prioritized, refined, elaborated, and constantly groomed top-down to ensure that high-value items are ready for selection in a sprint. Thus, the product backlog is at the heart of Scrum, where creative concepts lead to delivery of innovative products. The sprint backlog supplies the necessary fuel for the sprint to achieve the goal.

What is a timebox?

A timebox is a maximum duration that has a specific purpose to achieve, as well as duration, scope, and an agenda to meet the desired purpose. In Scrum, a timebox is the maximum duration within which the Scrum team hopes to achieve the defined purpose. If the purpose is achieved earlier, then the timeboxed ceremony ends early. Timeboxes provide control by allowing the Scrum team to be self-managing, self-organizing, collaborative, and aligned to accomplish the purpose of the timeboxed ceremony.

Scrum has five timeboxes: the sprint, sprint planning, the Daily Scrum, the sprint review, and the sprint retrospective. Release planning (optional) is not realized as a timebox. Besides, release planning without an inspect-and-adapt ability at the release level leads to an incomplete PDCA cycle. The sprint provides two PDCA cycles to cover product and process.

How the sprint is more than just a timebox

Sprints have a defined, constant duration for the project. For a project, all sprints have the same duration. The sprint is a timebox of a month or less. Sprints have a start date and an end date. All Scrum timeboxes except the sprint are closed as soon as their purpose is achieved. However, a sprint cannot be closed early unless it is canceled or is the last sprint for the product. Only the product owner can decide whether a sprint can be canceled. No other Scrum timebox can be canceled by anyone in Scrum. Product owners cancel a sprint only when it is identified that the sprint goal is obsolete. This is rare, as it is a traumatic event for the team.

On the other hand, a sprint is not closed when the sprint goal is achieved early. The team collaborates with the product owner to seek other backlog items that can be taken up in the remaining duration. The sprint goal cannot be changed within a sprint. For more details on these characteristics, and additional details, check my blog: Sprint is more than a timebox.


A sprint provides the basic wireframe structure within which Scrum is practiced. The Scrum team collaborates and learns rapidly to inspect and adapt in an ongoing fashion. The Scrum process enables transparency for further inspection and adaptation. The sprint ensures that continuous improvement is undertaken for the product and process improvements simultaneously. The Scrum framework is wonderful in the way it works. It enables highest-value delivery while allowing the Scrum team to collaborate and address uncertainties and risks.

The sprint is an essential building block of Scrum. The artifacts enable transparency throughout the process. The Scrum team starts from the prioritized and refined product backlog to build the sprint backlog and builds the product increment within the boundary of a sprint.

Being a good teammate is when you try to sprint down a ball that everyone thinks is going out of bounds. But you go after it anyways, and you get it. -- Mia Hamm

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4.8 (13 ratings)


Tim Baffa, CSM, 5/13/2014 11:27:04 AM
Good information in the article. My only comment would be about team activity when a sprint goal is achieved early. This is assuming that feedback from the PO and stakeholders was positive for the working software produced, and there were no issues (why wait for the Sprint Review to solicit feedback?).

One area that the team should consider in their Sprint Retrospective is their underestimation of either their overall team productivity or user story size. Good opportunity there for the team to consider items for improvement.

Personally, I would not advocate having a team accept any additional work into a sprint in the event they finish early. The purpose of Sprint Planning Part 2 is for the team to define the scope and goal for the iteration, setting expectations not only within the team but also with the PO and stakeholders. I would not try to change this dynamic at all.

Instead, I feel that the team's time would be much better spent in either refinement exercises or in learning endeavors.

In my mind, there is so much long-term benefit to allowing a team member to learn and grow as a more valuable resource to the organization by gaining knowledge, as opposed to the short-term gains that may or may not be achieved by trying to complete unplanned user stories to fill the time gap in a sprint.
Jai Singhal, CSP,CSM,CSPO, 5/15/2014 7:13:03 AM
Tim, you share an interesting perspective. The point is that Sprint is not treated as normal timebox.

A simple response to what to do if Sprint goal achieved is addressed in Agile Manifesto principle #1: "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." I have addressed it in detail in my next article.
Tim Baffa, CSM, 5/15/2014 9:23:05 AM
Jai, you mention in your blog that any extra capacity within a sprint can be used for "Spikes, Refactoring, integration, hardening, and innovative aspects". I would add training, education, and knowledge transfer initiatives in this statement, and then we are in complete agreement.

I would still maintain that in Scrum, we want to maintain the purpose of Sprint Planning Part 2, and coach against adding any additional complexity and unpredictability to what appears to be a very successful sprint by suggesting that the team work with the PO to see what additional items can be worked on. Effort estimation for the item, task breakdown, and team capacity calculation all seem to be wasteful activities with this approach, and places a sprint where all items satisfy DoD into risk if a team does not complete an additional item according to the DoD by the end of the sprint.

In my mind, a main goal of Scrum is to reduce complexity and add predictability to the software development process. Adding items mid-sprint seems to work against this goal.

If the Sprint Goal
Jai Singhal, CSP,CSM,CSPO, 5/15/2014 10:41:51 AM
Tim, It could very well be. The guide at provides clarity as to what occurs in the remaining time in this case.

The Scrum Guide* clearly states, "If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint."

Scrum Team is self-organizing. As an Agile Coach, I discourage Scrum Masters trying to impose their ideas on the Development Team and the Product Owners. It's all about "individuals and interactions" and "customer collaboration."

You raised some additional points. Empirical process control theory asserts that experience provides knowledge and the decisions are then made based on the what is learned.

*Note: Scrum Guide is a trademark of Ken Schwaber and Jeff Sutherland. Reference: Guides/2013/Scrum-Guide.pdf
Tim Baffa, CSM, 5/15/2014 12:44:11 PM

Not to belabor the point, since I think we're on the same page. My last comment refers to the quote from the Scrum Guide you cited.

It seems to me to pertain specifically to the work accepted by the team in Sprint Planning Part 2, and offers a recourse to the team and PO if the scope of the work accepted changes mid-sprint. It does not make a suggestion in the event that the team either over-estimates or under-estimates their capacity or productivity.

In all likelihood, the Team/PO negotiation would occur when the scope increases due to unforeseen circumstances. On the rare occasions when the scope turns out actually less than the team planned for, I would maintain that the extra time would be better spent by the team in refactoring, training, and education.

In the more likely scenario where the scope actually doesn't change, but the team underestimates their productivity, I would also recommend activities to improve both the team and individual proficiencies over identifying additional work to accept.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up