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)

KPIs as an Agile Coach

I'm always saying to leaders that we'll know I'm having a positive effect when we hear certain language being used.

I've noticed a progression as regards changing conversations. This might reflect UK culture or be more to do with my personal approach. The progression goes something like this:

Early on: a team member will say, "Because Jamie is present [knowing laughter], I should say..."
Later: "As Jamie would say [smiles], ..."
Finally: It just gets said. The fact I introduced it is - rightly - no longer a consideration.

Below is a fantastic example of exactly the kind of language I love to hear team members using. Note this is a verbatim quote (product-specific details) as posted in the team's Slack channel, used with permission:

"Dear [Product Owner], As you missed stand up you should know we believe we will not meet the sprint goal 😞 We are going to prioritise the UI changes now so we have something to show and get feedback on. We have identified a number of extra tasks as part of the [redacted] work. Most of these are not unique to this piece of work and will likely see reuse in other stories (even if only as patterns). We have made a number of good learnings this week and the work around [redacted] in particular should help benefit the upcoming [redacted] work. Happy to discuss further if you want."

Notable features:

• The team member took the action unprompted.
• They have reflected what was agreed collectively at the Daily Scrum. Note that the PO was unavoidable detained elsewhere.
• It makes clear to the Product Owner that Sprint Goal will not be met. While they had considered whether the Sprint Backlog could be renegotiated to satisfy the Sprint Goal, on this occasion they decided that it couldn't without incurring technical debt.
• Mild regret is expressed for the shortfall. As per Toyota, "There can be no kaizen ['improvement'] without hansei ['reflection']." [1]
• It underlines that what the Development Team have learned this Sprint will genuinely have positive effect on upcoming Sprints. That is, they are not making excuses for failure; rather, highlighting their successes despite the Sprint Goal being missed.

When I started with this team, language like this would simply not have been heard. Sprint Goals were afterthoughts (punchlines!), hastily written after a Sprint Backlog had been assembled. Un-Done work at Sprint end would occur frequently and was always carried over to the next Sprint without discussion. Product Backlog items read like mini-specifications rather than hypotheses to be experimented on to provide learnings. Sprint Reviews were demonstrations of Done work rather than conversation starters to get feedback from stakeholders. 

Change has been brought about by taking a multi-faceted approach, including:

• leading by example
• role-modelling desirable behaviours
• agreeing a code of conduct
• introducing new practices and challenging entrenched ones.

Teams can change their language in a positive way when they have incentives to do so, given adequate time and the right guidance.



Here are some KPIs suggested in the Hands-on Agile Slack community:

• Whether the team is meeting the stated goals of (a) the company and (b) customers and their users.
• Whether team members would recommend me as an Agile Coach to other teams/organisations.
• Whether the team is establishing their own KPIs and working collectively toward them.
• Whether the team engages in healthy conflict (e.g. seeing team members challenging each other firmly then going together for lunch and cracking jokes).
• Whether the team is feeling safer.
• Level of team happiness.

Essential Agile and Scrum books

Essential reading

'Coaching Agile Teams' by Lyssa Adkins (link)


'Agile Retrospectives' by Esther Derby (link)

'A Scrum Book: The Spirit of the Game' by Jeff Sutherland, James O. Coplien et al (link)

'The Scrum Princess' by Kyle Aretae (link)


'The Lean Startup' by Eric Ries (link)

'The Phoenix Project' by Gene Kim,  Kevin Behr, George Spafford (link)

'Scrum: The Art of Doing Twice the Work in Half the Time' by Jeff Sutherland (link)

'Scrum: A Pocket Guide' by Gunther Verheyen (link)

'Agile Testing' by Lisa Crispin, Janet Gregory,  (link)

'Agile Estimating and Planning' by Mike Cohn (link)

Honourable mentions

'The Five Dysfunctions of a Team' (Manga Edition) by Patrick Lencioni (link)

'Scrum Product Ownership' by Bob Galen (link)

'Making Work Visible' by Dominica Degrandis (link)

'It Doesn't Have to Be Crazy at Work' by Jason Fried, David Heinemeier Hansson (link)

'Scrum and XP from the Trenches' by Henrik Kniberg (link)

'The Scrum Field Guide' by Mitch Lacey (link)

'Scrum Mastery' by Geoff Watts (link)

'The Coach's Casebook' by Geoff Watts (link)

'The Way of the Web Tester' by Jonathan Rasmusson (link)

'Training from the Back of the Room!' by Sharon L. Bowman (link)

Dedicated Scrum Masters

The SMs I've worked with who've had the most positive effect on a team (performance, safety, empowerment, etc) were dedicated to the SM role. Everyone I have spoken to who has worked with a competent dedicated Scrum Master agrees. 

Every 'Developer as Scrum Master' (DSM) I've worked with has been far less effective. They can keep things ticking over but in my experience the DSMs put much more into the Dev role.

The real test is when a crisis happens: 

• Do they go into SM role? Do they focus on facilitating the urgent re-planning and discussions? Do they work to ensure safety so that the Developer's don't work silly hours?
• Or do they go into Developer role? Are they active in tech discussions and drawing on the whiteboard? Do they put in extra hours coding?

The DSMs I know would go completely into Developer role in a crisis and drop most Scrum Master duties in the process!

But it is more than this. DSMs are more likely to look at Stack Overflow for a coding issue rather than read a Scrum.org blog post about a team issue. They do code show-and-tells more often than run workshops teaching Agile supporting practices. They more often step in to the role of the expert telling the team rather than the active listener asking powerful questions.

The Head-of-department Scrum Masters I've know have had some success on tactical issues (impediment identification, not over-~committing~forecasting in Planning, etc) but have not really been really effective as regards kaizen and taking the team to the next level.

Un-Done work at Sprint end

Having un-Done work (items pulled into the Sprint but not Definition of Done at Sprint end) can be demoralising and prevent the team achieving a stable velocity. Many Scrummers ask, how do we account for this un-Done work, should it be re-estimated based on what is left to do or based on its new larger size?

If this happens only occasionally, go with the Development Team members' gut feel (e.g. spend five minutes per item estimating the impact in Story Points using poker) and move on. It will merely be a blip and the average velocity will balance things out. No biggie.

But if having un-Done work at the end of a Sprint occurs regularly, rather than merely treating the symptoms ("How to we account for carry-over of un-Done items?"), look to cure the disease ("How do we prevent un-Done work arising?") .

Symptoms to look for:

• No Sprint Goal. One the most effective patterns I can offer Scrum Teams it to start planning Sprints around Sprint Goals.
• The Sprint Goal contains connectives. For example: "Make services run on SQL Server and make the website open nicely in Chrome on Android and support features necessary for population genetics analysis." Clearly the two 'and' connectives strongly indicates there are three goals in this case.
• The presence of many items in the Sprint Backlog that do not relate directly to the Sprint Goal. What percentage of the items in the Sprint Backlog should directly relate to the Sprint Goal? While I think the value should be high, 100% may be idealistic and not practical.
• The team doesn't spend much/any time on 'Topic Two' during Sprint Planning. Take a look at the Sprint Guide section on 'Sprint Planning'. In my experience, the average Scrum team spends very little time on Topic Two.

Actions to cure the disease:

• Shorten the Sprint cadence. This suggestion might seem counterintuitive but I've personally had success with it. Shorter periods of time are easier to plan, which is why we do Sprints in the first place. It also reduces work in process (WIP) which helps teams focus on getting items to Done.
• Coach the team (or perhaps just the PO) on effective Sprint Goals.
• Teach the team to leave Planning with a plan. Yes, we favour responding to change over following a plan but we still value having a plan! Topic Two of the Scrum Guide outlines what such a plan should be.
• Coach the Development Team members on protecting the Sprint Goal by renegotiating the items on the Sprint Backlog mid-Sprint (reduce a PBI's scope, swap it for an alternative/smaller item, remove it from the Sprint Backlog, etc). Teach the team to refer to the Sprint Goal when they speak at the Daily Scrum. Make clear that a Sprint Goal without connectives is easier to protect.
• Ensure the Devs are making transparent which items are at risk of remaining un-Done and doing so early enough in the Sprint to allow renegotiation. A few of days before the Sprint end, the Scrum Master can take a confidence poll to identify items that are at risk of being un-Done. The team should discuss these items at Daily Scrum and adapt the Sprint plan accordingly.

Participation at Scrum Events

The best Sprint Retrospectives I have been part of have involved all team members bringing data (key occurrences, reactions, feelings ideas to try, etc), participating in analysis of the data to gain insights and agreeing actions to which all team members can share (and hold each other to account when agreed action is not taken).

The best Sprint Reviews I've attended have involved all team members taking pride in the increment they have delivered, telling the story of each item to stakeholders, taking note of feedback and standing together as a team when things haven't gone according to plan.

The best Sprint Planning I've experienced has involved everyone in the team playing their roles: listening to the PO's Sprint Goal, pulling in items from the Product Backlog that would best fulfil the Goal, possibly negotiating with the PO to possibly revise and split items, then formulating a plan on how each items will be turn from idea into Definition of Done as regards the various functions within the team's direct control (analysis / design / code, verify, database / API / UI, unit / integration / acceptance tests, etc).

The best Daily Scrums I've seen are mini planning sessions, where the plan agreed in Sprint Planning is reviewed and either continued progress is agreed or a change to the plan is immediately (immediately after Daily Scrum).

I think all Scrum team members has the potential to contribute to all Scrum Events in a way that increases their value.

For example, testers you have a particular role to play in representing the customer e.g. in Sprint Planning, ensuring the acceptance criteria is sufficient to clearly define the solution space without going as far as specifying an actual solution and checking that we are planning to deliver the smallest 'vertical slice' of functionality that provides the end user with the PO's desired capability. One way of doing this is to ask a well-timed, salient and considered open question. I testers doing this at Scrum Events to powerful effect.

It is my expectation that all team members attend all Scrum Events. It is my expectation that all team members actively participate. If there are impediments to team members actively participating then is my challenge (as SM) for issues to be identified and resolved where possible and desirable to all parties.