
Ask HN: Do story points and estimation games work for you - tdrgabi
I&#x27;m wondering if there are success stories using story points or some kind of estimation game, or even group estimation meeting.
In each team&#x2F;job, I was part of in which it was tried, it never seemed to work and it was abandoned after a while.
Is somebody in the &quot;we know how many points we can estimate in a sprint&quot; so we can plan better &quot;nirvana&quot;?
======
jacekm
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.

~~~
tdrgabi
Usually a team of 4-5. 2 are more senior and know the code area. 3 developers
are new or never worked in that area. You can ask the senior people to
estimate or if you ask everyone, the juniors are aware they input random
numbers. It feels like a charade. And the talk "why do you think it'a 4, mine
is a 2" usually results in a shrug and it randomly becomes 2 or 4

~~~
jacekm
It's ok to abstain from voting if you don't feel confident about providing an
estimate for SOME of the tasks. However if team members cannot provide any
input on any of the stories then you have a bigger problem.

> usually results in a shrug

This is a problem. I'd suggest to repeat voting after having a conversation.
And like I've said before - developers should try to commit themselves to
deliver a chunk of work. It's hard to commit to random estimate that does not
take your point of view into account.

You could also try replacing story points with t-shirt sizes. If you cannot
agree whether the story is 2 or 4 points, maybe it would be easier to agree
between M or L. I am not a big fan of this method but I've seen teams for whom
it worked better than story points.

~~~
tdrgabi
Thank you for the in depth of answers.

------
clusmore
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.

------
tomohawk
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.

~~~
tdrgabi
I agree on the make believe. And I remember long discussions about what 5
points are. Are they 2 days or 4, because 3 points was 1.5 days, etc.

And all that precise talk was about something that can't be precisly estimated

------
tablet
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.

~~~
jacekm
> you can just multiply

Couldn't agree more. I learned to multiply whatever I have in mind by 2.5 -
this gives me estimates that are actually quite close to reality.

------
UK-Al05
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.

------
sethammons
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.

