We’ve all b
een there. Someone describes a problem that they want solved (and possibly suggests how they think you should solve it) and in the very next breath asks: “So, how long will it take?”.
Invariably, we get talked into providing some kind of gut feel indication (days/weeks/months/quarters) based on nothing much besides (perhaps) experience. But how often in software do you actually do a rinse-and-repeat of something you’ve done before? In my 10 plus years in IT, never. Never ever.
Unfortunately, we don’t yet work in a world where most people are happy with “we’ll be done when we’re done” so a vague timeline is always needed: if only for coordinating training or the launch email and party. So where does one start?
First, there are some principles/facts-of-life that are important to bear in mind:
1. The cone of uncertainty
2. Some practical examples of the developer cone of uncertainty
3. A good analogy of why our estimates always suck, no matter what data we’ve used
In the beginning….
For me, the first time you can possibly try get a feel for how long your horizon might be, is after you’ve shared the problem with the team and they have had a chance to bandy around some options for solutions. At this point, assuming your team has worked together before, you can try do some planning poker at an Epic level. Pick a “big thing” that the team recently worked on, allocate it a number (3 usually works) and then have the group size “this big thing” relative to the one they have previously completed. I prefer to use a completely random number (like 3) rather than the actual story points delivered for this exercise because otherwise the team might get tied up debating the actual points and not the gut feel relative size.
Now, if you have a known velocity and also know the points delivered for the big thing we already built, you should be able to calculate an approximate size for the new piece and use your velocity to find a date range with variance (don’t forget about that cone!). For example:
– If we agreed our “Bake a cake” epic was a 3
– And then sized the “Bake a wedding cake” epic as a 5
– And “Bake a cake” was about 150 points to deliver
– Then “Bake a wedding cake” is probably about 3/5*150 = 225 points to deliver
– Which means you’re probably in for 225/velocity sprints (with 50% variance)
At the very least, this should help you pin-point which year and perhaps even quarter this thing is likely to be delivered. (Don’t make any promises though – remember the cone!)
When we know more….
Now, if you’re doing things properly, your team will groom the big epic and slowly start agreeing on small to medium stories and perhaps even slices. Ideally you’ll have a story map. At some point, you should have a list of stories (or themes or whatever) that more-or-less cover the full solution that the team intends to build. At this point, it is possible to do some Affinity Estimation, which will give you another estimate of the total size (in points) relatively quickly that you can sanity check with the help of velocity against your previous guesstimate. If you’re working with a new team and haven’t got a velocity yet, this is also the time when you can try ‘guess’ your velocity by placing a couple of stories into two-week buckets based on whether the team feels that they can finish them or not. This article explains this process in a bit more detail.
Keep checking yourself…
You will probably find that when you do Affinity Estimation that you will still have some biggish stories in the list, which is OK. Over time as these break down, it’s probably a good idea to repeat the exercise (unless you’re so great at grooming that your entire backlog has already been sized using Planning Poker). Until you have sized everything in detail to ready stories, Affinity Estimation is the quickest way to determine a total remaining backlog size that is reasonably useful. Over time, if you maintain your burn-up, you’ll be able to track your progress and re-adjust plans as you go along.
Did you find this post useful? Have you used these techniques before? What other techniques have you used to try build a view of your release roadmap?
Reflections of a Scrum Master 
Indeed I have used affinity estimation before, as you’ll recall I’m sure 🙂
It is one of the more useful tools when it comes to estimating an entire backlog / project the first time around, it relies on good facilitation though; I’ve seen it used first hand by others and fall apart due to the facilitation. It’s also not particularly useful for backlogs that are largely estimated already of course, the team just ends up looking at you funny if you go through yet another estimation exercise when in their minds it has already been settled.
Of course ultimately it is still an estimation exercise, hence the 50% variance, something to constantly remind others of …
Thankfully I’ve not yet been in a session where it fell apart! Based on your experience, what are things to do or not do when facilitating an Affinity Estimation session to prevent this happening?
It was quite interesting watching it play out, two simultaneous sessions, same prep and same goals, different facilitators and yet entirely different outcomes.
Personally I think the difference was one of understanding the technique well enough to stand up to scrutiny. It was a tough crowd with many senior people from multiple consultancies so the questions were flying: “why do we need to do this”, “what is this infinite scale for, let’s just use a 3 point scale” etc and the facilitator wasn’t familiar and / or confident enough in affinity estimation to answer those properly, so it descended into chaos.
In the other room, another facilitator, granted a more experienced one, faced the same situation, but was able to take the tough crowd on the journey with him and achieve the desired outcome because he intuitively seemed to understand the intention behind the various steps much better. So I guess one thing most definitely not to do is attempt it in the first place before you’re comfortable you can answer challenges, what also would have helped is prepping the attendees beforehand, I’ve always done that and in this case it wasn’t done, many of the questions would already have been answered in prep material.
btw I was not one of the facilitators in this case, just an observer 😉
[…] and business stakeholders were getting twitchy (“how long will we take?” – see How big is it?) and it was time to use our data to create some baselines for us to use going forward (and, as a […]