Comment by FrankyHollywood | Hacker News Reader

Comment by FrankyHollywood | Hacker News Reader

Parent Full thread

FrankyHollywood

exactly my experience, a reasonable deadline defines the design and scoping, and makes you give right expectations to a customer.

I left 2 jobs because of rigid scrum, couldn't handle the insane discussions.

"how many complexity points do you estimate?"

"euh, what was our velocity?"

"no, you can't think in hours, give me complexity POINTS!"

"I dunno, probably 2 to 3 weeks of work, to many unknowns"

"unknowns? we refined this story, there are no unknowns!"

"ok, 3 weeks = x points"

"no, you can't say 3 weeks, we have 2 week sprints. You should split the story in 2, where each story is a well defined functional component which we can show in next demo"....

"but, it is 1 thing, you can't split and have it working for next demo..."

mind torture... so I left

Nowadays I have a very experienced team. We do daily standups (without a scrumboard, just real conversation), we define deadlines, can be a week, can be 2 months. Demo's only when needed, kind of the way I used to work before rise of scrum :)

What upset me about story point estimation was that we never ever used it to influence decisions.

Every single sprint planning meeting and every single retro around half the time was spent talking about points, discussing estimates and commenting on our velocity had changed.

But we never had even one conversation where we put any of the 'data' we had about how many points we could do in a week to use to decide what we should focus on or when we should promise something by. The whole system was upstream of nothing.

Of course, this was a tacit recognition that it was worthless, and if we had used it, it would have been worse than nothing. But why didn't this acknowledged uselessness allow us to drop it?

Points are a forcing function to agree on scope and have everyone think about complexity. Even if they’re upstream of nothing, they’re downstream of valuable discussions that get the team on the same page and support each other better. This is what it usually looks like:

“OK I think we agree on the scope of this task. How many points do we think it is?” “Well, that depends if we include X” (it turns out, we didn’t agree on the scope of the task!)

You can’t anticipate everything, but I’ve had countless valuable discussions off the pack of pointing that resulted in things like: - agreeing on whether to include an anticipated set of clean-up as part of a task, that the team might have missed or disagreed on later - realizing a task is bigger than anyone thought or maybe could be parallelized, allowing the team to approach it more effectively or reprioritize to deliver more value

Basically pointing results in a ton of timely & valuable insight that helps the team learn faster and row together better. There may be better ways to drive these conversations but I find pointing to be a pretty good driver.

That said, points and valocity are not upstream of nothing - predictable velocity lets you know when to stop sprint planning. It lets you have these discussions on a reasonable cadence and not waste time fleshing out the tasks you won’t have time to touch until next sprint.

You spent some of this comment arguing that points and velocity are not upstream of nothing, and the rest explaining that it's ok if they are upstream of nothing, because the work spent on them justifies itself. This is exactly the refusal to acknowledge reality that I objected to.

Which is it?

Ahh story points... the logic that you don't want to use real time units because predictions are inaccurate, but then everyone spends time mapping from story points to real time units anyway...

Tbh if entire tasks are taking 3 weeks you have problems.

Or you are working on complex problems and interdependencies not tonka toy systems.

I've worked on very complicated systems(Mathematical simulations etc), you can always break it down to sub problems.

Reply on news.ycombinator.com