Scrum loves deadlines. An end to the holy debate

Source: Dan Regan

For some reason, and in a fashion somewhat similar to Godwin’s law, discussions around Scrum tend to gravitate towards one subject… deadlines. The people exerting this gravitational pull are always of the same opinion, namely that Scrum and deadlines are polar opposites. “Deadlines are relics from the era of Waterfall. Deadlines are to be avoided at all cost. We hate deadlines!”

You actually love deadlines. Yes you do

Let me get that one out of the way quickly: all Scrum practitioners love deadlines. They even impose a deadline upon themselves every two, three or sometimes four weeks. Why? Because you know it works! It forces you to focus on the stuff that really matters, compels you to prioritise and your work and motivates you to get stuff done. Yup, that’s right, the end of your sprint is a deadline.

Got you there, didn’t I? Probably pissed you off even more. Because off course you weren’t talking about those deadlines. The deadlines you dispute are long term deadlines. So, let’s go there.

Long term deadlines

The deadlines debated are long term deadlines, extending beyond 2 sprints. These deadlines often apply to “a project”, “an MVP”, “the alpha/beta/zucchini release”, or any other designation for what usually is a more complex set of new or improved features. Let’s use the term “project” from now on.

As soon as deadlines are set for projects people get anxious and uncomfortable. The most extreme counterargument to a deadline is that it’s unacceptable, because we can’t predict when the project will be done.

“It’s done when it’s done!”

The question is whether with this mindset anything would ever be done at all. Certainly not according to Parkinson’s law. And our own experience in working with sprints and sprint goals shows us that deadlines actually work very well. So what’s the problem with these project deadlines?

The fixed scope fallacy

All projects know three constraints: resources (or costs), scope and time. If you want a project to be feasible one of these constraints should be flexible. Having a deadline implies the factor time is fixed. Often you’ll find resources fixed as well. You likely have a fixed size team and fixed budget.

All this leaves us to play around with is scope. And that’s where things go awry. Because often even before a project is initiated all people can talk about are features and functionalities. And without proper and early guidance things turn for the worse. The project backlog quickly turns into a list of “everything we need”. And sooner rather than later all of that becomes non-negotiable. See what happened there? Now we’re left with a fixed scope.

Goals, commitment … and a deadline

The problem in above scenario, which regretfully plays out way too often, is that two very important concepts are forgotten: goals and commitment.

Instead of working on a fixed, non-debatable set of features and functionalities you should be working towards a goal (or a set of goals). Instead of promising to deliver “everything we need” you should commit to delivering features and functionalities which bring you closer to that goal. And you commit to doing this before a certain date.

This implies flexibility in scope and it’s paramount that this is understood by stakeholders, product owner and team. And don’t make the mistake to think having a flexible scope makes a project easier. I would argue it makes it even harder. It requires a great deal of stakeholder management and focussed and intense discussions.

It’s easier to accept a fixed set of features and probably fail. Way less fun though.

Every conversation between the product owner and stakeholders should revolve around the project’s goal. These conversations should take place on a regular basis. Preferably just as regular as the conversation between product owner and team about the next sprint.

It’s not at all forbidden to talk about features and functionalities with stakeholders. Stakeholders are likely to have great ideas. Just like team members, whose ideas for features and functionalities should be included in the conversation as well. Preferably in the form of user stories, as these are less focussed on the actual feature and more on attaining a user goal.

These conversation shouldn’t be about whether all features and functionalities can all be implemented. The question should be which of the user stories will have the most impact in achieving the goal (or as some put it “has the highest business value”). Work should be prioritized accordingly.

Pick a goal, set a deadline

If you manage to run a project based on the above there is absolutely no reason not to work towards a deadline. It’s even a good idea to do so. Because, just as with your regular sprints, deadlines force you to focus on the stuff that really matters, compels you to prioritise and your work and motivates you to get stuff done! You might even start loving them.

Loved it? Please “love it”!

I’d love you for it! Please press “heart” to recommend and spread around.

Great reads on this topic

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.