Conducting User Story Estimation Meetings

Source.

Recently, my team changed the schedule for estimation meetings and how we manage estimating the user stories in our backlog. Note that this article is only about organizational aspects. Some thoughts about how to get to specific estimations can be found in my article about dealing with estimations.

We Estimate Early and Often

In our project, a Sprint is two weeks long. Every week on Wednesday, the team gathers to do a one-hour estimation meeting. We noticed that after one hour of intense discussions about the business logic, everybody is tired and it's best to meet again later in one week. This also gives our business consultant time to talk to the customer about questions that might occur in our meetings. Also, it shortens his feedback loop from creating a user story to getting feedback for it.

Review Everything — Even User Stories

We noticed that our user stories are very good from the business logic point of view. Everything the customer wants is in there. However, developers sometimes had a hard time figuring out what to do on a technical level. Are there any user interfaces to create, database scripts to be written or mappings to be created? To help our teammates understand the story as fast as possible, the business consultant asks the technical team lead to review every user story before sending to the team. The team lead has the task to think every story through on a technical level and add implementation details if necessary.

The Meeting Is the Last Step

As written before, our estimation meetings became long and very exhausting because we needed time to read the user stories, think about them and discuss questions. One time, we only managed to estimate three user stories in one hour. To treat more user stories, we follow this process:

1. After having written a story, the business consultant gets feedback from the technical team lead.
2. At least two days before the estimation meeting, the business consultant sends an email with the user stories that are ready.
3. Every team member reads the story as if he or she would have to implement it.
4. Every team member either:
   1. Understands everything and writes down an estimation (in days), or
   2. Has questions that are also written down.
5. We meet (once a week).

The estimation meeting is the final step. Because our business consultant is responsible for the user stories, he leads this meeting. For every user story, he follows the same procedure. After announcing the ID of the story, he summarizes in a few words what the story is about. He then asks if anyone has questions. Because everybody read the story beforehand, this question can be answered right away. If there are questions, we clarify. If not, everyone can immediately tell an estimation in days. If there are great differences between the estimations, we discuss those abbreviations and agree on a common number.

This process helps us to have everyone on board with the business logic and get good estimations very quickly.

Conclusion

Have a fixed process for how to do estimation meetings. Review user stories before giving them to the team to be estimated. Estimate early and often so each estimation meeting is short enough to keep everyone concentrated. Have everyone on the team contribute to estimations.