Ask HN: Do story points and estimation games work for you

Estimation games (poker planning) always worked perfectly for me, regardless of where I was working. It's a great tool for having everyone on the team to voice their opinions. On some occasions where such games were abandoned I saw individuals putting unrealistic estimates on stories. While these individuals had a lot of experience they tended to estimate from their perspective and skillset, not taking into account that implementation may take more time for other team members.

Story points is a different topic though. In one company I saw it working fine, but we tended to keep number of points per story low. If too many points were assigned, BAs were asked to rework the story and split it into smaller ones. In my current job we tend to associate story points with person-days (so for instance 5 story points is ~5 days of work) and I think it works well for us.

> we know how many points we can estimate in a sprint

Well, you learn your delivery capacity after first couple of sprints. After 3-4 sprints I usually expect my team to deliver roughly similar number of story points each sprint. If we don't it calls for an investigation. Sometimes there's a good reason (e.g. people on sick leaves or previously unforeseen problems) and we expect situation to stabilize over the next 1-2 sprints. Other times we need to take some actions.

Also you may try assigning particular stories to particular people during planning meetings. Ideally they themselves should commit to deliver a particular number of stories. It may happen that some shuffling and reassigning will occur during sprint, but that's ok. The purpose of this exercise is to help you estimating how many story points you can deliver, the assignments are not that important.

BTW it would be easier to answer if you could elaborate what problems exactly are you facing.

In 20 years in soft. dev. industry I tried almost everything to improve estimates: delphi, planning poker, various formal techniques, points and estimation by compare, etc. Here are my rules.

1. In general I found that for rough estimate you can just multiply by 2 for a very experienced developer, by e (2.7...) for a developer with less domain expertise and by pi (~3) for an unexperienced developer.

2. If you need more precise estimates, then:

2a. do discuss every feature/story in depth, since it provides various opinions and help to find unexpected problems

2b. don't use points. Days are more reliable unit

2c. break down every feature to stories and every story to tasks. More granular items -> better estimates

That is it.

I find story points help, but they aren't perfect.

What they avoid is time pressure. I think a lot developers internally and externally feel pressured to reduce the time estimate.

Points allow you to be more honest.

I've worked on teams that were poor at estimating. They used story points.

I've worked on teams that were great at estimating. They used days. 1, 2, 3, 5, or 10 days. Smaller than a day - coalesce. Larger that 10 days - break it down.

The difference was with points there did not seem to be any real impetus to improve estimation. It was too make believe. Also, if you asked a team mate what a point was, they might say an hour, a day, whatever. Sometimes this would cause unnecessary drama.

With estimates in days, it was concrete, and concrete steps were taken as the team was forming to improve estimates. Also, minimum time of 1 day helped avoid the small stuff taking on too much importance.

I think a mistake was made when points and estimation came together. There is some history there and lots of debate. What I've landed on is points are good at driving a conversation around "should this story/ticket be broken down into something more manageable that still delivers value?" With that as a guide post, our team only points stories as 1, 2, or 3. 1 is "we know exactly how to do this straight forward thing." 2 is "we have some figuring out to do, but think we can do the thing in a reasonable amount of time and effort." 3 is "there are some big unknowns, but we can't think of a way to break this into smaller, useful chunks." If the team points a story as 3, it is a flag that we need to talk about it and figure out if we can break it up. We usually can.

For estimation of work we can pull in, it is about letting the org know when they might expect things. We pull in our average number of points minus a buffer, and then will pull extra things in as needed. But by committing to less, we are more likely to deliver what we said we would. That keeps the org happy.

For long term planning, I think points fall apart. The best I know to do is list out all the things that likely need to happen, break them up into stories/tasks, and make an educated guess and add padding for the unexpected and padding for optimism. And remember Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

The only thing that I've found to work reliably is same-sized stories, i.e. breaking down every story until you get very thin vertical slices of roughly the same complexity (not very complex at all). The refinement should be done with (some part of) the development team and the product owner present. Ideally each of these stories is at least slightly useful to a user (if not it's hidden behind a feature flag until enough related stories are shipped to make it useful), but it should be testable in production. I also find that when you do this, sometimes the product owner realises that some of the slices aren't particularly valuable and they can be deprioritised.