Managing Interuptions and Cancelling a Sprint

One of the more frequent questions I get about Scrum is how to manage interuptions within a Sprint. Interuptions and ad-hoc requests are a fact of life. Unless you’re working on a product which hasn’t launched yet there are going to be customer queries, and if you’ve not launched yet there’s a fair chance there will be questions from the sales and marketing teams or other stakeholders. There are a few options on how to deal with these. You can refuse to answer any query or request for help, or you can be the supportive colleague we all want to be. The real trick is how to balance these queries while still delivering the work the team is being paid to do.

In the past I have offered a few suggestions on how to approach this. What always strikes me though is how many teams either accept or push back on a request without understanding the impact it will have.

Should I support the business by answering quetions or deliver on the Sprint Goal? Photo by Robert Nagy on Pexels.com

Lets consider each piece of work which comes into the team as a new Product Backlog Item. This could be a support request or a question about how a particular piece of functionality works. As with all work it is the Product Owner who is ultimately resposible for maximising the value delivered by the team.

To do this we often need to pieces of information. What is the value this PBI delivers and how much effort will it entail. Now, there is no doubt that a level of pragmatism applies here. If the PBI is a quick email and won’t make any different apply the two minute rule and just do it. However, to avoid small task whiplash I recommend turning off email and IM notifications and replying to them in bulk.

Lets assume that a request for support is going to take more than 2 minutes. Perhaps the application is running slow in production. For the PO to make an informed decision he or she needs to understand what the impact is on the end user, are we talking a mild frustration (which could be looked at in the next sprint) or the system being rendered unusable. We also need to understand how long it will take to resolve. Remember relative sizing, is this likely to be more or less complex than the issue we looked at last week?

The first question which must be asked is “Can we respond to this request without jepodising our Sprint Goal?” If the answer is yes, then more often and not that’s exactly what the team should try and do. They should also use the Daily Scrum to continually reassess that assumption as the Sprint progresses.

However, lets say the team can’t help the business and meet the Sprint Goal. What should they do? Abandon the business in their time of need or give up on the Sprint Goal?

This is where the second question comes in, the urgency of the request. Lets go back to our example of poor performance in production:

  • This is a really big deal and needs to be looked at immediately
  • It’s a moderate issue, we should finish off the current Sprint Goal and then change priorities next sprint
  • The current Product Goal is more important and we don’t intend to look at this any time soon

I will just stress this again, this is the Product Owner’s decision, no one elses.

If the PO believes that whatever this support request is would deliver more value than hitting the Sprint Goal and they have agreed that the team can’t do both then this renders the Sprint Goal obsolete and the Sprint should be cancelled. The team should resolve whatever the issue is and then return to sprinting.

If the Product Owner decides to prioritise the work in a future Sprint (or not) then the work should be shown very clearly in a backlog. This is where transparency is key. Stakeholders grow frustrated when they request work and it vanishes into a black hole. By sharing exactly what the team is working on and seeing their work in the priority list stakeholders are able to engage with the PO to challenge priorities.

However the work is prioritised team members shouldn’t feel pressured into juggling both the Sprint Goal and the requests. That’s a great way to burn our engineers and put Sprint Goals at risk by hiding work in the gaps.

When one of the biggest challenge teams face is when the number of these ad-hoc requests means team sprints become disrupted over and over again. However, unless teams have a process in place when new work comes in then they will never stand a chance of maintaining sprints to continue to develop their product. When this process becomes embed and easy to apply it creates stability and prevents teams being pulled in different directions.

How do you manage disruptions? Do you cancel your Sprints when the goal becomes obsolete? Do you keep your backlog transparent to avoid stakeholder frustration – add a comment below or drop me a message on twitter.

The Scrum Values – Commitment

We’re on our last Scrum Value (and possibly the end of my Scrum walkthrough unless I think of any more topics to cover). This time it’s the turn of Commitment.

To help me describe the importance of the values and how they relate to day to day work I’ve used the questions Steve Trapp has posted in his excellent blog post. Under Commitment he asks:

  1. I always know what the sprint goal is and how my work supports it.
  2. I do everything I can to ensure we achieve the goals of the sprint.
  3. In my current team, I have never thought of taking a sick day to avoid going into work.
  4. I always arrive on time for the events, my colleagues never have to wait for me to start the event.
  5. I know what it means to say that an item is done, i.e. I know the criteria that meets our Definition of Done.

This shows very clearly how important Commitment is to Scrum Team members. We value people working to support the Sprint Goal, doing everything they can to achieve it, and not being dishonest with our team members (no matter how hungover we may be!).

It’s also about professionalism. Arriving on time to events and ensuring that work we deliver is complete and meets the Definition of Done.

The Scrum Guide itself even has the concept of Commitments. The Product Goal, The Sprint Goal, and the Definition of Done. These are promises we make that we will aim towards. Commitment as a Scrum Value reinforces that idea of deliverying what we set out to right down to the individual level.

Scrum Team members commit to a goal and do everything they can to achieve it. Photo by Nataliya Vaitkevich on Pexels.com

When I talk about commitment I think a lot about the book 5 Dysfunctions of a Team. In it Lencioni discusses the importance of creating safety in our teams (respect for others), how this makes people feel confident to engage in discussions and voice their opinions (openness and courage). If people don’t feel they have their chance to voice their points of view then they will not commit to a decision and will not hold each other accountable for the results. By valuing Courage, Openness, and Respect so highly the Scrum Framework is building an environment where team members can commit to a decision or Sprint Goal and will want to do what’s needed to achieve it. Commitment stops being about “going the extra mile” for the company and starts being about colleagues and teammates working together towards a shared goal. This is what commitment is about for me, not about “taking one for he team” and working yet another late night.

When Scrum Team members all commit to a goal they will often find a way to achieve it, even if the original plan which comes out of Sprint Planning turns out not to work. Team Members become determined to adapt and find a solution despite the inevitable challenges.

What does commitment mean to you? Do you think you need to be working in a team where you feel safe before you can commit to a goal? Let me know on Twitter or in the comments below.

Scrum Values – Courage

I’m working my way through the Scrum Values and explaining why each is so important to a Scrum Team. So far we’ve covered Focus, Respect, and Openness, today it’s Courage.

I think Courage is hard to define, as engineers we’re often courageous when picking up a new piece of work. We don’t always know how we’re going to solve a particular problem but we’re using to trusting in our own abilities and our support network to accept a task even when ambiguity and risk exists. There may be easier backlog items, ones which we know we’d be able to complete but we prioritise the most valuable, not the easiest.

Courage is a key component of any Scrum Team, even if it’s hard to define why. Photo by Marcelo Moreira on Pexels.com

Courage in my opinion manifests in a couple of ways. One of the responsibilities of any Scrum Developer is to hold each other accountable as professionals. This often isn’t easy, especially when the other developer is more experienced or senior than we are. If we believe that a particular course of action is the correct one it takes real bravery to speak up and make sure our point of view is heard. To understand why this is so important read 5 Dysfunctions of a Team!

It can also take courage to share our own weaknessess or concerns. But it’s this transparency which is so important for Scrum Teams to function effectively. If team members are afraid to share risks then they will most likely go ignored and the Sprint will fail.

Throughout this series on values I have referred to a blog post by Steve Trapps. He has posted a series of questions around the Scrum Values which can help you assess how strongly you live the values of scrum. For Courage his questions are:

  • I work on the next highest priority Product Backlog Item (I do not cherry pick the work I pick up in the Sprint)
  • If I see something that is wrong with what I’m being asked to do, I will say so.
  • I will question & reproach my team members if I feel that they are doing something wrong.
  • Regardless of the person talking, I will correct them if I believe that they are incorrect.
  • I will stand firm if I believe I am right, even if I’m in the minority within the group.

Do you think these are good questions to assess a team member’s courage? Do you believe you are courageous at work? Drop a comment below or contact me on social media to continue the conversation.

Q3 2020

It’s October, which means it’s the end of Q3 and beginning of Q4. Personally I work on a quarterly goals cycle so I want to share a few of my achievements throughout the last 3 months and share what I’m hoping to achieve in the last few months of 2021.

My goals for Q3 were:

  • Take 2021 Book Count to 70 – Done (I’ve read 78 books)
  • Pass AWS Architect Associate Exam – Done
  • TakeĀ  PSM-III Exam – Done (Passed)
  • Take PSD-I Exam – Done (Passed)
  • Host my CKD Site on AWS – Done (with a domain name, the site itself is still a work in progress)
  • Edit and Republish Donuts and Dragons – Done
  • Internal Work Goals 1 and 2 – Done
  • Get Weight Down to 215lbs – Fail (ok, this one didn’t go so well, I’m sat at 222lbs at the time of writing)

So what do I have in mind for Q3? I intend to:

  • Take 2021 Book Count to 100
  • Pass AWS Security Specialist Exam
  • TakeĀ  SPS Exam
  • Build a Lean Coffee Website
  • Publish a Short Story with the Donuts and Dragons Team
  • Paint my Lannister army of A Song of Ice and Fire miniatures
  • Paint my Warhammer 40k Salamanders
  • Finish the core pages of the CKD Site
  • Pages Get Weight Down to 215lbs (really this time)
  • To hit a financial goal I’ve set myself.

What are your goals for the rest of 2021? Have you got any new year’s resolutions you’ve not hit yet?