Failed Sprint?

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.

One of the options is cancelling the Sprint.

Scrum is an Iterative and incremental development.
If it occurs, a new Sprint would start immediately.
The cost is lower than waterfall developmenmt process.

When a Sprint is cancelled, if part of the work is potentially releasable, the Product Owner typically accepts it.

One of the options is cancelling the Sprint.

Cancelling the Sprint looks as not a good solution. The Scrum Guide tells the following:
A Sprint would be cancelled if the Sprint Goal becomes obsolete.
However, the Sprint Goal is not obsolete, but just requires a bit more work to reach it.

A "failed" Sprint is one where the Goal has not been achieved. The most important consideration is how failure is controlled.

If the Goal becomes obsolete, and the Sprint is cancelled, then a "fail early fail fast" model has been applied. Control of the situation, including the minimization of wasted effort, can thereby be evidenced.

On the other hand, if the Sprint Goal is not achieved and this problem only becomes apparent at the end of the Sprint timebox, then a greater level of waste has been incurred, and there is less evidence of control.

I have been wondering about the term "obsolete". As far as I understand it (and the following sentences in the Scrum Guide) it does *not* include "unattainable". So if a team learns that it can no longer reach the Sprint Goal with the current plan (Sprint Backlog), then the Scrum Master would coach them to look for an alternative plan to reach the Sprint Goal. If they do not find such a plan, then my understanding is that this would not be a reason to cancel the Sprint. Instead, the team would keep working to get as close to the Sprint Goal as possible while accepting that they will fail the Sprint. The Sprint Goal is never changed during a Sprint.

Correct...? Or am I on a wrong track here?

I think it's demotivating to reach for a goal you can't reach. As a Scrum Master I would motivate the team to reacht the sprint goal (whatever means nessicary) or simply challenge them to reach the goal. If the goal seems unreachable adjust the sprint goal, but only if it is blocked by an impediment that isn't going to be solved this sprint.

Posted By Christian Geyer on 04 Sep 2015 03:55 AM
Instead, the team would keep working to get as close to the Sprint Goal as possible while accepting that they will fail the Sprint. The Sprint Goal is never changed during a Sprint.

Correct...? Or am I on a wrong track here?

100% agree!

The first step for DT is to collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint. The PO could help to prioritize the work to do to get as close to the Sprint Goal as possible.

The worst result is to cancel the Sprint. I just want to emphasize that eventhough a Sprint is cancelled, the cost is lower than waterfall process.
The team members just do their best to meet the Sprint Goal. If it occured, they could learning something during the Sprint Retrospective.

“Fail” is a very powerful word and I don’t think it’s appropriate for this context.

If a Sprint Goal cannot be achieved, the Development Team should discuss this with the Product Owner. Between them they should collaborate to understand the situation and see if the goal can practically be re-scoped.

Let’s say the goal is “Users can register and login to our site” and 50% through the Sprint it is apparent that this cannot be done in this timebox — it’s simply too much work, there was a surprise problem, Fred’s caught the flu, whatever the reason.

The Dev Team and PO could agree to focus only on the user registration aspects (i.e. the goal becomes “Users can register for the site”), and login could be done in a future Sprint.

As others have said, the goal is absolutely not obsolete in this case, but as more has been learnt it has become apparent that it was overly ambitious.

I wouldn’t suggest the team or the Sprint has “failed”. Software Development is Complex and to call every surprise [or learning] a “failure” will destroy team morale. If you cancel a Sprint every time something doesn’t go to plan then you risk never completing a Sprint.

There is arguably also a lesson to be learnt with the type/style of goal being set — are they too specific and thus not factoring in the complex nature of the task at hand?

As you point out, Mikhail, "sprint failure" is not prescribed in scrum. So, I see it as something that is completely fluid for an organization: you can define it or not, you can attach it to rewards or not, you can change it over time or across teams. What is the most important (especially, as Ramsay identifies, since "failure" is a strong word) is not to focus on the idea that "you did poorly and failed," but on "what can we do better next sprint?" As they say, mistakes are good to make, as long as they are new mistakes.

Allow me to share my thoughts...

I've never come across a "failed Sprint" concept in the Scrum Guide, nor do I ever use this terminology.

I have worked as a Product Owner, Scrum Master, growing into a Coach -- Sprints don't "fail."

Perhaps it is around semantics or verbiage, but this is a very powerful word. Don't get me wrong -- when things don't go the way expected, it is best to acknowledge them, be transparent and be willing to address the root causes, as and if needed.

I have worked with Team members right up to the CTO, and again, have never used this terminology.

Posted By Nitin Khanna on 04 Sep 2015 02:35 PM
I have worked with Team members right up to the CTO, and again, have never used this terminology.

I could not agree with you any more.

The value of a Sprint includes customer value and knowledge value.

Success or Fail?
It depends on various point of view.
To embrace Scrum, inspect the progress and adapt to meet to the Sprint Goal, inspect the outcome and adapt to approach improvement.
It's a learning path to succeed.
The learning cost of from a Sprint is much lower than that from a whole project.

> If they do not find such a plan, then my
> understanding is that this would not be a
> reason to cancel the Sprint. Instead, the team
> would keep working to get as close to the
> Sprint Goal as possible while accepting that
> they will fail the Sprint.

No sprint should be a death march. If it is clear that the Goal cannot be met then it is obsolete for the purposes of that Sprint, and the Sprint ought to be cancelled.

A Development Team should not pursue an unattainable Goal since the risk of wasted effort then becomes high.

The remainder of a cancelled Sprint timebox should be used to plan and achieve a more realistic Goal. The team should try to extract as much value out of the work done as possible. The problems that have occurred must be addressed and resolved in the Sprint Retrospective, as the agreement of an unattainable Goal represents a serious material defect in the application of Scrum.

> I have worked as a Product Owner, Scrum
> Master, growing into a Coach -- Sprints don't "fail." 

I remember holding a similar perspective at school. I told my science teacher that no experiment could ever really fail, because at the very least data might be obtained that would help to advance knowledge. Regrettably, I failed in my experiment to convince him of this.

Regarding Scrum, I am also reluctant to speak of sprint "failure", because I don't think that sort of language is particularly helpful. Nevertheless I think it's important to know what sprint failure means, because without that we cannot understand what a successful sprint would mean.

I believe that if a Sprint Goal frames our understanding of what a successful Sprint should look like, we should also expect to observe any "failed" sprint through the same lens.

Wait a second guys.

Don’t we have an empiric process? Don’t we want to inspect and adapt also during a sprint?
Have we not learned, that the future (also near future) is unpredictable?
Isn’t it the purpose of the daily scrum to inspect progress towards the sprint goal and if we see we will not reach it, adapt the Sprint Backlog (in collaboration with the PO) and maybe also the Sprint Goal?

I think, we have to distinguish.
1. We will not reach the ‘full’ sprint goal in time but we will reach a big part of it.
In such a case I would adapt the Sprint Backlog and maybe the sprint goal.
And plan the rest of the work for the next sprint.
2. We have found big issues in reaching this sprint goal and we now know it will take much longer.
This might be a reason for cancelling a sprint.

But in my eyes cancelling a sprint for educational reasons is far too tough. We would need to set up new Sprint meetings on very short notice and I don’t think this is very efficient. Also I think it is very demotivating.
Also: If we have worked on the goal for 2 weeks until we found out, we will not reach it, within the newly planned sprint (another 4 weeks) we will easily reach it. So this might seem like a cool practice ;)

The Scrum Guide says that progress toward a Sprint Goal is inspected to detect undesirable variances. It also says that the Sprint Backlog can be adapted in order to meet the Goal, and that the Daily Scrum is an inspect and adapt meeting for progressing towards the Goal.

A Sprint Goal may therefore be seen as an immutable point of reference around which inspection and adaptation can occur during that Sprint. If the Goal is itself mutable then this process of inspection and adaptation will be compromised, and the rules of Scrum are no longer being observed.

You have indeed got a point here @Ian.
Such a Sprint should for sure not be understood as normal and successful. And reasons need to be addressed in Retrospective.

However, I would not go as far as canceling the Sprint.
Unless PO decides, that this goal becomes less important (and therefore obsolete for now) because it takes more time to deliver it.

> Unless PO decides, that this goal becomes less important (and therefore obsolete for now) because
> it takes more time to deliver it.

Until very recently there was a question in one of the open assessments for which the right answer was that only the PO could cancel a Sprint. If I recall correctly the reasoning was that a PO could cancel a sprint if he or she decided it made no sense to finish it.

Now the correct answer has changed, and cancellation is considered to be a matter of sprint goal obsolescence.

The two answers are not necessarily incompatible. Based on this evidence I would hold that a Sprint Goal becomes obsolete when the Product Owner determines that it has become so. Cancellation of the Sprint may then occur at the Product Owner's discretion.

There is an awful lot of talk about meeting or not meeting the Sprint Goal determining whether a sprint is failed or not. I do believe that the Sprint Goal is important, but I feel like we are missing the point here a little. A couple of things I like to stress with teams I work with: 1) The items that the team signs up for and commits to during the sprint planning is their main priority; 2) The Sprint Goal is there to help give focus to the team. To cancel/abort a sprint, the team, through a mutual decision with the Product Owner, determined that the items they had signed up for are no longer the highest priority things to do... Now about the topic of Failed Sprint... I tend to agree with the comments above that calling a sprint "Failed" is probably too strong... now, it is possible to fail to complete all the items in the sprint backlog... but, in my opinion, no sprint is "Failed".

> The items that the team signs up for and
> commits to during the sprint planning is their
> main priority

In the most recent version of the Scrum Guide the team does not commit to backlog items. Rather, the selected items represent a forecast of the work that will be needed to meet the Sprint Goal. It is the Goal, and not the forecast of items, that has the priority.

Firstly, who can cancel the Sprint? Who has the authority within Scrum guidelines? According for the latest guide, it clearly states that "only the Product Owner has the authority to cancel the Sprint", however, in "Agile Project Management with Scrum" Ken Schwaber writes that "If the Sprint proves to be not viable, the ScrumMaster can abnormally terminate the Sprint".

Which is the canonical version? Does this represent a shift in authority since '09 when the book was written?

Secondly, what is the rationale for focusing on Sprint Goal above the selected items. It seems to me that it diverts the attention away from the concrete (requirements, user stories, business needs, ROI) to the abstract (akin to the, mostly hated, "mission statements" of companies). It also requires a lot of cohesion from the selected items (not necessarily bad, just mostly unrealistic) if they need to be summarized in a single Goal without the Goal reducing to something generic like "our goal is delivering this functionality as per spec". Isn't the selection of Product Backlog items a commitment enough?

> Firstly, who can cancel the Sprint? Who has
> the authority within Scrum guidelines?

This topic was considered earlier this year in the following thread:

https://www.scrum.org/Forums/aft/1345

> Secondly, what is the rationale for focusing
> on Sprint Goal above the selected items.

Without an overarching and overriding goal, no risk or opportunity can be addressed which is larger than a single backlog item. Scrum articulates such goals on cadence each and every Sprint. A corresponding increment of value can then be delivered.

> Isn't the selection of Product Backlog items a
> commitment enough?

In predictable environments it may be reasonable to focus on individual items that are in progress and commit to their delivery. Certain Kanban implementations work this way...there are no Sprint Goals and therefore no need for Sprints. Work is drawn from a backlog and handled through continuous delivery.

Scrum however is designed for conditions of greater uncertainty, where the abstract must be made more concrete within a Sprint. This requires a flexible Sprint Backlog and the ability to replan as discoveries are made.

In predictable environments it may be reasonable to focus on individual items that are in progress and commit to their delivery. Certain Kanban implementations work this way...there are no Sprint Goals and therefore no need for Sprints. Work is drawn from a backlog and handled through continuous delivery.

Scrum however is designed for conditions of greater uncertainty, where the abstract must be made more concrete within a Sprint. This requires a flexible Sprint Backlog and the ability to replan as discoveries are made.

This actually confused me a bit. I totally agree with Scrum being more suited to uncertainty, but I understood the whole basis of Scrum to be founded on the near-immutability of the Product Backlog commitment for a Sprint. The Sprint Backlog, on the other hand, which represents the realization plan of the committed portion of the Product Backlog, is very much changeable and a living artifact.

So, for example, if a Sprint is committed to delivering a new piece of functionality plus a set of bug fixes, it seems fundamental to me that:
- no new piece of functionality may be "snuck in" into the Sprint
- no additional bug fixes from the Product Backlog may be inserted into the Sprint
- if new bugs are discovered, PO and DT need to decide if those would impact the delivery of the committed functionality and, consequently, if they are to be included as part of the current Sprint Backlog or, if unconnected to current Sprint, put on the waiting list of the Product Backlog
- if the circumstances change dramatically due to the said uncertainty, the Sprint may be aborted, with the advantage that it would fail early and at minimal cost, to realign the course

Is my understanding wrong at any point?

> I understood the whole basis of Scrum to be founded
> on the near-immutability of the Product Backlog
> commitment for a Sprint. The Sprint Backlog, on the
> other hand, which represents the realization plan
> of the committed portion of the Product Backlog, is
> very much changeable and a living artifact.

The Scrum Guide says: "The Sprint Backlog is the set of Product Backlog Items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a 'Done' Increment".

Therefore it can be seen that the Sprint Backlog is not merely the realization plan; it is also the selected Product Backlog Items. Moreover the Sprint Backlog, including those selected items, is a *forecast* and not a commitment. It can be argued that it is in fact the Sprint Goal that represents a "commitment" of sorts. The Sprint Backlog, including the selected items, is in no sense immutable and it should be expected to change during a Sprint while the team is in pursuit of the Goal.

> So, for example, if a Sprint is committed to delivering
> a new piece of functionality plus a set of bug fixes,
> it seems fundamental to me that:
> - no new piece of functionality may be "snuck in" into
> the Sprint

Correct. The new work could only be admitted with the joint agreement of the Product Owner and the Development Team, and it should not put the Sprint Goal at risk.

> - no additional bug fixes from the Product Backlog may be
> inserted into the Sprint

No. The team can agree to introduce those fixes if either (a) it does not threaten the Sprint Goal or (b) it improves the team's ability to meet it.

> - if new bugs are discovered, PO and DT need to decide if
> those would impact the delivery of the committed
> functionality and, consequently, if they are to be
> included as part of the current Sprint Backlog or, if
> unconnected to current Sprint, put on the waiting list
> of the Product Backlog

Correct, with the observation that the functionality is a forecast of what is needed to meet the Sprint Goal and not a commitment. It may be necessary to remove certain planned items from the Sprint Backlog in order to accommodate these changes while still allowing the Goal to be met. This is a matter of negotiation between the PO and the Development Team.

> - if the circumstances change dramatically due to the
> said uncertainty, the Sprint may be aborted, with the
> advantage that it would fail early and at minimal cost,
> to realign the course

Correct.

Hi,
Per scrum guide, a sprint can be cancelled if the sprint goal becomes obsolete. However obsolete does not mean unattainable. Dictionary meaning of obsolete is outdated, something which will not serve a purpose because of market/technology conditions. That is not the case here. Functionality being developed indeed is needed. The case here is that not all what was planned is going to be completed.

Per scrum guide, sprint goal provides guidance to the team why it is building an increment. The goal gives some flexibility to the development team regarding the functionality implemented within sprint and so I think that it comes down to the goal which is chosen. Could a careful selection/wording of goal help in avoiding a situation where goal is not achievable even with scope change?

On the other hand, I have a difficulty in understanding that sprint goal cannot be changed but scope can be changed. Isn't scope a more detailed breakdown of activities of attaining the goal? Can someone please give some examples where scope is changed but not the goal? To me, all scoped items should be reflected in the goal unless goal is high level/generic which does not get impacted even if some items are de-scoped? If so, I would say that situation will not arise that development team will not reach the goal even after changing the scope.

Can someone please give some examples where scope is changed but not the goal?

As a very simple example

Sprint Goal: Allow easy ‘1-click’ sharing of news pages on social media platforms

PBI 1: As a User I want to be able to share on Facebook so that…
PBI 2: As I user I want to be able to tweet a link to a page on Twitter so that…
PBI 3: As a user I want to be able to share a page on LinkedIn so that…

In this instance perhaps PBI 1 & 2 prove harder than expected, and consequently PBI 3 is de-scoped entirely. Sprint Goal still achieved as it is vague but still serves to provide guidance to the development team on why it is building the increment and helps the team to work together, rather than on separate initiatives.


To me, the goal is more about alignment and giving the team direction and encouragement to work together than it is a milestone in its own right. The goal could be to share on Facebook, Twitter and LinkedIn, but if anything this could encourage team members to work on separate streams as the goal has three distinct parts.

Thanks Ramsay. That was my thought as well that goal is vague/high level which provides guidance to the team why it is building the increment but gives flexibility to development team to remove some PBIs, if needed, without impacting that goal.

That being the case, I doubt that sprint cancellation would be required for not able to complete the PBIs planned. One should be able to drop some PBIs without impacting the goal and delivering a valid increment.

Hi,
I was reading the material from management plaza which has given 2 examples of goals which are pretty high level goals and not tied to specific features etc eg

'We are going to enable all the essential parts of ecommerce, to make other features of the website more meaningful to the customer'

OR
'We are going to improve our relationship with the customer this Sprint and use it to facilitate the progress of the project'

The wordings of the goal is such that it is giving guidance to the development team why it is building the product without detailing all the features to be built. That being the case, one should be able to achieve the goal even if some PBIs are not completed and so to me, situation of cancelling a Sprint should not arise as goal not met because some PBIs are not DONE.h

Hello there,

Can you please help me understand a hypothetical situation if there is nothing complete as per the definition of 'Done', should the sprint review will be cancelled as there is nothing to showcase to stakeholders? 

Thanks/

should the sprint review will be cancelled as there is nothing to showcase to stakeholders?

Is there nothing in the Product Backlog which is subject to inspection and adaptation?

Rajesh,

My advice to you is to read the Sprint Review section of the Scrum Guide.   

There are 8 bullet points that highlight what should be discussed in the Sprint Review.   Demonstrating functionality to stakeholders is only one part of the Sprint Review agenda.

Is there no value in showing what ever portion of the work you have finished in order to get feedback? 

@Timothy Baffa's advice is the best you will get.  There is much more to the Sprint Review than just showing done work. 

I agree with the above points about the purpose of the Sprint Review, but I would add that if you ever run into a situation where a Sprint Review is perceived to add no value, stubbornly persisting with that event might not help.

It's more likely to alienate the same stakeholders you need feedback and insights from.

It all depends on the relationship between a Scrum Team and its stakeholders, but if you have literally just been using the Sprint Review as a demo, turning up without the expected increment and asking stakeholders to provide feedback from the market without preparing them first, could undermine any future attempts to improve the Sprint Review.

It might be prudent to cancel this one Sprint Review, but resolve to work with the Scrum Team and stakeholders to improve the next one.

I'm going to back up on this question and just look at words and the feelings they evoke.



"Failed" is subjective. It's such a potent word, and everyone interprets it to their own views. I used to use it, but I don't anymore, even in personal life. From my observations, using it can easily instill a panic, especially in stakeholders... it's unnecessary.



If you set a realistic goal to lose 10 lbs in two months with true integrity but you only lose 2 lbs, that's not failure. You just didn't meet your goal. Don't beat yourself up. You just learned something about yourself or team and can adjust into the future.



Go Forward > Hit wall > Move aside from wall > Go Forward > Repeat

We had a similar situation where mid-way through the team, the tech team has a design review with the Engineering manager and realizes they need to change the technology stack they were using because of challenges with existing tech that they had not thought about.

Rather than calling it a sprint failure, we decided to spend the rest of the sprint in creating design with the new technology and grooming the feature in to new user stories that could be worked on starting with the new sprint.

In our case, the user stories were all tech development related so though we kept the PO in the loop, the decision to change the acceptance criteria on sprint user stories rested with the team. We did this so we could close out the user stories and use them as analysis stories. Even though the sprint goal fell way short but the work done in the sprint was very helpful for future dev as well as directing change in our processes.

Btw, doing a focused level retrospective to understand what we could do to ensure a repeat of this is a must. In our case, we made review of tech design with the engineering manager a must, brought in Spike user stories in the sprint before the dev work started and it certainly helped.