Estimating User Stories
Before we discuss estimating tasks, let’s talk briefly about user stories. User stories, also known as backlog items, are Agile artifacts that describe who the user is, what the user wants, and what the value is to the user. While the Product Backlog is owned by the Product Owner, anyone can write a user story. Furthermore, it is the scrum team who owns the Sprint Backlog. They are responsible for sizing and estimating the user stories and tasks in it. If the team needs to know more about the acceptance criteria or the priority of the user story, the Product Owner is there to guide them and order the backlog items according to their value.
One common practice in estimating user stories is by using story points. These are normally numbers in a Fibonacci sequence (such as (1, 2, 3, 5, and 8) and this can be enough for the team to know the relative complexity of developing the feature. Some teams can jump into work just by tracking story points per Sprint. However, from the Product Owner’s perspective, they will need more information to measure and forecast metrics such as utilization to their stakeholders.
Estimating Tasks
A good addition to estimating the story points of a user story is to plan the tasks needed to finish a user story, and how long it would take to finish each task. Story points are abstract, while time is more concrete, and the latter metric is needed for the granular nature of tasks. It is up to the team if they want to measure tasks in minutes, hours, or days, but for some teams, the default unit of time for measuring tasks is in hours. This is for them to know how much work they can commit to finishing a part of the user story within the day.
Task estimation is done during task breakdown in Sprint Planning. The development team decides what needs to be done to finish a user story, measure how long it would take to complete each task, and then, later on, assess the total amount of time it would take to finish everything within the Sprint. Then the team checks all of these against their availability. This is called capacity planning, and even if estimated times are not 100% certain and correct, this helps the Product Owner strategize with the team on how they can achieve the Sprint Goal.
It is an important note for Product Owners to know that estimates are not contracts or promises, but are simply guides for everyone to benchmark or baseline their work against. Estimation, in general, can be challenging for the development team to do – they may or may not be right, and this will only be known when they actually work on the tasks for the user stories. However, estimating and tracking will, over the course of the project, show trends and patterns in the work being accepted by the team.
Recommended Further Reading
The following materials may assist you in order to get the most out of this course: