We started rolling out Scrum across our engineering team this year and we’ve seen some great success so far. When building software, the “when will it be finished” question is always looming in the face of Product Owners.

Attaching deadlines to Scrum is possible. It can, however, be complicated when it comes to committing to meet those deadlines. Throw new products, new teams and new codebases in the mix, estimation is difficult and deadlines become harder to achieve.

Scrum doesn’t really facilitate deadlines. However, Scrum can be used to help determine what a team can achieve between the start and deadline date.

Don’t get me wrong, deadlines are good! If you don’t shoot for something, then it’s probably going to take twice as long. A little bit of pressure is a good thing.

The key to meeting a deadline in Scrum is a combination of finding the right mixture of velocity and scope. If you’ve got too much scope or not enough velocity, there’s just no way a Scrum team is going to reach a deadline without working huge hours. This leads to fatigue and burnout and your Scrum Masters will be putting out fires. No one wants this.

When to give a response on whether a Scrum team can reach a deadline is something that rattles around in Product Owner’s brains. We don’t want to give one too early when we don’t really have anything to go off. If we make a guess, there’s a good chance it’ll probably take longer than we thought. There’s pressure. This is just setting everyone up for failure.

I believe there are 4 “layers of certainty” (credit for the name goes to Daniel Irmler 🙌🏼) that we need to answer the “when will it be finished” question. It’s never going to be perfect but the deeper you go, the better the estimation and the more educated your answer will be.

You can use these layers to help you with the type of language you use to communicate with stakeholders. We don’t want to go throwing out empty promises and we want to leave room for the unknown. How we communicate this and the language we use is key.

Visionaries and stakeholders must understand what you need to go through to give a good answer so I encourage you to educate them on these 4 layers.

I’ll be totally honest, I don’t have this totally down to a fine art and I’m still learning. But here’s what I’ve learned so far.

“Go and build xyz” they say! The big vision is put out there and everyone is excited about it! The engineers in the room instantly start ticking over in their brains all the things they’ll have to consider.

At this point giving an estimate on how long it will take is a huge stab in the dark. I’d refrain from making any guesses here.

The next stage is to dig deeper and really understand what you are building. This is where getting with the right people, understanding who you are building for and what problems you are trying to solve is going to help.

You can then write out user stories to map out the whole product.

This will now give you better insight into the size of the product. But you’ll still be guessing pretty high level at this point. I’d keep digging into the layers before giving an estimate.

Now that you know what you are building, what dev team are you going to pull together?

If it’s an existing dev team working in an existing codebase already doing Scrum, you probably have an accurate velocity. Great!

If it’s a new team or new codebase, you can make some guesses on velocity but you’ll be taking (hopefully) an educated guess even if you have some stats to go off. For instance, if you have an average of 10 story points per person per sprint on other products you run on Scrum, you might be able to use that as a benchmark.

Estimation is still going to be hard at this point because we still don’t really know the size of what you’re building until you dig deeper.

We now have scope and an idea of what velocity we might have. This layer is where estimation becomes reasonably possible! Hurrah!

Your dev team can guess story points for each of the user stories based on the effort involved. Ideally, it’d be great to start breaking down some of the higher prioritized user stories to get even more accurate.

Take into consideration that your dev team is going to underestimate a lot of the user stories. I have this thing in my mind where it always takes twice as long as you think to build when you’re first starting out.

But you can now start doing simple maths to work out how long the product is going to take based on the total number of story points and the velocity of the dev team.

You will want to give yourself a little buffer on the estimation in case something doesn’t go to plan or blows out! I can almost guarantee it will. I’d rather get the product done 2 weeks early than 2 months late.

Yes, you can make an estimate here but really, there are still unknowns. My advice would be to take the “under promise and over deliver” approach and overestimate the time needed. This may force you to cut back scope just that little bit more.

Now we have all the data we need to make meeting a deadline much more possible. Chances are the 4 layers have given you insight into the inevitable - it’s going to take longer to build than what the deadline allows.

So at this point, you have three options:

The great thing is you can go back to the visionary leaders and stakeholders wanting the products done by a certain date and put it back in their court.

A true understanding of velocity and scope only comes with time.

A few or so sprints in you’re going to start seeing a trend in velocity and gain more insight on the scope as tasks are broken down.

Each sprint you’ll be able to assess whether the scope is too large for the amount of velocity. This gives Product Owner’s again power to go to stakeholders to get their feedback on whether we take longer, reduce scope or hire more engineers.

If you’re going faster than expected, just wait. Don’t put your foot in it and say it’ll be released sooner. Anything can happen. If it does go faster and you get it out 4 weeks early, then you’ll look really great!

This is why I love Scrum. Constant assessment and evaluation.

There is no silver bullet but velocity + scope can help you estimate when a product might be finished.

I’ll be sure to share more as this is put into practice and as we grow and learn from our mistakes.

Originally posted Nov 27, 2019.