Story Points are Relative to Each Team
When teams are new to story pointing, it can seem very confusing. This is because each team's scale is different. What takes one team 2 days might take another 5 days. What one team considers to be a 5 point story, another might consider it a 3.
This is the main reason why it's a HUGE mistake to compare points (and overall sprint velocity) across teams. If leadership starts to say things like "Why did this team only complete 45 story points when this other team completed 90" - that's an enormous red flag.
The main thing to keep in mind here is that the scale for each team should remain consistent. As long as the entire team understands what makes a certain story worth 2 points, and another worth 5 - you're in a good spot.
Use story points as a basis for velocity calculations only after a few sprints have gone by. Every team needs time to get a baseline and normalize.
Talk Through the Details
Most of the acceptance criteria for each story should already be worked out ahead of Sprint Planning during Backlog Grooming sessions with the Product Owner.
However, it's very common for some additional questions to arise during Sprint Planning, which often results in modifications/additions to the acceptance criteria. The important thing is that the Scrum Master (and PO) leave space during Sprint Planning for these conversations to take place. The team needs to talk through the details before they can best provide a story point estimate.
Developers are the Most Important Players in the Room
Developers should be the only ones providing story point estimates.
This can sometimes to a controversial statement, as others believe input should also be heard from the design team, product owner, etc.
However, in practice, I've found that the people closest to the work (i.e. the developers) are best at providing an estimate on level of effort. Designers can provide feedback and answer questions, but it's best if the actual story pointing is left to those that are going to be doing the building.
This makes the developers the most important players in the room during Sprint Planning (and during Planning Poker).
Role of the Product Owner
During Sprint Planning, the Product Owner should mostly be a silent observer - only speaking up to answer clarifying questions on features/functionality. This is because the Product Owner can be seen as an intimidating figure in the room. Developers may alter their estimates in order to please the Product Owner.
The PO should really only be in attendance in order to observe the story pointing process in order to better understand what certain stories are "worth" in comparison to others, so that the PO can use that info when prioritizing stories in the backlog for future sprints.
With all of this to keep in mind, it can be difficult to know where to start. The best way to begin is by asking questions. Doing this will lead the team to have a better understanding of what it means for a user story to be a 5 and how that compares to other stories. It will lead to more consistent team velocity, get everyone involved, and allow product owners to demonstrate their ability. Story pointing doesn’t have to be difficult; keep these tips in mind so that you can make your next meeting go as smoothly as possible.
