Estimating User Stories – Part 2

Estimating User Stories For Product Owners – Part 2

There are several ways to estimate user stories. A simple way would be using the T-Shirt sizing approach, where team members will mark each user story as S, M, L, or XL. These can easily describe the complexity of the user story, but will not be usable for tools like burndown charts and velocity charts. A common and pretty simple way to estimate story points with numbers is through Planning Poker, which involves everyone individually selecting a “card” with a number assigned to it, showing those cards to each other at the same time, and then discussing and re-voting, if needed. The number scale is up to the team, but the Fibonacci sequence can be used, for starters. Planning Poker requires everyone to agree on a number, and not just averaging the estimates. This enforces everyone to discuss and reach a mutual understanding on the user story.

If the project is new and there are no prior estimates yet, the Product Owner and the team can first select a user story as the baseline for future estimates. This should be a medium complexity requirement such that the team can advise if the effort of other tasks is greater or smaller than that of the baseline task.

59 Seconds Agile - Estimating User Stories

59 Seconds Agile – Estimating User Stories

Committing the User Stories

Once the user stories have been estimated, they are ready for the team to commit to completing during Sprint Planning. However, just because they are estimated doesn’t mean that the user stories cannot be negotiated. For example, during Sprint Planning, the team may have found roadblocks in a certain user story that could affect its estimates, and they may need to clarify it with the Product Owner and resize it. Or, the customer has expressed differently and the Product Owner thinks that they may need to revise a certain user story or discard it and then create a new one. As long as the user story has not yet been committed, it may still be changed and re-estimated.

Committing user stories will take place during Sprint Planning. It would be helpful to know what the velocity of the team is, which is the average total of story points they finish in a Sprint. If the Product Owner sees that the team has over committed or under committed, he may work with the team in re-scoping and finalize the Sprint Backlog.

Our Favourite Agile Books

We found these books great for finding out more information on Agile Scrum:

Just like software development, user stories have a lifecycle of their own: incepting the ideas, putting them to words, approving them, refining or possibly splitting them, prioritizing them, committing them, developing them, and then finally marking them as done. A mix of working agreements, Sprint ceremonies, and Agile tools will help facilitate the team is working on the user stories together. Estimates inform Product Owners on how their team perceives the work to be done and can further their decision making in developing the product.

Prev <— Continue Reading —> Next