Sacredness of the Sprint

Here is another excerpt from our upcoming Agile textbook.  This is a topic that I am particularly passionate about!

No Changes to the Sprint

One of the most importance cultural changes related to Agile adoption is adhering to the sacredness of the sprint.  What does this mean?  It means that once a sprint goal is committed to, there should be no changes to that goal.  sprint_sacred.jpgThe group that has the hardest time adhering to this is upper management.  There is always some crises or customer request or great idea that an executive wants the team to investigate immediately and there is a tendency for executives to pull the team off of their sprint commitment to work on the latest critical task.  The companies that allow this type of distraction have the most difficult time adopting Agile.  The companies that stand firm and honor their sprint commitments tend to be more successful in their adoptions over all.  Truly, it is a sign of executive commitment to the process and the methodology if they honor this one aspect.

Mike Cohn, in his book Succeeding with Agile, is very firm on this issue. “Nothing is allowed to change within the sprint. The team commits to a set of work on the first day and then expects its priorities to remain unchanged for the length of the sprint. “ (2010, pg 279)

Any exceptions?

Are there instances where the sprint must be interrupted?  Absolutely.  If one of your production servers goes down and your developers need to restore the system, then that is clearly a priority over new development.  If you are under attack from hackers (like a DDoS attack) then the developers may need to work on an immediate patch.  Those situations notwithstanding, there are many more instances where the “crises” can and should wait while the team works on their current sprint commitment.

Honor the Commitment

We learned a great lesson at a company who was rolling out Agile in this regard.  Like many companies, this one had a handful of customers who drove the most volumes and revenue.  When the Agile implementation was underway, the question arose, “What if one of our largest customers wants an enhancement and we are in the middle of a sprint?  Shouldn’t we stop what we are doing to handle their request and ensure their satisfaction since they are such an important customer?”  When working in the Waterfall method, that is exactly what they did; stopped everything in progress to deal with the ‘urgent’ request.  How could they handle this now that they had implemented Scrum?  What they discovered was very interesting.  Typically, when a customer comes to a development team and wants something urgently, they usually have not fully thought through all of the details.  Would this feature be refunded if the end user wasn’t satisfied?  Could the order be placed by a customer service representative or could orders only come through on the web?  Are we going to offer this feature in Canada?  Globally?  Does that introduce currency exchange and multiple language scenarios?  To answer these questions, the Product Owner and the account management team can work with the customer to flush out the details of the request.  And that process normally takes — two or more weeks.  Therefore, the request could be prioritized at the top of the backlog for the next sprint without disrupting the Sprint that is currently in process and we are able to honor our sprint commitment.

Again, this isn’t always possible.  Certain crises necessitate the abandonment of the sprint goal.  But as a rule, the Sprint should NOT be impacted if at all possible.  This allows the team to feel more confident in their ability to deliver and it increases the trust and teamwork across the organization.  This is also where having an executive sponsor the Agile implementation can make a tremendous difference.  That executive should have the power and conviction to keep their fellow executives in line so the sacredness of the Sprint can remain intact.

2 Responses to Sacredness of the Sprint

  1. Luis Eduardo Colon says:

    The interruption of a sprint is a symptom of business and IT not respecting commitments. Sprints and group activities should organically handle emergencies, bugs and debt, and then strive to make commitments that can be always achieved regardless of unplanned events. In my experience, it is better to experiment with different sprint lengths rather than discard a commitment because of an “emergency”. Commitment breeds discipline, predictability, and improves the trust between Business and IT.

  2. Great post, and one that is worth heeding. Only once did we break a sprint, and it was for a very good reason (line down, SHTF situation).

    One of the toughest part of my role as product manager / product owner was keeping the senior staff from messing with the team mid-sprint. They just don’t like being told “no”, but it is the right thing to do. The other tireless chore was communicating that “agile” doesn’t mean get more done faster to the execs. They never cottoned on tot he idea that it was more about maintaining development velocity, and being able to respond quickly to changes in the market landscape. Then being told that they couldn’t send the team on a wild goose chase at a moment’s notice was too much for them.

Leave a Reply

Your email address will not be published. Required fields are marked *