User Story Estimation Best Practices
User Story estimation is a topic you can read a lot about online, but how do you apply it in a real-world scenario? It is essential to grasp the concept if you intend to make the most of your Events, to execute successful refinement sessions, and ensure each Sprint contains a plan the team can deliver on fully and timely.
What is User Story Estimation?
The purpose of User Story estimation is two-fold. First, it is to set the right expectation with the Product Owner of what the Development Team is going to deliver. Also, for the Development Team, it helps them accurately forecast the size of the effort or the problem.
A User Story should focus on what the customer needs and that individual should write it. It should focus not on the how, but instead, the what. As a blank, I want blank so that I can blank is typically how a User Story begins. From the users’ standpoint, that covers their needs.
The Development Team then asks clarifying questions, so lets set the scene using an example. Say someone asks you to build them a house, and you want an idea of how big should the house be? If you get an answer that is vague, such as “large” or “big enough”, what does that actually mean? You need to dig deeper, so you meet the customer’s needs. If the customer tells you it should be 2,000 square feet, you still do not have enough. Do they want multiple floors? How many bedrooms are necessary? Do they want a garden/yard? These are the details of the User Story that gets added later.
Now that the team knows what they have to build, the Development Team figures out how they execute. The estimate of the User Story is based on the priorities of the Product Owner and complexity which allows the Development Team to figure out how much effort something requires.
It is Not a Due Date Effort
The User Story estimation process does not have any intention of coming up with a due date. There are just too many unknowns. Think back to the house construction, do you know what the weather will do over the next month? Or whether contractors necessary will do what they say, in a timely manner?
User Story estimation allows you to create a flow from one step to the other and also capture the overall effort necessary to get the job done. It captures complexity. If you have two User Stories, one that has an estimate double the other, the Product Owner can help figure out which is the priority, since one will take up more effort to deliver.
Successful User Story Estimation
Before User Story estimation begins, the Development Team gets the idea of how long something will take and throws it out the window. Feeding on the priority of the Product Owner, the process involves every team member estimating the effort and complexity.
User Story estimation is a team effort. You could not just ask one subject matter expert on the team. When you build a house, you should not just ask the electrician, but the plumber, the carpenter, and everyone else involved.
Sorting more significant problems into smaller chunks is also integral. Rather than worrying about if something is an X or a Y, think generic. Using t-shirt sizes can work. Go from small through to extra-large. The granularity is not critical; you want to bucket the User Story listing in like groups. High-level sorting allows you to get the spectrum of work you have and then go from there.
Estimation Tools
You can use a variety of estimation tools to bucket the sizes of the User Stories. Numbers can work, but people get hung up on whether something is a six or a seven if you have a one through nine scale. It would help if you spaced out numbers, use t-shirt sizes, something that separates one from the other.
Starting the User Story estimation and sorting at a higher-level leads to success. Bucket the work so it can fit into the Velocity of a Sprint as well. If a User Story estimates higher than one Sprint’s Velocity allows, break it into smaller chunks of work. Incremental refinement and User Story estimation will lead to delivery of additional value to your customer as the requirement gains sharper focus. In the end, it’s not about the tools, it’s about the process.