Can you fail a Scrum Sprint?
Lets set the scene, it’s the first Sprint Review for a new project. The Product Owner has only ever had experience with waterfall projects. You tell the PO that you completed 3 of the 5 stories. Her response — “So we failed then.”
Can you fail a Sprint?
Yes, if you’ve set your expectations such that success is measured simply by how many PBIs where completed. Is that a good measure of success? Personally, I think it’s a terrible measure of success.
Here’s the first two definitions of failure from Dictionary.com:
1. an act or instance of failing or proving unsuccessful; lack of success
2. nonperformance of something due, required, or expected
The first definition is straight forward, a lack of success, I’ll come back to this later. The second is more interesting, the nonperformance of something due, required or expected.
So here’s the rub. If you treat your Sprint Planning and your Sprint Backlog as an agilified Gantt chart, then yes, you can fail a Sprint. But you’re missing out on one of the key tenents of agile — that by failing fast we learn, and by learning early we setup ourselves up for future success.
To me, the only way you can fail a Sprint is if you learnt nothing from it. Even if you complete no PBIs, you can still learn from that. You learn about unforeseen impediments. You learn about technical challenges you weren’t aware of. You learn that the office is a really noisy place and the internet is really slow.
But you don’t fail.
Coming back to the first definition of failure: lack of success, I believe in developing software with an agile mindset. This means that your definition of success must reflect that. We do iterative development so as to regularly check in on the diection we’re taking and pivot if necessary. But the only way we know to pivot is by learning more, so as to make better decisions.
In essence, whenever we’re building a new feature, or adding new functionality, we set off into the unknown. Sometimes we can predict what will happen, based on past experience, but often we encounter new and unforeseen issues. This is ok. These are learning opportunities, things we must consider in the future. Learning about these early is actually only going to increase the chances of the project succeeding.
But deadlines?
The thinking goes along the lines of “if we didn’t hit this first deadline, then we’ll be late on the project!” Well, yes … if you stick rigidly to the project plan outlined in the Gantt chart and view Sprints as milestones on that same chart.
Only problem is, real life doesn’t follow Gantt charts. That’s why we do agile development. By inspecting and adapting, we have the ability, on day two of Sprint 1, to say “You know what? We’ve just found something that will slow us down. Should we continue on, or plan a work-around?”
That’s on day 2. If we had followed the original project plan, we would be reaching week 6 before the alarm bells start ringing.
Better still, on day 2 we may discover something that actually means we can achieve a whole lot more that we originally thought possible! But we still need to stop and assess where we’re at and where we want to go, then adjust the plan accordingly.
What to do?
We do agile because it enhances transparency in the process. Because it enables us to be, literally, agile and pivot to address risks, but also to grab opportunities as they arise.
So next time you feel a Sprint isn’t going well, remember to focus on the things you are learning. Why haven’t things gone well? Was it technical issues? Did you not address the risky stuff first? Are there people issues? Don’t forget, that’s what your retrospectives are for.
Sometimes we learn a lot more from a Sprint in which no work was completed than we do from a Sprint that goes smoothly.
Don’t panic. This stuff happens.
What about that PO?
For her, 3 tasks completed from 5 looks like failure. That’s probably what she’s used to thinking and in fact what she herself has been told in the past. This is a great opportunity to help someone else understand what agile is about. This is a great opportunity to help someone else gain a better understanding of their role and perform it a little better.
Talk it through and let them know everything you learnt. Let them know this will now feedback into the backlog and you’ll have a much better idea of whether your MVP is achievable.
It might take a few Sprints, but the transparency of this approach builds trust. Trust opens up the communication channels. One you’re communicating well everyone benefits.
