Is missing the Sprint Goal an automatic 'fail'?

I received the following quote in response to an earlier post about a Dev messaging the Product Owner about a change of plan mid-Sprint that would likely involve missing the Sprint Goal:

I'm troubled with this. Why did the team fail to reach the goal? How come there is room for extra tasks (new goal?) but no discussion of reducing scope? Is the current goal validated to be important and will the new tasks increase the chance of it being reached in the next sprint? Showing UI to stakeholders is nice but it could have been done with mocks/wireframes too. And if it has, then the feedback will anyway be expected, so what's the value of that?

Thanks for the feedback. As with all great feedback, it has made me think a lot, which is always a good thing :)

First, let me point out that at the time the message was posted, the Sprint Goal had not been missed. Rather, the Devs decided it was at risk mid-Sprint and they wanted to make this clear to the PO. In the days leading up to this point, the Devs had expressed concerns as regard meeting the Sprint Goal at Daily Scrum when the PO had been present. So this wasn't a bolt out of the blue, rather an escalation of threat level. This is a subtle but important point. But for this discussion, let's assume it is the end of the Sprint and the goal had not been reached.

In order to respond to you, I imagined the feedback had come from a stakeholder during Sprint Review. Let's say, one of the Devs had opened the meeting by referring to the Sprint Goal (which would be written on the board at the front of the space), had said the words I posted in the thread (but that the Sprint Goal had not been reached) and the CEO had said your words to the group before hearing any further context. What would my response be?

I think my reaction would be that the safety of the space would be under threat and I'd be concerned that the Devs would think that they were being attacked. I must say here that in these Slack channels I think we have a different kind of safety. I think as coaches and - I hope - mentors to each other, we can hold each other to account in a more 'robust' way where good intent is assumed. I coach my the Scrum Teams to show their 'public face' during Sprint Review and to save holding each other to account to the 'private' space we create during the Sprint Retrospective.

So I think my response would be to protect the team in the moment and close the situation down. I'd thank the CEO for their feedback. I'd remind them that during the Sprint Review the team will speak about "what problems it ran into, and how those problems were solved". I'd suggest that by the end of the meeting the context for missing the Sprint Goal would be clearer. Finally, I'd offer to speak with the CEO, and any other stakeholders, at some point after the meeting to address any remaining concerns.

The context for the Sprint Goal being at risk involved some impediments.

The team have recently on-boarded a new person and this is their first full Sprint with this team and this company. We knew this would impact the team but we couldn't know exactly how: we'd have an extra pair of hands but would they would need attention from old hands. Another factor for Sprint Planning was knowing that a Dev would be on holiday for 50% of the Sprint, which is always a challenge as regards ordering of tasks and adjustment of what some teams call 'velocity'. As the old adage goes, "It is difficult to make predictions, especially about the future."

We also had emergent impediments. A team member went off sick for a few days, which always has an impact on ability to deliver and couldn't have been foreseen. Another unforeseen event was the office losing internet access for an entire day: some of us travelled home to work remotely once our IPs had been white-listed but two devs on this team weren't able to work from home and had to make do without full access to systems.

When you refer to extra tasks, I wonder whether there has been some fundamental misunderstanding and if so I must apologise for not making things clear earlier. When the Dev says, "We have identified a number of extra tasks as part of the [redacted] work", they are referring to emergent understanding of the required work.

Here is a quote from my favourite Scrum Book:

"Scrum is an extreme sport and [the Scrum Team] enter into a Sprint with some risks in order to go faster. Their primary risk is emergent requirements" [1]

From the Scrum Guide:

"The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal." [2]

So it is not the case here that the Development Team have taken on new work unrelated to the Sprint Goal, rather they have discovered the normal and expected emergent work directly relating to the Sprint Goal. Either the amount is more than was forecast during Sprint Planning or the impediments resulted in too much lost time to cover the correct forecast.

Note that the Sprint Goals this team sets itself are not of the 'Do these five backlog items' variety. As is my usual approach, I've coached the team (particularly the PO) to encompassing, challenging goals that exist more in the 'problem space' and solutioning is avoided until we get into the Sprint proper. When we leave Sprint Planning, we have agreed that some kind of solution is likely given the time and people's availability but we haven't got detailed designs for every element, we haven't resolved all dependencies, we only have some of the tasks identified and on the board, etc. This is by design and honours the spirit of Scrum.

When the Dev referred to 'prioritising UI changes', they were alluding to vertical slices. Although the team have the mindset of creating product increments each Sprint that are vertical slices, the tasks in the Sprint Backlog have so far been more horizontal. The message from the Dev is that the work completed so far is missing an important element of vertical slice, being the UI. A wireframe would not complete the vertical slice and a fake would not meet the Definition of Done. Completing the UI is also important because it would allow the UI automated tests (both UI unit tests and end-to-end tests that target the UI) to be completed, again a Definition of Done requirement. I coach the team to only consider 'Done done' work as being part of the product increment and only share 'Done done' work at the Sprint Review.

In summary, the Development team favoured 

a safer bet on completing a 'Done done' increment of product that represents a vertical slice but falls short of the Sprint Goal 

over 

optimistically running at the Sprint Goal with a high risk of ending up with an increment that meets the Definition of Done.

Although I think there were failings that led to this point (and I will be picking these up later), I fully support the decision they made and how they went about in given the circumstances at the time.

Ultimately, I cannot answer questions such as "Why did the team fail to plan better to reach the Sprint Goal?" or "Should the team have protected the Sprint Goal better?" or "Have the team make serious errors of judgement?" That's for the team to analyse and decide on during Sprint Retrospective.

[1] 'A Scrum Book: The Spirit of the Game' by Jeff Sutherland, James O. Coplien, and The Scrum Patterns Group (https://pragprog.com/book/jcscrum/a-scrum-book)

[2] Official Scrum Guide, Ken Schwaber and Jeff Sutherland, accessed 9 June 2019 (https://www.scrumguides.org/scrum-guide.html#artifacts-sprintbacklog)