When faced with a task, you’re faced with the age-old question of how long it will take to complete.
It doesn’t matter whether you’re making dinner, building a new garden shed, or undertaking software development, you need to determine when you’ll be done so that you can inform your family when dinner is, tell your partner whether you’ll be finish before nightfall, or tell your stakeholders when something is going to be released.
In this article, you’ll learn what agile estimation is and how you can use it to have a better sense of your product development.
In agile product development, a “sprint” is a set period during which specific work has to be completed and made ready for review.
The length of the sprint may vary from organization to organization, however, the principle of the sprint remains the same; during this time the team will deliver an agreed series of work items.
When operating within an agile framework, the ability to estimate how long tasks will take feeds into the process of determining what work you’re able to complete within the sprint.
If your sprint is two weeks long, what work items will be finished in two weeks?
If your sprint is four weeks long, what work items will be finished in four weeks?
Teams are only able to answer these questions when they:
Agile estimation is the activity that supports the answer to the first question.
When it comes to agile estimation, there are two main techniques that product managers tend to employ: planning poker and t-shirt sizing.
Planning poker (aka scrum poker) is a technique most often applied in agile software development to help scrum teams estimate the amount of work required to complete tasks in the product backlog.
Planning poker is played with sets of cards that display numbers that roughly follow the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13…) before drastically increasing (20, 40, 100) and finally ending with infinity.
The numbers represent the potential complexity of the work being discussed, from the simple lower numbers to the more complex higher numbers. They’re often referred to as story points.
Teams discuss each work item that’s a candidate for inclusion in a future sprint and at the end of the discussion, the team will simultaneously turn over the card that they as individuals think represents the scale of the work involved.
The aim is for the team to have a consensus on the scale of the work, which would indicate a strong common understanding of what’s involved. A varied spread of estimates would indicate variety in understanding and lead to further discussion to share knowledge and reach more agreement.
At the end of the planning poker session, the team will be left with a series of work items, each with its own estimated complexity.
T-shirt sizing is a technique used in agile software development to help scrum teams estimate the amount of work required to complete tasks in the product backlog.
It uses the standard sizes of t-shirts (XS, S, M, L, XL, XXL) to categorize the complexity of work items within a backlog from simple items as XS through to complex deliverables at XXL.
T-shirt sizing starts with a common definition of what each of the sizes represents. This can then be used as a reference point for the estimation of all future work items.
For example, the update to the title on the website homepage might be classed as XS, whereas the inclusion of a new image carousel could be an M and the redesign of the entire page be an L.
At the end of the t-shirt sizing session, the team will be left with a series of work items, each with its own estimated complexity.
Of course, estimation is not the entire goal when it comes to developing new features or products. You’re aiming to understand what work can be done and when so that you can communicate to teams what they need to focus on.
Scrum is a framework that teams use to self-organize and work towards common goals and describes a set of meetings, tools, and roles for efficient project delivery.
Key elements of scrum that relate to the estimation techniques include:
Perhaps the most important use of estimation is to plan how much work you can realistically get through within a sprint.
Over time a team will develop an idea of the speed they can work at and this can be used as a reference point for future planning. For example, a team might get through an average of 50 story points during a sprint, made up of multiple stories of different sizes, and this velocity of 50 story points per sprint can be used to plan upcoming sprints where the total number of story points for work included in the sprint backlog is approximately 50.
Kanban is a framework that teams use to organize work in order of priority and to provide visibility of work items throughout development.
Key elements of Kanban that relate to the estimation techniques include:
Perhaps the biggest use of estimations is through the forecasting of when a work item will be completed, based on its estimation and the speed that the team works at.
For example, a team might complete a M t-shirt work item within one week and a L t-shirt item in two weeks. If the next item to be picked up was a M t-shirt size then the forecast would indicate its delivery in one week.
Now that you have a sense of what agile estimation is, let’s cover some of the frequently asked questions about it.
The short answer is no. Story points relate to the potential complexity of a work item. The velocity of a development team would indicate the average number of story points that a team might achieve during a sprint, however there isn’t a direct link from a story point to a time period.
A team’s velocity (i.e. how many story points the team completes within a sprint) is unique to them. It’s based upon their initial story point estimations and references, their sprint process, and their development process. No two teams will follow identical processes, so velocities will vary. This is OK.
The process of agile estimation involves the whole development team, and as time progresses the team builds up a frame of reference from work items they have previously estimated. These reference points become how different work items can be compared.
For example, if the team has already determined in the past that the inclusion of a new image carousel on the homepage was five story points then they know that in the future a work item of similar complexity would have a similar value, one that’s more simple would be less, and one that’s more complex would be higher.
No. It’s better to try and understand and forecast the future than not, as it provides a reference point for you to ask questions and look to improve. It’s natural for teams and stakeholders to want to understand when certain activities will be completed and estimating is a way of providing a level of insight. It isn’t 10 percent perfect, however, reviewing performance will improve it over time and provide a greater level of certainty.
When it’s apparent that an estimation is inaccurate it’s necessary to review the impact that this will have on the development ongoing or in the future. It might mean that other work items are removed from the sprint, or that future items will now start later. It might also mean that the work item itself needs to be reviewed in case it can be revised to something less complex or re-prioritized.
Anything that involves “estimation” is by definition not 100 percent accurate, however, having some information and being 90 percent sure of it is better than having no information at all.
Stakeholders of products want to know what the future looks like and through the use of some of the agile estimation techniques it’s possible to paint a picture of what that future looks like. It might not be the exact picture with all the detail, but at least they’ll have an idea of what to expect.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.
Learn more →
