Blog

Sprint issues – when sprints turn into crawls

11

As Eisenhower famously put it: “Plans are useless yet planning is indispensable”. There is a great deal of wisdom to this and apart from war, nowhere does this truism reflect more than in the software development world. This is a primary reason that Scrum and other Agile frameworks came into being. Although the frameworks offer flexibility and provision for change, even a two week sprint plan can quickly unravel.

So what can go wrong? Well although certainly not an exhaustive list (I could write a small book on the matter) there are a few sprint issues that I will cover:

  1. Team overcommits – how do you roll user stories (and other product backlog items) into the next sprint?
  2. Team undercommits – should you add new user stories mid-sprint?
  3. External impediments – how should these be reflected in the burndown chart and velocity?
  4. Product Owner changes – should you allow them to remove, add or significantly modify the sprint’s user stories?

The team overcommits

This is quite a common sprint issue and can be caused by mis-estimation or issue 3 (external impediments) above. The way I deal with this situation from a planning perspective is to:

  1. Acknowledge that the product backlog item was incomplete and as such, its story points don’t count towards the initial sprint
  2. Move the product backlog item into the subsequent sprint
  3. Create ‘clones’ of the tasks that were incomplete and move only those into the subsequent sprint. Obviously you will need to reset the task estimate and remaining time even though it is a copy of the original task. By doing this we can historically identify what work was completed in each sprint.
  4. Subtract the remaining hours for the outstanding tasks from the team capacity for the subsequent sprint
  5. Plan the work for the new sprint with a reduced capacity due to the incomplete tasks from the earlier sprint (assuming of course that the Product Owner still considers these left over tasks to be of high priority)

The team undercommits

To your surprise, all product backlog items are completed, tested, ready to deploy and you still have two days to go *shock horror*. But before everyone starts patting themselves on the back and strutting around, it should be acknowledged that whilst this might seem like a great achievement, it is actually more symptomatic of inaccurate planning and estimating and/or a lack of typical sprint impediments. So what do you do when this happens? Should you immediately end the sprint and plan for the next? Well I recommend against this. A fundamental tenet of Scrum is to maintain a standard sprint length which becomes the cadence of the project and without this standard rhythm, your velocity becomes meaningless.

Instead, I recommend you conduct a product grooming session which in this case acts as a cutdown sprint planning session for the small amount of new work that could possibly fit into the remaining time. If the new product backlog item(s) get completed before the end of the sprint their corresponding story points will count towards the velocity and you will likely end up with a higher than average velocity for this particular sprint which is fine.

Impediments and blocks

We define an impediment as anything that takes time away from the allocated six hours (in our case) of daily project work per team member. It is important to capture and track these impediments and how long they take as these often form the basis for your sprint retrospective. It’s so important, I have even devoted an entire article to dealing with impediments.

I’ve found that there are two common types of blocks; task blocks and general blocks. A task block as the name implies, is typically caused by an incomplete dependency that stops the progress of a task being worked on although it doesn’t stop the team member from moving on with another task. We signify a task block by spinning the corresponding post-it note 90 degrees so that it looks like a diamond. This makes the task stand out and prompts us to discuss it during our daily stand-ups.

A general block is more serious – this occurs typically when there is an environmental issue stopping a team member from working on anything. This is where the ScrumMaster needs to act immediately to remove the block because if you don’t, your burndown chart is going to quickly start to flatline.

Product Owner changes

Finally, we have the situation where the Product Owner decides to remove, add or significantly modify the sprint’s user stories. You might be saying to yourself, “Isn’t the ability to change course on the fly what Scrum is all about?” Well not quite. Scrum certainly provides provision to change product backlog priorities mid-project however this needs to occur between sprints and not during them. I call this concept, ‘fixed flex’ i.e. fixed lockdown during the sprint to provide the team with stability and focus whilst offering the the Product Owner flexibility around the sprint to be able to respond to change.

What this means is that the sprint backlog’s user stories should not change mid-sprint unless something drastic pops up that can’t wait until the next sprint planning session i.e due to this change the currently scheduled work will be rendered meaningless and/or useless. Should this situation happen often? No it shouldn’t, but it certainly can happen and no doubt you will come across this situation in your travels. So what do you do? Well, this situation calls for the much maligned abnormal sprint termination. This is not a good thing. It has several negative derivatives including but not limited to, deflated morale, lost momentum and additional administration time as you will have to start your sprint again. This includes conducting a whole new sprint planning session. The bottom line is that there should be a very low tolerance for killed sprints and the Product Owner really needs to ask themselves whether their requirement can wait until the next planning session. That being said, we need to accept the fact that exceptional circumstances will occur and this option is there if you need to break the ‘safety glass’.

So there you have it; rarely do plans work out exactly as initially expected (especially in the software world). The important lesson to learn is that we need to gather as much data about these speed humps as possible so that we can constantly inspect and adapt our processes and start bridging the gap between theoretical planning and ‘in the trenches’ reality.

Now it’s your turn. Have you encountered any of these issues during your sprints? How did you deal with them? I’d like to hear whether these shortcuts worked for you or how you’ve adapted them to suit your unique situations. Drop me a comment below.

If you liked this article, you can:
Subscribe to this RSS feed!


About the author

Ilan

Ilan

Director at AxisAgile

I’m Ilan Goldstein and I’m a director here at AxisAgile. I’m a Certified Scrum Trainer and the author of Scrum Shortcuts Without Cutting Corners.

Find out more about me or get in contact with me by using the social buttons. I also respond to comments below.

Ilan

Ilan

Ilan

Latest posts by Ilan (see all)

  1. Rajesh
    Rajesh12-05-2011

    Thank you Ilan for some great ideas. My team is having similar issue to “the task estimates were incorrect.” After release to customer, we are creating a “placeholder” task in the next sprint in case for support and urgent fixing from the release but we never know how much will be required so we assign hours roughly, but almost always when were wrong the sprint fails. How to overcome this issue? If estimate longer, then canot commit to enough features for next release.

  2. renier Cronje
    renier Cronje08-10-2012

    If you have a new requirement whcih derives from a bug which there is no previous matching requirement or story.. Do you create a new story for that requirement? Or do you define it as an issue?

    Renier

  3. Surya
    Surya11-23-2012

    From an incomplete story which was partially done in a sprint, would you advice to give full story points when its completed in later sprint or revise the story point every time story comes back to product backlog.

    • Ilan Goldstein
      Ilan Goldstein12-07-2012

      Hi Surya – I recommend you move the story to the next sprint and count the entire set of points towards the sprint that it is completed in.

  4. Amie
    Amie01-25-2013

    For situations when the team overcommits and they decide mid-sprint that they cannot complete a user story, if you move the story from the sprint, would you back fill it with other stories from the back log?

    • Ilan
      Ilan08-21-2013

      Hi Amie – apologies for the delay. I intend to be much more responsive now that the book is finished :) To your question, If you over commit, I recommend that you try your best to do as much as of the requirement as possible (even if you don’t quite finish it) rather than switch it out for a smaller lower value item. Use your retrospective to determine how you can potentially avoid overcommitting next time.

  5. SM
    SM03-04-2013

    I heard from someone that SCRUM don’t support change during sprint.

    Does it mean if we need change whatever reason (business or technical limitation and we cannot wait until next sprint) we have to drop and start the new sprint?

  6. Deepak
    Deepak05-28-2013

    Thanks for a very pratical and apt article on this topic. I’m sure many folks similar heartaches and its good to know what choices can be made. I have a query on Story Point estimate. In our requiredments management tool, we do the backlog tracking in the form of user stories as well as capture details on the task level burn down. There are different stages where one can realize that the sizing done during release planning may not be sufficient as its relative and with some unknowns. Should the team be allowed to update the sizing of user stories during sprint planning and/or sprint execution? I’ve read different opinions from different folks on this topic. Some of them are in the favor of making this correction as it’ll help the team use that data for planning subsequent sprints and will not project velocity that’s based out of unknowns. Some of them feel that it should not be changed as it defeats the purpose of having relative sizing that should balance out over a period of time.

Leave a Reply