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

https://news.ycombinator.com/item?id=20909616

by tdrgabi • 7 years ago

10 12 7 years ago

news.ycombinator.com

I'm wondering if there are success stories using story points or some kind of estimation game, or even group estimation meeting. In each team/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 "we know how many points we can estimate in a sprint" so we can plan better "nirvana"?

jacekm3• 7 years ago

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.

tdrgabi3• 7 years ago

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

jacekm3• 7 years ago

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.

sethammons2• 7 years ago

We try to write stories to be clear enough that anyone on the team could work on it. Supporting documentation linked, code points linked, etc. It is not always needed, but can help, especially with newer folks. Still, if someone is sufficiently new or unfamiliar with a given topic, they can abstain from voting (and it usually means this person should be shadowing or pairing with someone else to deliver that story).

For 2 vs 4, I've heard it recommended to use Fibonacci numbers to help avoid the confusion. 1, 2, 3, 5, 8... The argument being that with small points, usually things are easier to compare. As you get larger points, it is more apparent if something is a 5 vs 8. So a 2 vs 3? Meh, round up and move on to the next story. 2 vs 5? Orly? Let's talk on why these are (un)like similarly sized stories.

However! Hemming and hawing over close point stories irks me, eps. when the story could have been half way done by the time the team negotiates the points. If points are slowing your team down or not aiding discussions about sizing, then your team should change how it operates; the process should be helping. We've changed ours method to 1, 2, or 3 (definitions what those mean to our team in another comment I left here). Pointing for us typically takes under 20 seconds. Everyone agrees? Good; done. Disagreements? Either round up or discuss it and move on.

The end goal is to help the team create as small of stories that are still delivering value to the org. If any of your agile/scrum ceremonies are not adding value, the retro is a good place to discuss how to improve (or remove) processes so that the team can effectively and visibly make progress.

tablet• 7 years ago

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.

jacekm3• 7 years ago

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• 7 years ago

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.

tomohawk• 7 years ago

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.

tdrgabi3• 7 years ago

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

sethammons2• 7 years ago

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.

clusmore• 7 years ago

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.

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

Related Stories