Think in Deliverables, Not Just Sprints

Project Management | Agile

Let’s imagine you and your team have just started on a new project, perhaps to create a new mobile app for your company. You have some general idea of the order in which features will be completed, and that you’re going to start by allowing users to log in to the app.

You arrive at the conclusion that this authentication system will take about 3 weeks to implement. Accordingly, you and your team decide to take on a 3-week sprint, provisioning enough tickets to fill this interval. So far, so good.

Then, 3 weeks pass by. Invariably, a litany of unexpected complications have arisen and it turns out you’re nowhere close to finishing the tickets in the backlog. At this point, the second sprint is due to start and you need to decide what to do next.

Here, is where I think it often starts to go wrong. Designing software is complex, and encountering unexpected complications is, well, expected. It’s not necessarily a problem that we didn’t accommodate for these unknowns in our estimation. What can be a problem however, is if we attempt to resolve this situation in a way that compromises the long-term quality of the product we’re building.

Too often, teams will be so driven to be able to demonstrate “forward” progress in each sprint, that they will attempt to catch up by effectively scrapping anything that’s not a “priority”, so that they can move on to the next feature. What’s no longer a priority in this case? Well, that tends to be those tests you intended to create, that documentation you were going to write or that refactor that you once thought was necessary.

Of course, all these things are actually important, probably just as important as that next feature. All you’re doing by removing these tasks is creating technical debt that you’re inevitably going to have to repay at some point. Sometimes, taking on a bit of technical debt can be the right decision at the time, but if this is happening almost every sprint, that’s going to translate in to a huge amount to pay back in the future. Likely, taking far longer than it would have done to just address the issues upfront.

Ultimately, that’s the point of this article: that too heavy a focus on having “productive” sprints can lead to poor code quality. It creates a scenario where it’s far too tempting to ditch any work that doesn’t result in something clearly tangible, something that you can show off to your product owners. My “solution”, if you could call that, only really amounts to a switch in mentality. I’m not suggesting that you stop having sprints, but that you consider deliverables as your main point of iteration instead.

What do I mean by a deliverable (or milestone)? It’s just that current goal we’re working towards, some individual feature within the larger scope of the project. In the case of our example, one deliverable would be our authentication system (though in a real project, you may want to split it up even further than this). When we’re working towards a deliverable, we should always try to make sure it’s as complete as possible before moving on to the next one. That is, you’ve written tests, you’ve gotten feedback from your product owners, you’ve refactored those bits of code that you now realise could be done slightly better, and so on.

Fundamentally, a project is successful if the deliverables were successful, not the sprints. Yes, you may need to remove certain aspects of a deliverable at some point, particularly if you have hard deadlines to meet. However, you should always try to ensure that if something is getting removed, it’s getting removed for the right reason. Not writing tests because you’re worried it will sound like you haven’t got that much done in the sprint, probably isn’t a good reason.

The way I prefer to do it, is to work on one deliverable at a time. We build the backlog based on a deliverable, and we don’t move on to the next one until it’s as complete as we can reasonably make it. When having discussions about the project with product owners, try to focus the discussion around the deliverables you’re working towards, rather than what you’ve managed to do in any particular sprint. Hopefully, being able to frame the discussion in this way will prevent the temptation to discard tickets that might not sound as attractive. We still work in 2-week sprints, but only really to act as an interval at which to have regular retrospectives.

To conclude, sprints are a core element of any agile project. However, you should be wary that underestimation of the sprint backlog doesn’t result in accruing a large amount of technical debt by abandoning any work that doesn’t correspond to a visible feature (tests, refactoring, etc). Consider adopting deliverables as the main iteration focus and framing your discussions around those, instead of sprints. Remember that for a product to be a success, it’s your deliverables that matter, not sprints.