All happy families are alike; each unhappy family is unhappy in its own way.
Leo Tolstoy
When it comes to planning, every product owner wants to live in the two-dimensional world. One dimension would be business value , another one – resources.
It would make prioritisation much more manageable than it is now. Just pick the tasks that give us more value and require less effort, and you'll be fine.
In the previous note, Who Needs Estimation: The Story of Two Backpacks, we used a Knapsack problem as an analogy for this process. Just in case, here is its definition from Wikipedia:
The knapsack problem or rucksack problem is a problem in combinatorial optimization: Given a set of items, each with a weight and a value, determine the number of each item to include in a collection so that the total weight is less than or equal to a given limit and the total value is as large as possible. It derives its name from the problem faced by someone who is constrained by a fixed-size knapsack and must fill it with the most valuable items.
What do we need to do to match this analogy? We need to take all our tasks and map them to the same scale – estimate them.
What do we see in this picture?
The elements look alike, so we're able to compare them to each other:
- Let's assume a spoon would take one story point
- A fork is similar to a spoon. A knife would probably require the same effort. Two story points would be accurate for both of them
- A knife, a fork and a plate... Perhaps the plate is harder to make than the first two – let's put five for it
I hope it sounds sensible so far because I'm oversimplifying. In reality, the mapping looks more like this picture:
The elements are heterogeneous, they have a very little in common – but we still need to put them to the same scale.
Are there any similarities between a dear, a golfer, a flame and a flying saucer? I see only one – they're hard to estimate...
... but we will try
This is how a typical project looks like:
Each task from the second category is dangerous in its own way, which makes it hard to come up with a generic algorithm. But it's not too bad – there are at least 4 big categories, each with its own particularities. I tried to name all of them:
If it doesn't make sense yet, it'll be better after I return to our knapsack analogy.
For those who don't remember, or didn't read The Story of Two Backpacks, don't worry, it's simple.
We were talking about a guy who is moving from Norwich to London (~2 hours on a train). He has a backpack (or a suitcase, or both) and plans to move everything he needs in several iterations.
As I said before, the real world planning is much more intricate than a Knapsack problem, so it's time to demonstrate it.
I will walk through all these types, show you several examples from real projects, and give you some advice that would help you to estimate tricky tasks. Let's start with the first one!
Teddy bear: a m ulti-dimensional problem
As I already mentioned, the original version of the knapsack problem rarely exists in real life because it has only two characteristics: weight and value. Unfortunately, there are much more.
For example, what if you want to take this guy to your new flat in London?
His weight is around 400 grams, so if it was only a matter of weight, you could put 50 bears in your backpack and decorate your apartment in Siberian style.
Unfortunately, if you take it, there is no much space left – maybe only for your wallet and two mugs, but that's all.
Teddy bears are appealing:
- They're easy to carry
- You can do something in the background (e.g. listen to audiobooks or watch movies)
- Usually, it's possible to predict how much time they would take
But there is a big downside as well. The fact that teddy bears are light and don't require any specific skills to carry them may belittle estimation.
Real-life example: writing Selenium tests for a stable product
Advice:
- Remember that estimation is effort, not just complexity. Don't fall into the trap of one-dimensional estimation
- Always check previous teddy bears you carried. How long did it take? Why should it take less this time?
- Distance from the business value when estimating. A sprint doesn't look meaty? Swap teddy bears to something more meaningful, but don't take more than you can carry.
Kettlebell: a problem with side-effects
Time for another example. Imagine that you need to take this luxurious kettlebell with you – would it fit in a backpack?
Well, it would. This would even leave some free space that you probably wouldn't use.
Why? Because it's too heavy.
Yes, kettlebells are smaller than teddy bears, but they're incomparably heavier. But there are a few more differences you should keep in mind:
- Perhaps, not everyone from your team can take a backpack with a kettlebell inside. It's a job for well-trained folks
- It requires full concentration. You can't carry a kettlebell and solve differential equations at the same time. You should always be focused on the process – how to breathe, how to keep your back straight. Otherwise, it's just not going to work well
- It affects your time before and after. Before – you're preparing. Later – your back hurts, and you physically can't do anything else
- You want to throw it on the floor from the moment you took it. Most likely, you will do it as soon as you enter your flat, and it will lie unpacked next to the door
- By the way, about unpacking: expect people to be busy when you need help
Real-life example: optimising performance for a critical piece of an application
Advice:
- Round up when in doubt. If you hesitate between 5 and 8 story points, don't. It's 8
- If the scope is unclear, agree to meet and reevaluate when you have more data
- Make sure you're estimating the whole problem and not only the most challenging part of it. People may lose concentration after they solved the challenge, even if they still have 80% of work to do. Always account on this 80 %
- Pay close attention to all stages of your cycle: code review, testing, deployment, anything you have. If development was hard, expect other phases to be harder as well
- Pair programming works great with kettlebells, but estimation becomes tricky. Two programmers won't be coding twice as fast, even though they have 4 hands.
Antique vase: a problem with no margin for error
Let's move on to the next one. We've just moved a teddy bear and a kettlebell, what do we need now? This fragile vase that costs a fortune perfectly complements this logical series:
What distinguishes this example from the previous ones? Well, a lot:
- You have to keep it safe no matter the cost
- You would like to choose the best time to move it – the rush hour is much worse than 1pm when the trains and buses are empty
- You'd better not take anything else at the same time – all your attention belongs to the vase
Real-life example: legal requirements that your product must meet before the deadline strikes
Advice:
- Estimate antique vases in people, not in story points or time
I only have one recommendation, but it deserves clarification.
If it comes to a critical task with a strict deadline and a non-negotiable scope, we have to focus on it to get it done. Whoever works on it, shouldn't think about anything else.
Should one person be enough to complete the task? Great, give her this task and plan the rest of the sprint as if she is not there.
Need two people? Pretend that they're both on vacation.
Need the whole team? Why the hell are you wasting your time on estimation – start working right now!
65-inch wall mounted TV: a problem with unknowns and dependencies
It's time for the last one.
You want to move your TV panel to the new flat. How hard can it be?
- You need to find somebody to help you because it's too heavy to carry alone. You would also have to sync your plan with this person.
- You need to check with the landlord if you can mount it to the wall. If yes – great, you have all the equipment
- If you aren't permitted to drill the wall, you'll need to buy a stand. You haven't done any prior research yet, so it'll take some time to choose a good one
There may be more dependencies, such as contacting your TV provider or buying an extension cable, but it's already complicated.
Real-life example: Implement "Feature X".
We know the team which worked on a similar feature before, we should be able to use their database. If it happens to be not enough, we need to ask them to create one more database for us.
Advice:
- Keep in mind potential communication overhead
- Use spikes to reduce uncertainty
- When it's impossible to use spikes, estimate different options separately (e.g. for the worst, best and average possible scenarios). If we still need one number, use techniques such as PERT to calculate it. This variant is efficient when we cannot use spikes and can gain new information only by failing different approaches
The last bit
We genuinely wish to reduce estimation to a one-dimensional problem, where only story points (or time) matters, but it's not easy.
We need to not only compare apples and oranges but know how each of them affects our capacity. It makes normalisation complex, but not impossible, I'll cover it in my next notes.
In the meantime, there are several final points as a summary:
- Talk. It's not always easy to notice these tricky tasks, make sure that your team has a forum to discuss it. If Carla gives a task 8 story points, when the rest of the team votes for "3", it's a good chance that you deal with something unusual
- If anything catches your attention, think about what type you have to deal with. One task can share the signs of different categories – a 65-inch wall-mounted kettlebell is very common, but you know what to do with it
- Decompose to eliminate complexity. Do you need to estimate a card for a bugfix you cannot reproduce? Maybe a time-bounded spike can give you more details?
* the photo of cute cats is by Jari Hytönen on Unsplash
Top comments (0)