Tag: scrum

Moving the sprint end date

Most of Canada has May 24th off work – Quebec calls it “National Patriotes Day” but everyone else knows it as Victoria Day. But what do you do if it falls during your sprint? I’ve heard some teams move the sprint end date to compensate, so their sprint is still the same number of working days. (I’ll use 2-week sprints for simplicity but YMMV – I’ve worked with teams using 1-week, 3-week or 4-week sprints, but I’ve never seen a non-integer week duration; have you?)

I can understand the thinking behind moving the sprint end date because that gives them the same capacity as other sprints, but I think it’s a slippery slope: would you move the sprint end if some of the team are on vacation for a week? What if the company introduces a weekly all-hands meeting that consumes 90 minutes of everyone’s time? Do you move the sprint review and retrospective by the same amount?

The intent behind setting a regular cadence for your scrum events is so that everyone knows when they happen, and it simplifies meeting scheduling (set a recurring appointment and let it run). Often key stakeholders have busy schedules, so knowing the sprint review will always happen at the same time makes it easier for them to move meetings around it. (I would argue that your stakeholders’ willingness to prioritise your sprint review over other activities is a reflection of the value/importance of the work you’re doing.)

A regular cadence does not mean that your sprints will always have the same capacity – today’s stat day (aka Bank Holiday in the UK) means a reduction of 10% of the sprint… or more if some of the team took Friday off to make a 4-day weekend. Hopefully, the team thought about this when they planned the sprint and adjusted accordingly. Some teams I’ve worked with use a simple spreadsheet as a reminder to check each team members’ availability – maybe one person is on vacation for a week and another is on a course for 3 days.
I stop short of then calculating what percentage of the team is available and applying that to their velocity – this isn’t a precise science, just an aide-memoire to get them to think before they plan. If the team still relies on one person for a particular skill (e.g. database design) and they’re away then maybe the team needs to rethink which stories they can complete… and hopefully that’s also the trigger for them to work out how to share that skill so they don’t hit the same problem again.

An extreme case usually happens around the end of the year: a combination of holidays, stat days, and using up personal vacation time can mean a 2-week sprint has a tiny fraction of the normal capacity. I’ve seen teams make an exception and have a one-off extended sprint, spanning three or maybe even four weeks. I’ve seen teams just stick to their cadence and plan on completing far fewer stories. Recently I saw some teams try an interesting experiment where they abandoned sprints and teams for those weeks – instead, they took the opportunity to work on their tech debt backlog and pair/mob with people they don’t usually work with. There’s no “right” way to handle the unusual circumstances but I would recommend resuming the regular cadence as soon as possible.

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”.

Retrospection:
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.

Anti-patterns:

  • 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.

Scrum doesn’t work for us

Hearing a team say “Scrum doesn’t work for us” can trigger a negative reaction, based on an assumption that the team doesn’t understand Scrum or isn’t doing it right, but it could be a positive sign – maybe the team is growing and needs to move beyond “Scrum by the book”.

Scrum can be a good starting point because it provides structure and guidelines on how to “do” Agile – the Scrum Guide specifies roles, artifacts, and events. It specifies pillars (transparency, inspection, and adaptation) and values (commitment, focus, openness, respect, and courage), so it also tries to instil a mindset of “being” Agile. Scrum’s definition states “Scrum is simple” and “purposefully incomplete”; it is not intended as an endpoint but as a stepping stone on an Agile journey.

But rather than say “we’ve outgrown Scrum” and throw it away, this could be an opportunity for the team to inspect the way they work, consider which aspects they would like to change, and then run experiments to try to move towards where they want to be. That might sound like a retrospective, and that’s not an accident – effective retrospection is, I believe, the engine that powers change. If, for example, a team identifies the way that they collaborate during a sprint as something they could improve then they may decide to try pairing for the next couple of sprints. After those two sprints, they should ensure they discuss collaboration in their retro and whether pairing is helping – it could be they decide to extend the experiment, try something different, and adopt it permanently as part of how they work.

Another example could be to move towards kaizen (continuous improvement); maybe the team decide it’s working so well that they decide to drop scheduled retrospectives from their calendar. A purist might ask if you are still doing Scrum if you aren’t doing everything in the Scrum Guide; as a pragmatist, I would be pleased to see the team grow and wouldn’t care what they call it.