What's the best way to estimate story points in scrum?

Question

I like the way planning poker works at the beginning of any project, letting you compare and discuss details of each story with one another.

One of the issues I've noticed with this is that through time and as you gain more experience with the problem domain, you tend to vote less points for each story, i. e., a story that was worth a 5 or an 8 at the beginning of the project might now be worth a 3.

How do you avoid or tackle this problem in the best possible way? Is there a better way to estimate? Should the stories always remain the same, or is this story points decrease ok?

Answer 1

I don't think that's a big problem.

There are two obvious things that could be causing that. One is that you're experiencing some mild point deflation. The other is that your team is actually getting faster. (I hope it's the latter!)

Either way, it shouldn't be a big deal. The two main uses of velocity are figuring out how much work to take on in the next iteration, and making rough estimates of delivery dates for larger chunks of work. Neither of those is harmed by a gradually changing velocity. Indeed, if the improved velocity comes from getting better, then your new numbers present a truer picture of the team's capacity.

If the velocity is changing too quickly for comfort, then one response is canonical stories. Go through the last couple months, picking out 3 stories each to represent the point levels you use. Put 'em up on the wall where you do estimations. Then as you estimate, use them as comparison with the story you're dealing with. That should reduce both drift and volatility in your estimates.

Answer 2

Fundamentally, this isn't really a big problem, as most of these things will come out in the wash. By and large, explicit manipulation of the output of estimations is going to be a negative for the process. Story points estimation works best when teams keep their eyes on the ball - you're estimating relative complexity of stories versus other stories, and as long as you have historical information at hand for completed stories, you're probably going to see things settle out in the long term. Here's a place where team cohesion pays benefits, as a team will eventually settle on methods and reference stories for story estimation.

Story point deflation can be a mild problem, though, in that as your range of points estimates gets compressed down, you start losing information about fine tuning the velocity, and that compression can have negative effects in estimating the length for delivery of longer term release planning (inasmuch as you're going to multiply the errors introduced by the compression of all your stories into a narrow range). By and large, you want the results of increased velocity owing to expertise to be expressed as taking on more story points rather than estimates going down. The way to combat that is to continually reference previous completed estimates and make sure you're always estimating complexity. Never state how long you think something is going to take, just compare the overall difficulty of a story compared to previous stories. Let's say you have an app that supports mobile platforms, and you have to port to another. Is it similar to a previous port? Harder, because the platform has worse tooling? Easier, because you have a better debugger? That should inform your estimates, not the fact that this port will likely go faster because your teams is getting good at estimates. Concentrating on complexity should help solve this problem, to the extent there is one.