Estimating Unknown Scope is Impossible! Here’s how to Do It
Most projects will miss their original deadlines. You heard that before, right? And there is one particularly sticky type of project. The kind where you just cannot see what’s ahead of you. It could be more bugs than you can fix. Unforeseen technical issues. Or massive scope creep. In those situations it’s virtually impossible to estimate a delivery date. So I wanted to share a nice little trick with you.
Spoiler alert: it’s all about risk management
The sticky conversation
Manager: Can you deliver the project by the end of the quarter?
Devs: Maybe…?
Manager: OK. So what do you need to do to see if we can?
Devs: Difficult to say. Oliver keeps asking for more features. We uncover new stuff as we code. And the bugs. The bugs! We keep finding more than we can fix.
Shift the focus to what you can do
You cannot say how long it will take to finish “stuff” without knowing what “stuff” is.
That’s madness.
You might not control the scope ahead of you. True. But you can look back, identify what the team has delivered, and assume they will do it again. That will give you a baseline to what is possible. What you need is to translate that into risk.
Establishing the likelihood of being late
You want to do this exercise with the team. Here’s how:
1. Show the team how many requirements (bugs and features) they completed in past weeks 2. Ask them... - How many requirements can they confidently deliver each week?
- How many would be a stretch?3. Build a stack chart
Now you need do to some basic maths. For example, say you have 6 weeks left in the project. And the team feels they can easily deliver 8 requirement every week ahead. That’s 48 bugs or features in total. Sweet! And if the team feels 15 as a stretch? That will give you 90 “whatevers” delivered as a stretch. This is powerful! Now plot it.
Here’s how you read it. Say we are in week 2, from the graph we know that if we have less than 40 features and bugs we are safe; anything else adds risk.
You see? You don’t know how many new bugs and features you will have. But when you get to week 2, you can count those. Lookup it up in the chart. And know how likely it is that the team will deliver those.
Great! Now what?
You cannot foresee what the project from hell will throw at you. But now you can easily establish the likelihood of being late. And this is very powerful. It allows you to move the conversation to a place where you have some control. But most importantly it allows you to answer the question in everyone’s mind: “will it be done on time?”
