Comment by UK-AL | Hacker News Reader

Comment by UK-AL | Hacker News Reader

Parent Full thread

In scrum you are traditionally not meant to give time based estimates(it doesn't work). You use story points. Humans are bad at time estimates, everyone is.

Using story points, you measure how complex a story is, rather than time. A small spelling change, vs massive re-architecture. You do things in general abstract terms, rather than hard deadline, where you get fired if you don't meet it.

A added advantage of story points is that is abstract, it doesn't care if you 6 hours out. So you don't feel pressured to lower it.

You then look at previous sprints and see how many large/small tasks you can complete in a sprint.

A lot companies try to use time estimates to increase productivity, and get developers commit to releasing by a certain date. It doesn't work, it leads to rushed buggy code.

Its sounds like company is one that doesn't really understand agile/scrum, and is trying to use estimates as a whip to get you to work faster.

Companies need to stop using time estimates as a whip, and focus more on methods that are actually generally accurate, and provide useful information for planning.

We'd tend to do that for stories, yes; take an overall story and assign it a number of story points. We'd then try and make time estimates for each of the story's subtasks, which is where I would have trouble. Time was a bit like a currency - "We have X number of hours available in this sprint, the sprint is big enough when we've 'spent' all those hours on estimates".

My experience actually matches what you're saying, in that there was always much better discussion around the number of story points and I never felt like my story point estimates were guesses. If there were any disagreements over story points, we'd at least be able to discuss it concretely ("here's why I think this task is more complex / more simple").

For what it's worth, before I was gone our process was moving more towards a velocity focus, where story points were getting more importance than time estimates. Generally Scrum was a new thing for our company and our group was one of the first to use it; I don't think they were using estimates as a whip, at least not intending to. However the business still needed/wanted concrete dates that the group had to commit to.

At our company, story point method is very accurate, so most of the tasks are completed at the end of sprint except maybe 1 or 2 at the end(out of 30) which normally caused by something outside of our control.

At previous companies I used time based 'guess' methods, which were all over the place most of the time. I don't think i've ever been at a company that could actually get it right.

Honestly this way of estimating really suits my team. I don't want go back to a company that picks time based estimates out of thin air then expects you to meet them. I was really bad at that, but so is everyone else.

We don't expect to developers to have committed to complete stories mid-sprint or anything. But we have generally come to expect all items to be completed at the end of sprint, simply because our capacity planning is very good at the moment. Everyones happy with estimates at the moment. We do slight adjustments based on previous velocities. When we don't complete stories at the end of the sprint, we change the capacity for next sprint rather than blame developers.

It's a lot more collaborative, rather than a hostile blame game.

Reply on news.ycombinator.com