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.

Scrum Values – Openness

I am writing about the Scrum Values and this week it’s the turn of Openness. Being open with each other and our stakeholders is key for the success of a Scrum Team. Scrum is built on Empirism which in turn has pillars of Transparency, Inspection, and Adaption. Without Openness there is no Transparency and the whole framework comes crashing down. Lets dive into this a little deeper to explain what I mean.

In Scrum we constantly inspect our progress, we do this at least once per day using our Daily Scrum within the Sprint and then again at each Sprint Review as we examine our progress against the Product Goal. The purpose of this is to detect any issues early and adapt our plan to ensure we can meet our goal despite the problems which arise. Transparency is vital to this inspection, if we do not make efforts to make our work and current challenges transparent then we will not be able to inspect or adapt. This puts the entire team’s long term goals at huge risk.

If we do not create transparency through openness then we will be unable to inspect and adapt.

As Scrum Team Members we must value Openness and Transparency. This allows our colleagues to support us, it also allows Stakeholders to engage and steer the team to providing true value for the customer. If we are not open with our work or our concerns then we will blunder into making mistakes which could have been avoided.

In previous posts I’ve referred to Steve Trapps’ excellent blog post about Scrum Values. In it he asks key questions which lets Scrum Team members assess their own levels of Openness, these are:

  • I do not shy away from telling difficult news to team members and stakeholders
  • I do not hide away difficult issues in the hope that they will sort themselves out.
  • If something / someone is annoying me I will address it / tell them.
  • My colleagues can judge what state of mind I’m in, I can share my feelings with my them.
  • I always say the true state of an item, and do not over/under play it.

How many of these questions can you truthfully answer yes? Are you building a safe environment so your colleagues can be open with you?

Look for Openness on your teams and evangalise it yourself, the results speak for themselves.

The Scrum Values – Respect

We’re working our way through the Scrum Values, the second value I want to talk about is Respect.

Last week I shared Steve Trapp’s blog post. In it he asked Scrum Team Members

  • I listen with equal intensity regardless of who is talking.
  • When listening to people I never talk over them.
  • I value everyone’s opinion equally.
  • I am never concerned who works on what item in the backlog.
  • I feel that my opinion is respected and that I have an equal say in the team.

Respect is key in a Scrum Team. A good team is diverse and brings together different people with a wide variety of backgrounds and experiences. People can only work effectively if they feel safe to share their own points of view. If you haven’t already I strongly recommend reading 5 Dysfunctions of a Team as a great fable about why this is so important.

If we want to work well as a team it’s important we can engage in constructive conflict without making people feel vulnerable and worried that their ideas will be ridiculed. We all need to take responsibility for creating a team where respect for each other is paramount.

Of all the Scrum Values this is the one I believe is the most important. Great teams can adapt and rise to meet challenges, however a great team cannot exist without mutual respect between the team members and between the team and it’s stakeholders. Reinforce respect and you’ll build a strong team who can achieve great things.

How do you nurture respect in your team? What do you feel when working in a respectful environment? Let me know in the comments below.

The Scrum Values – Focus

The next topics I want to discuss are the Scrum Values, these are Commitment, Focus, Openness, Respect and Courage. Or as I remember them Focus, Respect, Openness, Courage, and Commitment. I find the values some of the hardest parts of scrum. Not because I disagree with any of the values – I find them all admirable and praiseworthy but because I find them harder to measure. Its easy to see whether a team is running Daily Scrums, its less clear whether they’re displaying courage!

In his blog post on the Scrum.org website Steve Trapps talked did a fantastic job of articulating what these values look like when a team share them. For focus he said:

  1. Whilst working on a story I do not get distracted.
  2. If I am not enjoying the work in a story I still give it the attention it needs.
  3. When enjoying working on a story I will not over work a story just to prolong it.
  4. I do not procrastinate when working on a story.
  5. As soon as the story is ready to move into a new state, I will tell my colleagues and either hand it over or ensure that they know it is ready to pick up.

I think these are very valuable questions to ask yourself and your team to assess whether you are living the values which help support Scrum.

When Scrum Team Members focus on their work it helps the entire team achieve it’s Sprint Goal. This in turn moves progress towards the Product Goal and helps the Product Owner deliver real value to the customers. However, if team members are not focused, if they are distracted by endless emails or shiny opportunities then they often fail to deliver and the Scrum Team has to replan frequently.

Scrum Team members should value focus and avoid distractions.

It is everyone’s job as Scrum Team members to help reinforce focus wherever we can. To avoid distracting each other and to collaborate in a non-intrusive and distracting way. We should empower our developers to work autonomously and focus in a way which works best for them. For some people that means at home, for others that means in an office surrounded by people to collaborate with.

Keep focus in mind and always look for ways to encourage it both within yourself and within the team.

The Increment and Definition of Done

The last couple of posts I’ve written have been about the Product Backlog and Product Goal then the Sprint Backlog and Sprint Goal. Today I’m going to focus on the Increment and it’s Commitment the Definition of done. These are slightly different to the previous two Artefacts and Commitments, the Backlogs and Commitments described above show the current progress of work and the vision of what that work will look like when it’s delivered.

The Increment is the piece of work which is being delivered to the customer at the end of the Sprint. These should be as small as possible, however it’s possible that it may be the entire Sprint’s worth of development. The Increment is the next piece of the product which has been added to create more value. Scrum.org has a nice defintion of an increment.

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

The Scrum Guide 2020

This is different to the previous to artefacts because it doesn’t describe the current state of what’s being worked on for the purposes of inspection, is is what’s being worked on.

Increments are added iterativly with each one meeting the Defintion of Done, this ensures that quality does not decrease during the Sprint. Photo by Startup Stock Photos on Pexels.com

However, as with previous artefacts it does come with a commitment. Where the Sprint Goal and Product Goal descibed the objectives we were working against the Definition of Done is a commitment to create transparency over what has been delivered.

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

The Scrum Guide 2020

One of the biggest frustrations in modern software development is when something is “done” but exactly what that entails is a little hazy. One team may mean code complete, another may mean tested, another may mean deployed to a customer. The Definition of Done creates a shared agreement of what the team understands “Done” to mean. This prevents the awkward scenario where a stakeholder is expecting tested functionality but gets only code complete stories.

It also makes estimation easier because everyone has a clear understanding of what is expected.

The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment.

The Scrum Guide

If a team is working as part of a Nexus of Scrum Teams developing a single product, or if they’re part of an organisation providing components to another team then the Definition of Done should be shared to ensure that all teams share the same understanding of when something can be said to be Done.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum

The Scrum Guide 2020

Teams which do not have a clear defintion of done experience friction when engaging with stakeholders, uncertainty when it comes to estimates, and ambiguity when planning out work.

A good Definition of Done should include items like:

  • Acceptance Tests Pass
  • Non Functional Tests Passed
  • Documentation Created
  • Deployment Pipelines Created

It may also include “deployed to customer” if a team is following Continuous Deployment practices. However, for the purposes of Scrum we commit that our increments will only be “Potentially Shippable”.

One final point, the Definition of Done ensures that quality does not drop as functionality is added. The Scrum Guide states that quality does not decrease during the Sprint. The Definition of Done helps us verify that each and every increment is complete and quality is maintained before it is declared complete.

Hopefully this has been helpful, I think it may be time to look at the Scrum Values!

The Sprint Backlog and Sprint Goal

Last week I talked about what Artefacts and Commitments are and described the Product Backlog and Product Goal. This week I’m going to continue this theme but focus instead of the Sprint Backlog and Sprint Goal.

The Product Backlog is an ordered list of all the work which would deliver value to the product, we consolodate a future vision of this around a Product Goal. Within a Sprint we look at this at a much smaller scale, breaking down a single step the team aims to achieve and then comes up with a plan to deliver it.

Many teams I’ve worked with come at this the wrong way around. They look at the next work on the Product Backlog and through estimation and historical velocities select a number of stories which will “fill the sprint” usually carrying over anything which wasn’t completed in the previous sprint. Then they declare a Sprint Goal which is usually sounds like “Complete these Backlog Items” or “Do this, this, and this.” If you haven’t already I hightly recomment Jasper Alblas’ blog post about Sprint Goals.

Instead a team should look at their Product Goal and declare a Sprint Goal which will move them towards it. They should then identify the appropriate Product Backlog Items required to deliver that Sprint Goal and use estimation to ensure that it is realistic.

The Sprint Backlog should be a plan to achieve a Sprint Goal. The Sprint Goal should not be to complete a Sprint Backlog. Photo by olia danilevich on Pexels.com

The Scrum Guide tells us that:

The Sprint Backlog is composed of the Sprint Goal (why), the set of Product Backlog items selected for the Sprint (what), as well as an actionable plan for delivering the Increment (how).

The Scrum Guide 2020

In other words once we have a Sprint Goal in mind we should identify the work required to deliver it (the what) and create a plan for how to deliver it (the how). With these three components in place we are in a position to start delivering.

As the Sprint progresses we should update the Sprint Backlog to reflect the progress of the work being delivered. PBIs may be marked as done or we may encounter impedements. However, by using the Daily Scrum sessions and the Sprint Backlog we’ve created enough transparency for us to be able to inspect and ensure that we are still able to meet our commitment – the Sprint Goal.

This is why a transparent Sprint Backlog is so important, it’s also why Daily Scrums are so vital. They give a daily opportunity to see issues and resolve problems so that the Sprint Goal is met. As soon as the team identifies that their Sprint Goal is at risk, perhaps the original approach won’t work or the effort required is greater than they originally intended they can adapt their plan.

Directly from the Scrum Guide

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 Scrum Guide 2020

In other words the team should attempt to meet their Sprint Goal in a different way, perhaps by negotiating scope or taking a different approach. If the Product Goal is simply “do the work” then there’s no way the scope can be renegociated and the team will not make a move forward against the larger Product Goal.

Finally, if something happens which renders the Sprint Goal obsolete, perhaps a significant new piece of information, business incident, or realising that it’s impossible the Product Owner has the authority to cancel the Sprint and replan a new Sprint Goal.

I hope that this has given some insight into why the Spring Backlog and the Sprint Goal are so important. Next week I’ll progress on and we’ll look at the Increment and it’s Commitment The Defintion of Done.

Artefacts and Commitments the Product Backlog and Product Goal

Scrum contains three Artefects each of which have a corresponding Commitment. It took me quite a long time to get my head around these so I will attempt to explain what both of these terms mean here.

ArtefactCommitment
Product BacklogProduct Goal
Sprint BacklogSprint Goal
IncrementDefintition of Done

But what exactly are Artefacts and Commitments? The 2020 Scrum Guide explains that

Scrum’s artifacts represent work or value

and

Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured…

These commitments exist to reinforce empiricism and the Scrum values for the Scrum Team and their stakeholders.

To show this I’m going to describe how these apply to the Product Backlog and its corresponding Commitment the Product Goal. Then, in over the next two weeks I’ll cover the Sprint Backlog, Sprint Goal, Increment, and Defintion of Done.

The Scrum Guide tells us that the Product Backlog (the artefact) represents Work (or value), it is an ordered list of all the work the team intends to do to deliver value to it’s stakeholders. The Product Backlog Items (sometimes written in the form of User Stories) are often sized to give an indication of how much effort is required to deliver them and to help the team with forecasting.

The Commitment contains the information to create transparency to stakeholders so they understand what to expect as the work is delivered. In the case of the Product Goal this is a medium term future state which the scrum team is working to deliver. It describes a set of functionality the team can use to plan against and create a focus beyond the Sprint by Sprint goals.

The scrum team can assess what’s delivered each sprint and look at the work required to meet the Product Goal. They can then decide the next work which needs to be delivered and begin to plan it. This is commonly done in the Sprint Review and Spring Planning sessions. In fact, when a team is following Scrum diligently there is often a lot of crossover between these two sessions with one flowing seemlessly into the next.

I’m having quite a lot of fun talking about Product Backlogs and Product Goals in Donuts and Dragons, the book I’m currently writing about Agile Doftware Development. Initially the team focus on improving overall user experience, then they realise that they need to pivot and adjust their Product Goal accordingly.

It’s worth noting that

[The Scrum Team] must fulfill (or abandon) one objective before taking on the next.

The Scrum Guide 2020

This is to prevent the team splitting their focus and attempting to deliver multiple projects at once. Obviously something which wants to avoided.

Once the Product Goal is met (or abandoned in favour of a more appropriate one if required) the Product Owner will work with the team to identify the next goal. It’s not uncommon to see a high correlation between Sprint Goals and “Releases” in more traditional organisations. While planning a single deployment from release is far from recommended it often helps businesses to group work together into Releases or Projects (I know, all dirty words in Scrum) and the team can map the Product Goals onto these. After all, what is a Product Goal if not a collection of work to be done to deliver value to stakeholders and transparency to the business?

I hope this post has been helpful, next week I’ll discuss the Sprint Backlog and it’s Commitment the Sprint Goal.

PSM-III Exam and Certificate

Over the last I’ve been discussing the Scrum Master exams from Scrum.org. Today I’m going to look at the PSM-III, it’s the hardest and last of the scrum master exams. In their own words

PSM III certificate holders prove that they have a deep understanding of the application of Scrum, Scrum practices, the Scrum Values, and have the ability to apply Scrum in a variety of complex team and organizational situations.   

Scrum.org
The PSM-III is the highest ScrumMaster certificate at Scrum.org

According to Scrum.org’s own statistics at the time of writing less than 1000 people have passed this exam. That’s around 7% of the people who’ve taken the PSM-II and a staggering 0.2% of the people who have taken the PSM-I. In other words, PSM-III certificate holders are few and far between.

So what does the exam entail? As with all other scrum.org exams anyone can take them at any time, there’s no requirement to go on a particular course or buy certain books. The cost for this exam is $500, it’s expensive because real scrum experts mark it. The marks for earlier exams in the series are calculated automatically but the PSM-III asks the candidate to write answers to questions which are then marked. This obviously adds cost.

The exam itself is 30 questions and you have 2 hours 30 to finish it. The questions are a split of multiple choice and essay type answers. As with the PSM-II questions are much more focused around what you would do in a particular situation rather than asking you to give answers directly from the Scrum and Nexus guides. The pass mark is 85%.

Time is your big enemy in this exam (you know, other than the difficulty of the questions). You need to work quickly and make sure you’re covering all the points in each question. Particulary in the essay questions there are multiple points to address and you have to think and write quickly to ensure that you have enough time to finish the paper.

You should work quickly, not focusing too much on spelling and grammar but making sure you’re answering the entire question and what you have written is clear. You don’t lose points for typos but you will miss them if you get to the end of the time and haven’t answered all the questions. Work your way through the question and make sure you’re answering everything which is asked. In the multiple choice questions remember that more than one of them may be correct.

Not all questions are the same length so it’s not as easy as limiting yourself to 5 minutes per question. Some of the multiple choice questions may take ten seconds and the longer essays some significant time. Having said that, keep an eye on the clock and pick up the pace if you’re running behind.

When I clicked Submit at the end of the paper (with around 2 minutes to spare) I felt absolutely exhausted. But then the next trial begins. As I mentioned above the test is marked by scrum.org’s own experts so you won’t get your answer right away. You will get an email confirming they’ve got your answers but then you will have to wait, three weeks in my case and let me tell you it’s a very very long wait. At one point I even began to wonder whether the wait was part of the test and they’d see how I’d escalate or communicate with a third party supplier!

You don’t get the same category breakdown you do with the PSM-I and PSM-II but you do get a very helpful email with feedback, some questions to think through to further your learning, and hopefully some good news.

I found the entire process and exhausting and very rewarding experience and was delighted when my certificate came though.

What are your experiences of the PSM-III exam? What advice would you give to other people looking at taking it? Please drop me a comment below and let me know!