Happy new year my fellow Scrum mythbusters and I hope you’ve all started 2016 in tremendous fashion!
I thought we’d start off the year with what I’d consider to be one of the most toxic and prevalent myths that I see out there in the Agile world that leads to some seriously dysfunctional thinking.
So, a question that I get asked a little too often for my liking goes a little something like this: “If my team does not complete everything that they committed to in the initial Sprint Backlog then is this what we should call a failed Sprint?”.
For me, that is an overly simplistic way of looking at the situation and ties back to what I was speaking about in part 6 when referencing the Sprint Burndown chart.
To tackle this one let’s explore where the myth found its origins. Back in the day, the Scrum Guide spoke about the initial Sprint Backlog as being a Sprint commitment. We can trace the etymology of the word commitment (in the Scrum context) by going back to Ken Schwaber’s early Scrum book where this term was broadly introduced, the intent of the word commitment was that the “team committed to do their best”. However, over time, this word commit took on another meaning in many parts of the so-called Scrum world with many misinterpreting it to mean a commitment etched in stone which if not delivered upon would indicate a failure worthy of medieval torture!
The simple fact of the matter is that there is only one time that we have perfect knowledge about any particular requirement. And when is that? Well it is when it is completely done and dusted. As such, based on this premise, even a plan for a short ten-day period is susceptible to unknowns and this gives rise to reality, that being a plan can never be a guarantee of the future.
So to address this in part, the latest Scrum Guides have deprecated the word commitment using the less misinterpreted term of forecast. But nevertheless some people really need to be able to categorise a Sprint into success or failure. So, I actually give them a different definition of failure that they can apply if they feel they must, because I actually do believe that there is such a notion as a failed Sprint.
80% complete can mean very different things…
So let’s paint two scenarios: A team during Sprint Planning forecasts that they will complete five Product Backlog Items. Now during the Sprint they work hard but a few things go wrong and they end up nearly finishing all of them. In fact all of the PBIs are roughly 80% complete.
Let’s now switch to another team that also predicts that they will complete five items. They work hard, and again a few things pop up that weren’t expected, resulting in the fact that they only ended up completing four out of the five PBIs. Both teams did not achieve what they had forecasted and in fact, both teams only completed 80% of their target, yet in my eyes, only one of them failed. Do you know which one? That’s right. The first team failed. Why…? Well because at the end of the Sprint the first team delivered NOTHING that was potentially shippable and/or validatable when they certainly could have. If this team had swarmed just a little bit, they most certainly could have completed at the very least a few of the Product Backlog Items in the same way that the second team did.
Less starting and more finishing!
Starting lots and finishing nothing when there was the opportunity to finish at least something is the definition of a failure for those so determined to use that word. The team that only finished four out of five, at least worked together to finish four potentially shippable increments. For me this is not a failure. Sure this team should use their Retrospective wisely to determine why they were unable to achieve what was forecasted in an attempt to learn for the future. Perhaps there was something that they could improve upon and perhaps not (for example if a couple of team members were sick for a few days or similar).
Now don’t get me wrong, we certainly want to do our very best to deliver what was forecasted but we should not do this at the cost of underachieving.
Let me give you an example. If you said to a team that each member would receive a significant bonus if they are collectively able to constantly deliver on exactly what was forecasted in the original Sprint Backlog then what would happen? I’ll tell you what would happen. You would get exactly that. Beautifully packaged up Sprints that mirror the Sprint Backlog forecast exactly to the hour.
But what else would you get? You would start to generate a team that thinks so conservatively that effort will not get maximized and the team will never leave their comfort zone for fear of over-extending and not delivering. Is that what we really want? Teams that play it safe and create inordinate amounts of buffer to make sure that an artificial target is met is certainly not what I’m after in a great Agile team.
The real point of the Sprint Backlog
I want to use the Sprint Backlog as a guide and a way for us to focus our planning for the near horizon, as well as a way to work out how as a team we can swarm to deliver product increments sooner and more effectively. The closer to the forecast the better as it hopefully means that we understand our problem space well, but this should not be at the cost of the team giving sandbagged estimates full of caution.
The reality is that I don’t want my teams delivering to their forecast 100% of the time. If I see this occur, it means that effort isn’t being maximized and there is probably a culture of fear. Hitting the forecast most of the time, even with a mature team is good enough for me.
Sometimes it will be over, sometimes it will be under, but so long as we are doing our best to anticipate reality and we are using our Retrospectives to continuously learn from what goes well and what does not necessarily go according to plan, then I’m generally happy 🙂
Onto the next one!
Once again, I thank you my fellow mythbusters for joining me on the tenth leg of our truth-revealing journey. See you next time when we tackle the next Scrum myth!