We should never work on assumptions but we definitely should work with assumptions.
A PO I once worked with used to threaten to slap us if we ever used the words “I assume”. We did a lot anyway and thankfully we never got slapped
His point was that we should never, ever, work on assumptions because it means we will likely get something wrong and do rework.
This might create a fear of assumptions though, which is lethal because really, any fast work we do, is done by heuristics. Previous experience and generalisations that help us make quick decisions. This allows us to assume things and prioritise effectively (although sometimes wrongly).
Poker planning
An excellent example of how to work with assumptions is poker planning.
If you haven’t heard of it, to put it simply, it’s about estimating work using numbers, hiding your estimate like you would your cards in poker and then showing them to the group at the same time.
This avoids what is called the anchoring effect where one person (the first estimator) sets up an expectation of the range of estimate by giving their estimate first.
Many teams I’ve worked with use this technique to agree on an estimate but really, the point, especially when we use it to avoid anchoring, is simply to highlight differences in estimations. Why is this important? Because it highlights different assumptions.
Make assumptions explicit
Once we know that you and I have a different estimate of how big a task is, or how impactful or risky. Whatever the variable. We can discuss why. What do I assume differently from you?
This usually highlights gaps in skill, knowledge, risks and much more. Let us look at an example.
Yui is a PO and David is a dev on the team. They are talking about implementing a like feature. Yui says it’s an easy 3 because it’s just a button and David thinks it’s a 5 because we need to save if it has been clicked or not for each user.
They share this to each-other and this makes Yui realize that she forgot to mention that we also need to count it everywhere which David then raises is another bit of work.
Honestly, it can feel discouraging at times when tasks grow so quickly in size once we start to talk about the assumptions. However, it is far worse to deliver late or the wrong thing. If we agree on the assumptions we then talk about what is important to do or not.
It’s worse when we agree
In a sense, when everyone agrees that “this is easy” it can be worse than when disagreeing. It might be that the task actually is easy, but without explicitly having a reason to highlight why it is easy we might be thinking of two completely different ways of what we are about to do.
The five why’s is a good tool to avoid this. Allow someone to explain why this is easy and you’ll get the assumptions out there in the open again.
Don’t work on assumptions
Today I’ve shared why we should not work on assumptions. Instead, we need to clarify them and make sure they are no longer assumptions. Or at least that we can mitigate their risk, sometimes we have to work with what we have.
Once we have raised our assumptions and clarified them (maybe even tested them) we must make sure to take a note of it. Because two weeks later, that question will undoubtedly come “why did we do X again?”.
I keep rigorous notes for times like this, every meeting goes into either Confluence or my journal. It isn’t just because my memory is swamped, to say the least, but generally because everyone forgets. It’s a tedious job but even if short, put a link next to your assumption showing why it’s no longer a (risky) assumption but that there are sources for it.