When I wrote the “Long time, no see” post in December I was planning to resume writing regularly (at least bi-weekly) but since then I’ve only managed one. I thought I would have some spare time that could be put towards it but other things got in the way.

Does that sound familiar? How many teams start a sprint having planned to complete a number of things, only for that plan to go awry? If your team hasn’t experienced it yet, then it’s just a matter of time before you do… or maybe you’re playing it safe and you have a second planning session mid-sprint.

bury headI’m not saying this is a bad thing – stuff happens and not adapting would be worse. Sticking blindly to a plan and ignoring reality sounds ridiculous and yet many organisations still do precisely this.

So how can we reduce the chances of our plans being impacted? Plan smaller steps; discuss risks and dependencies as part of planning; understand your capacity; and say “no”, or at least “not right now”.

Plan smaller steps

planning onionIf you plan once a year (e.g. an annual budget cycle) then try moving to quarterly planning. If you create quarterly roadmaps that describe what needs to be delivered, then break it down into smaller feedback loops. If you’re a scrum team that plans four-week sprints but finds yourself replanning during sprints, then try two-week sprints. Whatever your cadence, if your plans often need updating then try a shorter timeline. It’s also possible that your plans are too detailed or rigid; there needs to be room to adapt based on learning, discovery and feedback. This is also why there are multiple “planning layers” – the team meet (at least) once a day to coordinate their efforts, share new insights, identify obstacles and make adjustments as needed. The shorter these feedback loops are, the sooner the team can respond.

Discuss risks and dependencies as part of planning

raidSprint planning isn’t simply for the team to decide what “fits” – there should be (or have been in preparation for planning) discussions about the risks, assumptions, issues and dependencies. The somewhat-controversial Definition Of Ready is a good place to keep a list of reminders of the types of things to consider, e.g. if it takes a while to get access to a particular system, then make sure the team knows to start that process ASAP (in extreme cases, it may mean postponing a story until the access is granted). What else might throw the plan off course? It’s not possible to predict and anticipate everything but the team should learn from past “gotchas” and try to avoid repetition.

Understand your capacity

overflowing bucketEven if everything goes smoothly, there’s no point in planning for more than could be realistically achieved. If a team uses story points consistently, then they probably have a good guide as to their capacity. Even without putting a number on it, stable teams should have a good feel for what is possible. The trouble with both those approaches is that teams can believe (or be cajoled into believing) that they can do more “just this once”. Forecasting (e.g. using cycle time) is based on the reality of historic data and is less open to “interpretation” or wishful thinking.

Say “no”, or at least “not right now”

drakeThe previous steps can help improve the likelihood of success, but one other defining factor is whether the team feels they can say “no” to taking “just one more thing”. If they feel they have to say yes to everything then there is no true commitment. (I know commitment is a controversial term; I’m using it as a shorthand for what the team tell those outside the team what they believe is achievable.)

In short: don’t make promises, because things change. Small steps with frequent feedback let your customer/sponsor see progress (which should lead to increased confidence) and collectively you can make adjustments based on new information.

I’m not committing (out loud or even just in my head) to updating this blog every two weeks, but I will try to write when I have time and have something to say. 🙂

Is it safe?

One of the agile principles is that the team have a supportive environment; Modern Agile explicitly says “Make safety a prerequisite”. It’s essential that the team can say “no” when asked to take on extra work, for example, otherwise saying “yes” has no meaning. We expect the team to commit to a sprint plan but if they cannot decide that a story is not ready (e.g. too many unknowns) or that taking “just one more story” will mean they cannot deliver them all, then any apparent commitment is just lip service.

However, many of the questions posed during software development can’t be answered with a simple yes or no – many require investigation (more than just a Google search!) so how can we make that safe? If the product owner wants to know if moving the “buy now” button will increase sales, or the team wants to know if splitting stories smaller will help them finish epics sooner, then the best way to find out is to try it and see i.e. run an experiment.

I often hear people talk about “failed experiments” but that’s misleading: an experiment proves or disproves a hypothesis. (OK, if you have constructed or executed it incorrectly, then maybe that’s a “failed experiment”.)

If we want to encourage a learning environment, we should get used to saying that the experiment proved our hypothesis to be incorrect, and that is something from which we can learn. For example, if the experiment’s hypothesis was that moving the “buy now” button to the top of the screen would increase sales by 5-10%, then (after collecting data from multiple customers) we could compare the sales figures for the button’s new location to its old location. An increase in sales could support the hypothesis; a decrease doesn’t. If sales were zero then we probably broke something and maybe that could be deemed a failure.

How do we make it safe to experiment? We must change our language but also we should observe the experiments closely and be prepared to abort them if we notice something outside of the expected parameters, e.g. sales dropping to zero. As part of defining our experiment, we should define an expected range (e.g. sales go up or down by 10%) – if moving the “buy now” button causes a 50% increase in sales (i.e. well beyond expectations) then perhaps something has gone wrong and we should reset everything.

While we’re thinking about the language we use regarding “failure”, another common phrase that needs to be stopped is “we failed the sprint”. Usually, this refers to the work planned for a sprint not being completed. However, sprints are timeboxes which means they end whether you are ready or not. Sprints don’t fail, they end. If the committed work is not completed, then I would still think twice about calling that a failure – it feels like the lead into apportioning blame, which is far from creating a safe environment. Incidentally, if the root cause of not completing planned work was found to be the product owner or senior management I suspect it would not be called a failure.

p.s. I managed to not reference the scaled agile framework or the scene from Marathon Man, so I’m calling that a success 😉

One More Thing

In the current (2020) version of the Scrum Guide the word “commitment” is used with regards to the sprint goal – “Although the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it.

So what should happen after the team and product owner agree on the goal for a sprint, create a sprint backlog and start the sprint … but then someone* tries to add something to the sprint? (*The “someone” could be the product owner, a manager, or it could be a critical production defect.)

The Scrum Guide doesn’t provide much in the way of guidance other than “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.

What does that negotiation look like? A colleague from a previous company, Kiryl Baranoshnik, wrote a post with some good suggestions but I have a slightly different set of suggestions. Like Kiryl’s post, I’ll break it into two parts: Immediate Action and Retrospection, but I’ve not had time (or the skill) to create my own infographic yet.

Immediate Action:

  1. Postpone it
    The first decision should be whether the work really must be done in the current sprint – if it’s not important and urgent then it probably doesn’t deserve to jump the queue. The default answer should be to add it to the product backlog and only bring it into the sprint if it absolutely cannot wait.
    If the product owner decides it must be done ASAP, then the team should follow their standard refinement practices, e.g. referring to their Definition of Ready and estimating the new story.

  2. Exchange it
    A question that I have found to help focus the product owner on whether the new work really justifies disrupting the sprint is to ask “If we were to bring this new story into the sprint then we will remove the equivalent (estimated) size of work from the lowest priority items in the sprint backlog – is that ok?” This tends to make it clear that some of the originally planned work is unlikely to be done, which often has a knock-on impact on the product roadmap.

  3. Absorb it
    If the team are confident they have the capacity to complete their sprint goal as well as the new request, then they can choose to bring the additional work into the sprint as is. The risk is that, despite their confidence, the team are unable to complete everything; this should be raised with the PO and discussed just the same as the team would do if a regular (uninterrupted) sprint was in jeopardy.
    I put this option last as it can sometimes be more of a non-decision, e.g. because the team may feel pressure to accept the new work in addition to their plan or be overly optimistic. If it is the route taken then I strongly recommend the team make it clear that, even though they will try to absorb the additional work, it could put the lower priority sprint backlog items at risk. It’s always important to talk to the product owner if reality isn’t going as planned, but in this instance, I think it is especially important for the PO to be aware.

In summary, the three reactions to choose from are: “no, we’ll put it in the product backlog”, “yes but something has to make room”, or “yes we think we have room for it”.

If the decision was either flavour of “yes” then the team and product owner should hold a retrospective to discuss the root cause (why did this work appear after sprint planning?) and how it impacted the sprint. I would recommend a retrospective even if the answer was “no” because the root cause question should still be addressed – why wasn’t the new request just added to the product backlog?

One other thing to discuss is how often these unplanned requests arise: if it becomes frequent then the team and product owner should discuss whether the sprint length is appropriate (if two-week sprints are frequently interrupted then maybe try one-week sprints), or if the nature of the incoming work is simply unpredictable (e.g. support teams tend to use kanban’s flow approach rather than sprints). There could be other causes, for example is the product owner able to say “no” to stakeholders (see Henrik Kniberg’s excellent “Agile Product Ownership in a Nutshell” video) but ultimately the aim of the retrospective is to identify the root cause(s) and experiments to try to address them.


  • Leaving room for emergencies
    If the sprint interruptions happen frequently then there may be a temptation to leave some capacity unplanned, ready to insert the additional work. The reason I list this as an anti-pattern as it can hide the problem but also because it can give a distorted impression that the team is over-delivering.

  • Having one team member assigned to emergencies
    A slight difference to the previous one, I’ve seen teams allocate one team member (often rotating the duty each sprint) as their “on-call” person; they plan the rest of the team’s sprint as normal but the selected individual works from an unplanned “to do” list. Again, this hides the problem of late-breaking unscheduled work.

  • Saying “yes” without being able to consider the impact
    Teams that don’t feel they can say “no” or discuss how the additional work impacts their sprint plan aren’t really planning their sprints – if you can’t say “no” then saying “yes” has no meaning. Morale tends to be very low as the team has no control over their workload, which management often describe as “lacking engagement or ownership”.

This list could probably include a lot more anti-patterns, but please leave a comment if you’ve had success with these Immediate Actions or seen other ways to handle the mid-sprint request to add One More Thing.