Experimenting with a better way to estimate agile sprint work
As an NPD team we’ve not really been working in traditional sprints, but as the product has been settling down, I’ve been thinking about estimation of tasks. I must admit, I’ve been avoiding it. All the plannings I’ve been in where people have estimated every story has been lengthy and frustrating.
But estimating is important — it helps us understand:
- How to decide when a project may be delivered so that we can keep other stakeholders informed correctly
- Whether or not a team member needs something that you haven’t noticed yet
- When do your team/team members perform best so that you can retain that environment
What is it definitely NOT for
- Keeping autocratic tabs on how much work everyone is doing in order to punish them
- Comparing team members
Just had to clarify that one.
The problem
As any good designer would do, I started to analyze what the problem with estimating was and what was causing that problem. I found that in times where estimation felt long and unproductive it was because there was either:
- Too much discussion deciding the framework (Fibonacci, shirt size etc)
- Too much discussion on which number/letter each story should get
The root cause of this was that each of the estimation frameworks only focused on how to label, not how to decide which label was best. So every time we tried something it seemed complex to explain and also in order to simplify, that discussion always went to ‘how many days will it take’ which of course is very difficult to estimate.
The first experiment
So I’ve been testing a new way to estimate that helps eliminate some of the discussion and direct the conversation in a productive manner. This solution is a framework for deciding an estimations value that encourages team members to talk about the user story itself rather than debating the numbers/letters.
The framework is based on two principles:
- When estimating, you always have an idea of how hard/easy a task may be even if you don’t know everything yet
- When figuring this out, there is sometimes an element of unknown knowledge that can make your estimations incorrect (i.e. once you dig into a piece of code you realize its harder than you thought) and this tends to make a time-based estimation incorrect
Therefore the framework is as follows:
- How hard/easy is the job
- How much/little do you know about it
The experiment results so far
Of course this is just an idea at the moment and we’re testing it — the results so far are:
- The estimation has been very accurate, allowing us to ensure on time deliveries and better communication externally
- The method applies across disciplines, we’re testing with FSD, FE dev, designers and POs
- Even though the estimation is working well, the one thing that still has to be done is well broken down stories
- We ended up with a range of points for each sprint available because we’re deliberately leaving space for anything ad hoc that comes up — that number is 10–15 per person per (2 week) sprint
- The 2 and 3 boxes sometimes don’t feel right — I’m considering these two boxes being 2/3 depending on the task
- We’re still having conversations about the numbers but they’re not long. This is enabling us to understand each other’s story but not get caught up into a conversation about numbers
- When we have a number discussion, it is often between 2/3 and in that case we just pick the ‘3’ because its better to slightly overestimate and then have space to do more
Wanna hear more about this? Let me know!
