Hacker News Reader

Comment by LtWorf | Hacker News Reader

In a job a long time ago there was a brogrammer in the team, always estimating absurdly short times because he was so good and fast (he wasn't bad, but he was 2-3x slower than he himself estimated). So I had picked up the habit of estimating 5x longer on tasks, to balance him out.

Also all the sprint planning and retrospective took basically 30% of our time.

View on HN

Agreed. The differences of opinion during estimating are another form of pressure. Programmers work differently. I might estimate a task longer than a colleague, but I might be the type of programmer who tidies up and refactors along the way, or who spends more time communicating with the team on strategy and architecture. These are hard to quantify behaviors that Jira can't effectively track, unless you're going to spend half your day _in_ Jira writing down every action every day. Don't event get me started on the effect of context switching.

Managers are pushed to produce reports to prove they're managing. Reports require metrics, and that's a lot of where all this rubbish starts. The solution in my experience is to keep teams small enough that you don't need those sorts of layers of management (though the opposite is inevitable in larger companies).

How does something like this take 30% of your time? On my calendar it's two hours out of 80, or 2.5%. One hour per sprint for planning, one hour for retro, why would it be longer?

My team lead spends more time prepping tasks with the PM prior to sprint planning, but even then it's about 5%.

My last company, we had one-week sprints, but we didn't do official retros, so it was still 2.5%, one hour of planning for 40 hours of work.

Sprint planning today took 26 minutes.

The Retro yesterday was 30. So that's less than 1.25% of my time spent.

I find it challenging to estimate my own time in tasks. Part of every task is figuring out how to actually do the thing you are wanting to do, and sometimes that takes 5 minutes and sometimes much longer. So I am terrible at estimating my own time, and even worse at estimating someone else’s. It doesn’t add pressure to a person if you give them a time goal they know is basically arbitrary.

That means the task is underspecified. You should schedule a "figure this out" instead, and once the task is well defined it can be done.

You never know if you have really completed the "figure it out" task until the "get it done" task is completed.

A meeting to plan for the meeting. Instead of turtles, it's meetings all the way down.

I never said a meeting. That says a lot about you :p

Software estimation is very hard.

This is what scrum (done well) helps with. Unless the software was horribly written, it’s usually easy to estimate effort for very modest, well-defined changes.

Take a large enhancement or overhaul, however, and estimates will be wildly off and it’s because of the iceberg effect of unknowns.

What scrum forces the inexperienced teams to do is start breaking down, plan and incrementally chip away at a ill-defined, large request by turning it into many smaller and better understood deliverables.

It’s what very good teams do, though they do it without the need for formality.

Shouldn't that lead to a team discussion about why the estimates differ so drastically? In most circumstances, the reasons would be inaccurate assessment of scope or complexity. Clearing up misconceptions like that can be a great boost for productivity.

"Oh, you can do it like THAT?! I was not aware. I'll take a shot at implementing the feature using that approach."

It did. I said I would not stop doing it until he'd stop. So we just continued this way.

It inevitably does and then everyone slowly starts estimating everything at the middle point size in the agreed spectrum, with only 2-3 outliers

Theoretically, yes, but if you’re spending half of your time on process overhead there isn’t much left to do that well and most of the time there’ll be enough differences from sprint to sprint that it’s plausible that this time was late for other reasons, until you have a sufficiently long data set to show that it’s a trend.

> "Oh, you can do it like THAT?! I was not aware. I'll take a shot at implementing the feature using that approach."

Next performance review, your manager goes: It seems like you're not really aware of a lot of techniques of how to solve problems efficiently. Maybe you should do more pairing with the other seemingly much better developers to strengthen your skills. And now you've cornered yourself as a junior for the next 2 years, who was "hired on the wrong level".

All of this is assuming that the team members will prioritise the performance of the team higher than their own performance, of which there are no incentives. The incentives is to make yourself look as good as possible (don't admit your idea is inferior), and skew the playing field to your advantage (insist on using the tools you know best) etc.

People simply don't spontaneously cooperate and simply don't "just get along" in a situation like this.

Even in hippie communities where everything is voluntary and there is no personal gain to be had, it still falls apart because some people just don't cooperate.

So how do you expect that to happen in a situation with money involved, and competition between people?

Why do the software industry and scrum think they have spontaneously discovered how people always just get along, inside a basic weekly planning schedule? That would literally be a nobel peace prize right there.

Estimates should be made in abstract units (e.g. 'function points'), then converted to man-days or dollars or whatever using a scaling factor specific to the estimator. That way, the actual value of the estimate is moot; it's the consistency of the estimates that counts.

Reply on news.ycombinator.com