Sprint Goal will not be achieved. Should I cancel the sprint or not?

As per the scrum guide: 

A Sprint could be cancelled if the Sprint Goal becomes obsolete. Only the Product Owner has the authority to cancel the Sprint.

 

The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

 

The moment a Product Backlog item meets the Definition of Done, an Increment is born.

Although an increment is born after one PBI has met the DoD, I would question why the sprint only has one PBI in the first place.  Question the team on whether they believe the PBI could be broken down into smaller PBIs which still create value. 

I find this situation quite unusual.

It could be reasonable that the Sprint Goal is tied to a single Product Backlog Item, the fact that there is only one Product Backlog Item selected for the Sprint is a bit unusual. That seems to indicate that the team has refined that Product Backlog Item and determined that completing it would take the entire team a full Sprint - a very unusual case. In most cases, the work can more easily be broken down and divided into smaller pieces. Having smaller Product Backlog Items can help the negotiation between the Developers and Product Owner during Sprint Planning to find the right balance between the Sprint Goal, which Product Backlog Items support the Sprint Goal, and how many Product Backlog Items to pull into the Sprint.

I also find it unusual that on the second day, the Developers have determined that they can't achieve the Sprint Goal. There should be plenty of time to take a look at the Sprint Goal and find ways to achieve it.

I'm curious as to what the Sprint Goal and definition of the Product Backlog Item are, since I don't think I've seen a case like this before.

My recommendation is that the team figures out if it's possible to achieve the Sprint Goal without completing the Product Backlog Item and adjust the Sprint Backlog to create a plan to do so. If that isn't the case, then perhaps canceling the Sprint is something that is on the table. Canceling a Sprint is very rare, though, and if you are operating in a scaled context, may not be feasible. Trying to use the remaining days of the Sprint to somehow create a valuable increment may be a better option, but I'd also consider starting the retrospective activities earlier and figuring out how the team got into this situation and preventing it for the future.

Scott, Thomas, thank you.

Let me give you more details about the situation.

It was (supposed to be) the lates sprint, with only one US to be delivered. The story was "Implemenation of Contact Us page".

It was a very simple US, front-end, back-end, tests, etc were possible to be made in a one week sprint. So the team started on day 01. 

On day 03, 2 developers (back-end programmers) got sick and could not work. So, at the Daily the rest of the team talked about the situation and explained that it would be complicated (they meant impossible) to finish the US on time.

In this situation, what should I do, as Scrum Master? 

Note: there were no spare developer available.

Regarding the meaning of obsolete, does it mean "Sprint Goal not valuable anymore" or "Sprint Goal is not reachable until the end of the Sprint" or both and so on?

See ya!

Has the Sprint Goal itself become obsolete? Or is the team just not able to achieve it? These are different. 

If the goal is still valid, there is no reason to cancel the Sprint. Scrum Guide supports this as quoted by Scott above. 

Goal shouldn’t be to finish that 1 PBI but to achieve some value based outcome. What CAN the team do to achieve that outcome? Negotiation time! 

Seems like a great retrospective topic. What can be learned from this Sprint and adapted for the next?

Affirmative, Ryan.

The Sprint Goal did not become obsolete, but the team could not finish due health problems.

They negotiated with the PO. The outcome was to do what they could until the end of that sprint and for the next one, with everyone healthy again, they should finish the unfinished US.

What do you guys think about the PO decision?

It sounds like the Sprint Goal is not obsolete, so I don't think that cancelation is appropriate in this case. A Sprint Goal is only obsolete if it is no longer represents something valuable to stakeholders.

Given that you have a 2-week (10-day) Sprint, having a Sprint Backlog that only contains 1 Product Backlog Item doesn't seem right. My rule of thumb, absent more specific organizational details, is that a Sprint Goal should be achievable within 70% of the Sprint's capacity. It seems like you've achieved that, since the team figured the primary objective would take half the Sprint. However, that doesn't mean that you shouldn't have other work in the Sprint Backlog that, if completed, would add some level of value to stakeholders.

Tying the Sprint Goal to a specific Product Backlog Item also isn't the best approach. The goal should be an outcome, not an output. A Contact Us page is an output. The outcome is an easy way for users to contact the organization. Is there a way to build something that facilitates that with the available people and the remaining ~8 days of the Sprint? Or could the developers who were out sick return in the next few days, leaving enough time to complete the original plan in the Sprint?

Going forward, one recommendation that I have is to improve the ability of the team to be cross-functional. You may have specialists in front-end development, back-end development, testing, database administration, and other skills. These specialists should work to teach the others on the team their skills so that, in a situation like this, you aren't dependent on a couple of people to get a specific piece of work done. Perhaps it will take longer or you may incur some technical debt that needs to be cleaned up later, but you can be more effective at delivering value.

Thomas, thank you again.

...having a Sprint Backlog that only contains 1 Product Backlog Item doesn't seem right.

The thing is that the "About us" page was the last thing to do in this specific project. The last item from the product backlog. Now I understand that the Sprint Goal shoud have been better defined, to not be a output like you said, but an outcome (valuable).

I understand perfectly what you mean about outcome and output, that's something I will show to the Scrum Team. 

Regarding the cross-functional team, I do agree too. Unfortunately, it wasn't our reality at that time.

So if I am understanding you correctly, after this single story is completed, there is no work that will need to be done on the product.  It is going to be unsupported and never touched by your organization again.  Since that is the case, you could have the remaining team members do the work that they need to do in this Sprint and let them move on to their next product team. Then the sick team members can finish the work when they return. 

Yeah, I know that is stupid.  I meant for it to be.  A Product Backlog exists as long as there is work to be done on a product.  If there is no work left to be done, then the product is usually seen as no longer valuable. I'm sure that the Product Owner has other work that has been identified as wanted/needed for the product.  Those ideas should already be represented in the Product Backlog.  So to support @Thomas Owens there should be work in the Product Backlog that could have been pulled into the Sprint that would allow at least one increment of value to be produced.  The Sprint Goal could be adjusted to represent that work instead.  The "Contact Us" page could be moved back to the Product Backlog to be pulled into a future Sprint. 

The way you mention this work being tied to a project makes me wonder how much of the work done in each Sprint was pre-arranged according to a project plan and delivery schedule instead of being incremental value driven to allow for stakeholder feedback as the work is being done. 

Which brings up the point of what have your stakeholders said about the situation?  The Product Owner should have communicated to them in making the decision. After all, the Product Owner represents them and makes decisions based upon their input.

So, at the Daily the rest of the team talked about the situation and explained that it would be complicated (they meant impossible) to finish the US on time.

Two things:

• How were they able to explain this inability to meet their Sprint Goal commitment, given that the forecast only had one item in it? In other words, how was development risk being broken down and visualized? How was it being controlled?
• Why was this problem surfacing in the Daily Scrum? What sort of collaboration, discovery, and resolution happens throughout the working day? Do you think it's adequate?

Hey Daniel, thank you!

In this project the PO and stakeholders planned that the "About us" page should be the last delivery. The maintenance of the project (website) would be done by another team.

 Which brings up the point of what have your stakeholders said about the situation?

Since both developer were sick due the COVID virus and this kind of risk were known by everyone, the stakeholders understood the decision of finishing the "About Us" page work on the next sprint.

Hello, Ian. Thank you too! 

There were a lot of risks envolved in this project: COVID and quantity of developers were two examples. Unfortunately, with 2 developers out, the rest of the team didn't have the skills necessary to finish the job (big fail here, but it was the reality at that moment).

Regarding the risk control, they had some actions prepared, but none of those prepared for the situation mentioned. What happened: lessons learned.

They notified about the sickness on the Daily meeting because it was the first opportunity they had to (their dailies were done everyday on 08:00 AM).

Hi Ícaro, I have two questions.

Has this page even been released? If yes, how was it possible without a contact page? If not, can you tell that it has even been in a "releasable" state? How does it relate to the agile principles?

The second question, what was the goal of this project? Was there a space to experiment and try different ideas? How would you know that a current product goal has been reached?