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!”