Category Archives: Estimating

When Should I Re-Point My User Story?

The intent of Planning Poker and pointing is to prevent analysis paralysis[i] and provide teams with a general, abstract, relative size for backlog items[ii] (i.e., user stories).  This consensus-based activity empowers teams to collectively discuss their estimates and any assumptions that may exist that effect those estimates.  Additionally, Planning Poker helps facilitate sprint planning, team capacity, and enables product owners to make decisions on which backlog items to be built.

As an agile coach I’m often asked “when should we re-point a backlog item that we’ve already pointed?”

My general guidance – don’t repoint any backlog item because it typically adds no additional value.

Are there exceptions to this?  Of course there are, that’s why this is guidance and not a rule.  If there is a significant change to a user story that causes it to become a different user story then I would consider repointing it.

When would this happen?  What constitutes “significantly”?

  • The user story stays the same but the acceptance criteria dramatically changes (it’s important to note that I’m not discussing just a refinement to the acceptance criteria). This change to the acceptance criteria in effect makes backlog items intent completely different.
  • The customer realizes they had the backlog item incorrect, “I wanted user story ‘X’, but that user story was incorrect, I need to re-write the user story”.

Teams often want to re-point because they want to get “credit” for the additional work.  But Planning Poker and pointing was not to establish credit.  So resist the temptation to re-point and ask yourself “is re-pointing a backlog item worth it or should we be spending the time delivering working functioning code?”

Remember, don’t just “Do Agile,” “Be Agile!”

[i] Grenning, James, “Planning Poker or How to avoid analysis paralysis while release planning”, 2002.


Product Backlog Grooming

Although this material may be found in a variety of places on the web, clients have often asked me to provide them write-ups and explanations.  Enclosed is a brief summary of the Product Backlog Grooming.


The Product Owner has a prioritized Product Backlog that aligns with their Release Plan and Roadmap.  To help expedite the meeting, the Product Owner should send out a list of stories that he/she wants the team to estimate. The team can then do any necessary research.


1 hour, 2 to 4 times during an Iteration


The purpose of Product Backlog Grooming is for the Product Owner to present new stories to the Team, discuss the stories intent, capture the acceptance criteria and story point the story.  It is a time-boxed meeting where the goal is to estimate as many stories as possible in the allotted time.

If this meeting is conducted regularly, Iteration Planning – Part 1 will be much faster and smoother for everyone.



  • Product Owner
  • Team
  • ScrumMaster


  • Anyone


This concludes when the meetings allotted time has expired or all the stories that were prioritized for that session have been estimated (planning poker).

Standard Scrum Ceremonies / Meetings

  1. Participants in this document refer to individuals critical to the meeting and are allowed to talk during the meeting. 
  2. Observers in this document refer to individuals allowed to observe meetings, but aren’t allowed to talk during the meeting.