Hacker News Reader

Comment by tupac_speedrap | Hacker News Reader

On my current project we don't estimate. It might not be suitable for most projects but we just pick up tickets off the kanban board instead of wasting days every month arguing whether a ticket is a '5' or an '8' we just do the work that needs doing the most.

View on HN

This works well with senior developers with the same background as people that drive the business decisions, otherwise developer's understanding can be completely different.

I think you need to discuss everything that is going to be done as part of a ticket anyways. Asking at the end "Is everyone ready for estimation? 3, 2, 1 go" takes an extra minute.

We do this sometimes and it is interesting to see how big the range can be. The motivated, new developer gives a 3 for reasons while the senior who's been burned by the big ball of mud too many times gives a 13 and the PO somehow thinks this means it is an 8.. For me it is a wasted minute (times tickets), but you gotta pick your battles.

True. Our default is to go for higher estimation especially coming from a senior. 13 should be broken down tho.

I know that this is a commonly held belief, but: why does it need to be broken down? Can a 13 not just be a 13?

In our system it implies a major piece of work that can almost always be split down into multiple tickets that can usually be worked on in parallel.

2nd Splitting it in smaller parts forces you to examine all the parts and inner workings. Sometimes you will realise entirely different solution is needed, sometimes that there is an api call that will incur costs… and some of these things definitely have to be communicated to stakeholder, ideally before you spend significant times in development.

Last time I was in a team that did this, it was pretty useful.

A wide range would spark a brief discussion (the senior would bring up the points that the junior is missing - yay knowledge sharing) and high estimates would usually result in breaking down.

The key is to keep it short, if need be timebox.

That, and time estimates are output. Estimate by story points or T-shirt size, track how long tasks take to complete, and you can trivially derive a mapping from one to the other. Revise during implementation, too, if need be. Something that was estimated as a 3 and turns out to be a 1 gets re-pointed, and vice versa.

This helps in all kinds of ways. Engineers don't have to think about time when estimating, which tends to make estimates freer and thus more accurate. PMs/POs don't have to deal with too much uncertainty, because the distribution of time to completion over a given estimate is right there. It's easier to know how much can fit into a given sprint, and as soon as all the tickets in a given epic are pointed, you can know about how long the epic will take to get done.

Engineer time remains nonfungible, of course, but if the team is well balanced that seems to average out, and I don't (yet) know a better method of squaring a team's need for looseness with an organization's need for legibility.

> Estimate by story points [and] track how long tasks take to complete, and you can trivially derive a mapping from one to the other.

I like this approach because time is such a weird thing to try and figure out beforehand. You either overpromise and look bad or over deliver but the thing you're delivering could get delayed because another team isn't ready. This other team will likely not be developers too, it could be a timeline imposed by the product team.

Time still has importance tho because something can be easy but still take a decently long time. You could rate something 1 story point but it could still take 3 hours all-in from dev time to do because it involves making a very straight forward change to 8 services which entails maybe creating an epic Jira ticket to explain the situation and then 8 individual tickets (1 for each service repo) + 8 PRs + 8 code reviews + updating 8 release docs.

For most purposes we don't try to be more granular than days, rounding up. When hours do matter, it's usually in a context where estimation isn't as important because whatever it is needs to be done ASAP.

You don't need to discuss everything.

The the oh-so-common 2 hour+ full team meeting scoping session, where half the team dosen't care what the other half is talking about since it's irrelevant to them - it tires everyone out and produces very little value for the impression of "we're now aligned".

Things only need to discussed if, when and only by as many people as required, everything else can be followed up later, it's really okay. Personally, I've always found things like 3 amigos to be much more time effective.

It works well with junior developers too.

The problem isn't really seniority or juniority it's that doing this usually requires buy in all the way up to the CEO.

If it doesn't then the CEO pressures the CTO for estimates, the CTO badgers the middle manager for estimates, the middle manager badgers the project manager on your team for estimates and he comes nervously to you asking if you could please give him something resembling a date while he nervously wonders how much to pad it.

Each one has their asses on the line for the date.

You can be as "agile" as you like on a team but this wave of estimate badgering reliably turns on the waterfall every time.

The 5s and 8s are like the Holy Grail. The Grail isn't the point - the quest is.

We don't do detailed estimates, but we do some estimation. Often the discussion around the estimation leads to a change in the task, which drastically impacts the estimate.

That is, by thinking about how to solve it, in order to estimate time taken, one can come up with alternatives which might achieve the same or a similar goal with less work involved.

Maybe the customer doesn't need such a bespoke solution after all? Maybe we can ask the customer if a slightly different solution is suitable?

For example, recently a customer asked if we could make a new web API that they could query for some data. While estimating the point was brought up that just transmitting a xml/json file with the data once a day might be just as good and less error prone for the customer. After all the underlying data doesn't change more than once a day anyway.

So we ask the customer and once they think about it they agree it's a better solution all around. So they get what they wanted for a much lower cost, and we didn't have to commit a lot of resources to make a new API.

Reply on news.ycombinator.com