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!