There is a long-time debate if you should re-estimate user stories that you haven’t finished during a sprint. My answer is:
yes, you should!
And this is why.
First of all, let me explain what I use estimates and story points for. Mostly so it is easier to decide how much the team is able to deliver during a sprint. If you have some historical date as to your capacity, then it is easier to decide whether you will be able to deliver X or only half of it. The second reason for estimation is, that it coerces team discussion which helps to uncover issues that would otherwise remain hidden.
So, I’ve read Mike Cohn’s post against re-estimation (“To Re-estimate or not; that is the question“) and I totally don’t buy his argument. And his argument basically is, that when you re-estimate, then you end up with a backlog which consists of items of different sort, so to say. Estimation of some items happened a priori (without knowledge before you experienced working on them and some a posteriori (which means, using the knowledge from your experience of actually working on them.
Having both before-the-fact and after-the-fact estimates on your product backlog and list of finished work can cause a lot of confusion for the project. When all estimates are given in before-the-fact numbers we can reason about them and compare them.Mike Cohn
It is pretty logical, I have to admit. But, the thing is, it doesn’t work this way for me. For the teams I work with it happens 99% of time, that if the item is not finished during a sprint then it gets (almost) automatically assigned to the next sprint. Which means, there are no a posteriori estimated items in the backlog. Which renders Mike Cohn’s argument irrelevant to my case.
And since story points and estimates help me so much with sprint planning, I will stick with re-estimation.