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:
- Team overcommits – how do you roll user stories (and other product backlog items) into the next sprint?
- Team undercommits – should you add new user stories mid-sprint?
- External impediments – how should these be reflected in the burndown chart and velocity?
- 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:
- Acknowledge that the product backlog item was incomplete and as such, its story points don’t count towards the initial sprint
- Move the product backlog item into the subsequent sprint
- 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.
- Subtract the remaining hours for the outstanding tasks from the team capacity for the subsequent sprint
- 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.
If you liked this article, you can:
Subscribe to this RSS feed!
Find out more about Sprint issues by taking one of our CSM training courses.
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.
No problem Rajesh and glad they are of use. I would steer away from this method and instead wait for issues to occur and create separate PBIs when they occur rather than creating placeholders. I suggest you read http://www.axisagile.com.au/blog/planning-and-metrics/incriminating-impediments/
[…] lot of things can go wrong during a Scrum sprint. In this post, Ilan Goldstein makes a list of some common issues in Scrum sprints and how you should deal with them. He recommends to gather as much data about these speed humps as […]
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
Hi Renier, yes I recommend you create a new story for this.
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.
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.
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?
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.
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?
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.
[…] I enjoyed the exploration of this theme inĀ the “Product Owner changes” section of this articleĀ and the “Changing Requirements” section of this one.Ā SubstitutionĀ mid-sprint is a […]
So, the team over commits and moves the story the the next sprint. we’re using TFS to manage the backlog and we’re tracking task estimates and actuals in support of CMMI mandates from our home office. The question is what to do with the remaining hours in the tasks in the sprint that’s ending. Should we zero them out or leave them there to show the tasks as incomplete?
Hi Bill – for your CMMI tracking, I’d leave them there (incomplete), and then replicate the task in the subsequent Sprint with associated time remaining.
What will be happen, if the Sprint terminates abruptly in middle?
Hi! If this happens (should be rare), move the incomplete PBIs back to the Product Backlog, commence Product Backlog Refinement and then ready, go back into Sprint Planning with the new set of Sprint-Ready PBIs.
What do we do if there are a list of tasks on the sprint, but one or more members have no tasks they can work on? We have a team where the current critical items can only be addressed by certain members due to skill set. Therefore, halfway through the sprint, some members have absolutely nothing in the sprint backlog they can work on. In this case, it is acceptable to add items to the sprint backlog so they can keep working? Also, who gets to make this decision? Is it the scrum master?
Hi Jason – until individuals start developed t-shaped skillsets to avoid this happening (https://en.wikipedia.org/wiki/T-shaped_skills), you’ll need to consider this during Product Backlog Refinement and potentially restructure your Product Backlog order to consider these skillset dependencies. In the worst case, sure pull off the PB and the ScrumMaster with PO should assist in the most appropriate selection.