In the world of Agile, one of the core concepts is the idea of a User Story. There are many different pieces to a user story and the structure can change from team to team. However, each user story should always cover at least:
- Who is the “user” or role is the story representing?
- What is the goal of the story?
- Why does this make our product valuable?
Many other stories might list acceptance criteria or fine-grained requirements details (which I advise).
But each user story should also have an estimate.
An estimate is simply a way to gauge the amount of effort required to implement the story. When you estimate a user story, you aren’t signing up for a deadline or a deciding the exact of time a story must be completed in. Instead, you are simply making a thoughtful and informed decision about how much effort you think the story will take.
Its sorta like a hypothesis: its an informed guess. You look at the evidence about how long similar stories have taken, determine how divergent the current story is based on your knowledge of the codebase, and estimate accordingly. You then do the work, record how long it actually took the finish, and use that information to inform estimations on other stories.
Sounds easy right?
Well, its supposed to be.
The trouble with estimates is that, well, they are estimates. There is no exact science that says a story should be a certain size based on some input parameters. Even you spend all day looking at outliers and create a framework for estimating, it’s still an estimating.
There are some things you can do, however, to help you and your team get better at estimating.
Agree On Estimate Values
Ironically, the biggest point of contention isn’t with the process of how to estimate or what to estimate, but more on which values to use. If you have heard of Story Points, this is where they come in.
A Story Point is basically a single number that is used to define the amount of effort for a user story to be completed. A story point does not, however, concretely tie to any quantitive amount of time like hours or days. They just are.
What makes them powerful is how they relate to each other. An 8 point value is greater than a 5 for example. And that should be all you really need to know. It allows you to group stories into similar buckets without having to strain to decide if it should be 2 days or a 3-day effort.
In story points, you would generally have a range of acceptable point values, say 1 to 10. This allows the team to have a range of options when estimating a story so as to not have radically different understandings of the effort associated with each one. If the relationships are linear, then you wind up with the same problem as estimating time. What is the difference between a 2 and 3 or a 3 and 4? Well, the same amount 🙁
That is why I’m a fan of using the Fibonacci series for estimates. Using the Fibonacci series, stories should generally find themselves being grouped into small, medium and large without too much over-thinking. It is a 2 or a 3? Who cares! They are both close to each other and much less than a 5. Is the story bigger than a 5? They just put the next number on it (an 8 by the way) and move on. No need to spend too much time debating.
The Estimation Meeting
The estimation meeting is where you should ideally get all the developers, product owners, and other stakeholders together to perform estimation. This meeting should likely be around an hour long and need to happen only once a week. You can, of course, have more or less as needed, but be careful before scheduling too many or too few meetings.
This meeting should also be managed and lead by the product owner since they have the most in-depth knowledge about what the product needs are.
Start With the Backlog
Ideally, you should have a prioritized product backlog with items that need estimating. You simply take the top story from the backlog, review it, estimate it, and move it to the next “stage” (like On-Deck or Ready for Sprint).
Technical debt items from the team should, hopefully, have made it on the backlog and been reviewed by the product owner and technical lead for the product before estimation as well. This allows the technical leaders to agree on a priority of technical debt alongside product features or bugs.
Tools like Jira, Rally, or Trello can usually make these processes easy and simple. If you don’t have a prioritized backlog, I suggest you do that before attempting to any estimating. Otherwise, the process of estimating is essentially nil since you don’t know how urgent it is or even if the effort is worth it (which is entirely possible of the estimate is too high).
Give Everyone Time to Review
As you go through each story, make sure the team has adequate time to review it before estimating it. This usually means reading the story requirements out loud to the group and verifying the story is still needed. Let the group ask clarifying questions if they need and allow developers or stakeholders with additional insights bring those to the attention of the group.
If the story ambiguities, try to clarify them with the story author if they are present. If the author isn’t present, the group should decide if there is enough information to point it without having those points clarified. Sometimes the ambiguity is if an error message should say “X” instead of “Y”, which is important but doesn’t affect much of the time or effort required to implement the story.
Ideally, much of this process, called Backlog Grooming, should be done by the product owner and authors of the stories. Sometimes this time is hard to get, so it finds itself in estimation, which is totally fine in my opinion. No one wants another meeting on their calendar.
Once everyone agrees on the requirements for a given story and any needed clarifications have been provided, its time to estimate.
This is another place where teams can get tripped up. They might want to use fingers or go around the room stating their number, but each of these techniques introduces their own problems, especially the problem of bias (ie someone basing their estimate on yours without meaning to). I recommend using an online tool that allows team members to enter their estimates without anyone seeing another’s estimate until all are entered in (a tool like PlanItPoker is a good example). Once the team has finished submitting their estimates, you review and pick a final estimate. If everyone “voted” for the same value, then everything is fine – you use that estimate and move on.
If your estimates are different, there are a few things you can do. Some teams like to have a small debate between people who voted differently and then re-vote. Some use the largest vote and move on. Others pick the most commonly voted estimate or closest point to the average of the votes.
In my experience, this is the most frustrating part of estimation. Everyone brings their own bias’ into the mix and you can quickly get caught up into a never-ending loop of revoting that goes nowhere.
What I recommend, and our team does, is follow a few simple rules if we don’t all vote the same:
- Ask if anyone has a strong reason they voted what they did. You’d be surprised how many people don’t have a huge reason
- Re-vote after that first round and heard the positions from some of the members described above
- If we still have a disagreement, but it’s between two story points that are immediately adjacent int he range, take the most common value
- If it’s between more than two, repeat steps 1-3.
Agile purists are balking at this as they read. And that’s ok with me. If an estimate is just an estimate, then the difference between 2 adjacent values shouldn’t mean that much in the long run. Additionally, I’ve found the most contention comes between a story being either a small-medium story to a medium story rather than a medium to large etc. So you aren’t saving yourself a lot of time in that debate – just making your team angry at each other.
Once you’ve either used up all of the available time or estimated enough stories that you need for the next week or so of work, you are done! Great work!
Remember, Humans are Bad Estimators
As a final take away, remember that humans are simply bad at estimating how long things will take. Daniel Kahneman illustrated this via his Planning Fallacy theory. I won’t reiterate all of the findings here, but the core is we always underestimate how something will take. Even when attempting to think through possible problems, we still tend to underestimate.
Don’t let this get you down. Instead, simply accept it and realize that your estimates are almost always going to be a little off. And that’s ok! Over time, your teams and your estimates should get better over time, and you just always plan a little extra time than you think you need.
Look out for my next article that will help you figure out how to use your estimates to track your progress! In the meantime, tell me about any tips or tricks you have come across when it comes to estimating in the comments!