What Happens When a Sprint Goal Is Attained Early?

6 June 2014

Jai Singhal
Agiliants


Introduction

I wrote an email back in 2009 about why ScrumMasters should be discouraged from forcing their preferences on the development team and the product owner when the sprint goal is achieved before the sprint expires. It was actually triggered based on feedback from development team members who were upset that the ScrumMaster was asking them to function in a specific way. I wish I had kept that email around, as it is becoming a hot topic!

Foundation of Scrum

Empirical process control theory is the foundation of Scrum. Empirical process control theory asserts that experience provides knowledge and that decisions are then made based on what is learned. Scrum is most effective in a complex domain context where there are unknowns and uncertainties. As more is learned about the unknowns, the Scrum team uses the knowledge and information gained to take necessary steps to achieve the sprint goal. This is like driving a car on a new route, without navigators or even detailed maps. The only insight could be an approximate route based on various references, distance, a general idea about the highways and exits to take, some landmarks, and how long it could take to reach the destination. As we drive for each hour on the route, we use various checkpoints to ascertain whether we are on the right path. Perhaps we reach the destination on time, perhaps early, late, or we even get lost during our travels -- and we make corrections as more information is revealed. As we gain more knowledge and experience, we make better decisions.

Estimated team velocity

Estimated team velocity is just what it states. It is an approximate capacity that the team thinks it can deliver in a sprint. The work effort for each backlog item is estimated in the product backlog. During the first half of sprint planning, the product owner discusses each backlog item from the top as the development team selects it for the sprint, based on a rough estimate. Once sufficient backlog items have been selected, the development team identifies and owns various work activities or tasks required to complete the backlog items. A sprint goal is set. The development team commits to this sprint goal. The product owner agrees with the sprint goal and backlog items. The game is on!

The Scrum team employs empirical process control to work toward the goal. The three pillars of empirical process control are transparency, inspection, and adaptation. Scrum enables us to make the complete process visible at all times. This enables inspection and adaptation. Yet it requires intelligence, motivation, good collaboration, and some luck in getting to the sprint goal. The three pillars don't guarantee success. Hence we hear the phrase, "Scrum is not a silver bullet."

Another important aspect is the Agile Manifesto -- it is all about "individuals and interactions" as being of higher value than "processes and tools." The Scrum process is no exception. If Scrum is used with little or no interaction and collaboration, it would be ineffective in yielding remarkable results.

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 the sprint backlog within the sprint." The development team collaborates with the product owner throughout the product development.

When the sprint goal is achieved on time

Some consider that it was a good estimate that the Scrum team met its goal just in time. In the beginning of project, Scrum teams normally have more unknowns, new domain, little or no business domain knowledge, and new team configuration. As the individuals are just learning to interact and are learning about their roles and Scrum rules, values, and practices, a lot is at risk. When the Scrum team achieves the sprint goal with consistent velocity, we hope that it is not due to lowered expectations because the bar was set so low that it was easy to achieve. This does not foster motivation, self-organizing, and collaboration for the Scrum team. A challenge is motivating. A motivated, self-organized, dedicated, and cross-functional team loves challenges. It has been observed that achieving the sprint goal just in time becomes a norm for an advanced Scrum team.

When the Sprint goal is not achieved within the sprint

When the Sprint goal is not achieved within the sprint, the development team discusses various impediments and events of the sprint that contributed to this factor. In fact, as soon as the development team becomes aware of the situation, its members work with the product owner. The product owner holds the ability to cancel the sprint if not enough value is gained. This is rare. Normally, if only 75 to 80 percent of the work is identified, the product owner collaborates with the development team. So, for same cost invested, lower value could be accepted.

When the sprint goal is achieved before the sprint ends

This is where most prevailing practices are off track. The development team continues to review completed backlog items with the product owner. As these items are found to meet the definition of Done (DoD), they are considered done. When the sprint goal is achieved early, the development team should identify the situation to the product owner. This helps in optimizing the remaining time for maximum value delivery (see Agile Manifesto principle #1). The product owner is also keeping track, due to the visibility of the process, and keeps the product backlog refined and prioritized. As a backlog item is completed, stakeholders may identify new stories, enhancements that would promote higher value. This enables the product owner and the development team to collaborate on maximizing value. The top items of the product backlog are considered to see whether the development team can take one (or some) of them on for the remaining time of the sprint. If not enough time exists, the time could be well spent on activities such as backlog refinement, estimating, discovering unknowns and uncertainties, managing risks, etc.

What is not done during this time is a long list, and it is important to know too. The development team does not spend time learning or attending classes when it could deliver a priority backlog item. The ScrumMaster does not enforce his or her ideas unless asked. The Scrum team is self-organizing and cross-functional. The development team collaborates with the product owner. Customer collaboration is valued more highly than contract negotiation, as agreed during the sprint planning ceremony. This list is long too, and it is tested against the Agile Manifesto and its 12 principles.


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.4 (8 ratings)

Comments

Hesham Amin, CSM, 6/9/2014 1:15:39 AM
The remaining sprint time can also be used to manage technical debt, automation, fix bugs left from the DoD.
I'm not sure why the PO should cancel the sprint in case of failing to deliver the sprint goal.
Jai Singhal, CSP,CSM,CSPO, 6/10/2014 10:50:24 AM
Hesham, Technical debt is highly undesirable and should be avoided as early as possible.

Cancelling a Sprint is discussed in detail in the latest Scrum Guide* Published in July 2013 https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf
Product Owner can cancel a Sprint if the Sprint does not yield enough value. Scrum allows risk to be limited to a Sprint length. However, it is intelligence to stop once you know that the project has gone downhill.

*Note: Scrum Guide is a trademark of Ken Schwaber and Jeff Sutherland.

You must Login or Signup to comment.