The project has been funded, the team is assembled, and as PM you’ve written out feature stories based on your product roadmap. Now it’s time to talk specifics and figure out the amount of effort each story will take – will the team be able to complete everything in the given time frame?

In agile development, an estimate is a unit of measurement of the effort required to complete a user story. Estimation is important because it enables the PM (and the entire team) to figure out which stories to prioritize for the iteration and whether these stories can be feasibly completed within the span of that iteration.

Typically estimation happens collaboratively as a team, and the functions that work on a specific story give the sizing estimates for that story. Collaborative estimation helps ensure that teammates have a say in the process and are committed to completing stories on time. It also uncovers potential issues, unforeseen dependencies, and even possible shortcuts, since these estimations encourage open discussion.

One of the most effective ways to approach estimation is to estimate the relative effort and not the absolute effort of the story. What this means is that instead of stating the exact date or amount of time each story should be completed, the team assigns points to stories based on the relative level of effort – this story is bigger than that one, this one will take a lot more effort than the other one.

Agile teams commonly use the Fibonacci sequence to size stories (1, 2, 3, 5, 8, 13, …), likely to prevent a sized story from being broken down even more and to illustrate the uncertainty in estimating larger items. There are several other methods, such as “shirt sizes” (extra-small, small, medium, large, extra-large, etc.), but Fibonacci seems to be the most popular.

In my experience, while the product manager does not directly size the stories, he/she is still responsible for facilitating the conversation, calling out anything that sounds off, and asking the right questions. For example, if the developer sizes a story as an 8 and the QA sizes the same story as a 3, then the PM should be asking questions to each person and helping the team reach a consensus.

Most importantly, the product manager should be prioritizing the stories based on their sizes to ensure that the right stories are completed in the right iterations. This is called iteration planning and is the next step following estimation. As the team works through the iterations, the PM can calculate the velocity by looking at the number of completed points from the past several iterations. The velocity is a good barometer of how well the team is performing and allows the team to take a step back and make adjustments if velocity is lower than expected.

All in all, estimation is an important team activity that the PM should be very familiar with in agile teams. It not only provides a realistic view of the level of effort of the stories, but also opens up the team to discussions, questions, and elaborations that allow everyone to complete all stories and tasks in the most effective way possible.

Have thoughts that you’d like to contribute around agile estimation? Chat with other leaders around the world in our PMHQ Community!