Do’s:

 

Use Relative Sizing: Story points are about relative sizing, not absolute time. Compare the size of one user story to another, focusing on complexity and effort rather than specific time estimates.

 

Involve the Whole Team: Estimation is a collaborative process. Include developers, testers, product owners, and other relevant team members in the discussion to gain diverse perspectives.

 

Use Reference Stories: Maintain a set of reference stories with known story points to anchor your estimations. These serve as a benchmark for sizing new stories.

 

Leverage Planning Poker: Planning Poker is a popular technique where team members independently estimate a user story and then discuss discrepancies until a consensus is reached. It encourages open communication and alignment.

 

Estimate in a Relative Manner: Story points are not meant to be directly translated into hours. Instead, they should reflect the team’s understanding of the effort required for a story compared to others.

 

Consider Complexity, Risk, and Uncertainty: When assigning story points, take into account factors like complexity, risk, and uncertainty that might impact the effort required to complete a user story.

 

Revisit and Re-Estimate: Regularly revisit and refine your story point estimates. As the team gains more knowledge and experience, they may need to adjust their estimates for previously estimated stories.

 

Focus on the Discussion: The value of estimation often lies more in the discussion it generates than the actual number assigned. Use estimation sessions to clarify requirements and potential challenges.

“The real test is not whether you avoid this failure, because you won’t. It’s whether you let it harden or shame you into inaction, or whether you learn from it; whether you choose to persevere.”
– Barack Obama

Don’ts:

 

Don’t Equate Story Points to Hours: Avoid the temptation to equate story points directly to hours. Story points are a measure of effort, not time.

 

Don’t Force Consensus: While consensus is important, don’t force it. Some level of disagreement can be healthy and may lead to valuable discussions about the user story.

 

Don’t Overcomplicate It: Keep the estimation process simple. Avoid introducing unnecessary complexity, such as fractional story points.

 

Don’t Use Story Points for Tasks: Story points are meant for user stories or features, not for estimating individual tasks within a user story. Tasks can be estimated separately, often in hours.

 

Don’t Fixate on Precision: Story points are estimates, and they don’t need to be precise. Aim for accuracy at a high level but understand that Agile values adaptability over precision.

 

Don’t Skip Estimation: Even if a user story seems straightforward, don’t skip the estimation process. Estimation helps uncover potential challenges and provides a shared understanding of the work.

 

Don’t Compare Across Teams: Avoid comparing story points between different Agile teams. Story points are specific to each team’s context and should not be used for cross-team comparisons.

 

Don’t Neglect Refinement: Story point estimation is an ongoing process. Don’t neglect backlog refinement sessions where you can revisit and refine your estimates as needed.