Estimating and Planning Agile User Stories

For some teams, planning and estimating user stories is an exercise they do not enjoy, especially at the start of a project. Even where the Product Owner has explained the project to the team by describing the epics and what they are expected to deliver, there is a lot of uncertainty about how much effort is involved in getting each user story to “done”.

Especially when a team is new to Agile, or new to each other, there is a lot of apprehension as to what the team is committing themselves and whether they will meet the stakeholders’ expectations. These fears are groundless, and with the correct approach to story estimation, it can be a simple, and even fun process.

Taking the Pain out of Story Estimation

The key word to remember is “estimate”. An estimate is a guess; while it is possible to be surprisingly accurate when estimating, the estimate could be too optimistic or too pessimistic. However, if the Product Backlog has around 300 user stories in it, the estimates will average out. Unlike traditional projects, where activities are estimated using time as a basis, such as hours of effort, in Agile we assess the complexity of a user story. Obviously a complex user story will take more time than a simple story, but the focus is on how many stories we can complete in the current sprint, not the time it will take. We do know how long it will take for all the stories in a sprint because the sprint has a fixed timeframe, say 4 weeks. So, instead of using time, we use a points system, allocating a number of points to a story to describe its complexity.

Recommended Further Reading

The following materials may assist you in order to get the most out of this course: