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.
What Are Story Points Good For?
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.
Uh-oh, But Mike Says “No”!
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
But My Case Differs
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.