Comment by Test0129 | Hacker News Reader

Comment by Test0129 | Hacker News Reader

Absolutely anything is better than sprint pointing. This garbage process was adopted from what I can only assume is some cabal of "agile consultants". I have over 10 years in the industry. I cannot estimate something with less than a 20% margin. An estimate requires you to know everything up front, at that moment, for it to be accurate. Anyone who has made software knows this is never the case. The only thing it allows, and what I can assume is the only reason it continues, is because it's a job creation program for "agile certified" project managers and it produces a nice burn down/up chart you can show the manager. Sure, you can call points deadlines, but they are not. It's an arbitrary measurement of a unit of work that in total makes up a two week "deadline". Two weeks isn't enough to produce good code on anything more complicated than a boilerplate application.

Deadlines are far better. Tell me something needs to be done by next month it will be done. I can negotiate inside these bounds to prevent scope creep because a deadline is far more flexible than points. If you find yourself done with deadline work, you can refine and add touch ups. If you find yourself done with pointed work the PM will just assign you more work to "keep your points up" instead of allowing you to do the same.

The tyranny of the agile PM hinges on convoluted point systems. Even the one the writer prescribes. Force the management to actually agree on a deadline that is reasonable (not ship me facebook next week) and watch how productive and accurate developers can actually be. Read the comments here. Agile has been butchered to the point it's unrecognizable. Give me deadlines.

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.

I disagree as an IC of 10 years that's now gotten into eng management. Estimating is a useful tool that allows us to discuss upcoming projects, surface unknowns, and build team understanding of the projects we're committing to. It's a bad idea to throw the baby out with the bathwater here, despite some terrible software organizations. There's a lot of bad applications of good ideas, and we'd be at a pretty big loss if we threw all of them out.

I just want the real agile back.

The nice thing about a deadline is the tech illiterate understand them just as well as the people building it do. You can check in and have stand ups about the deadline all you want. You can even track work in tickets. Just no pointing. Ever.

How would the team have any idea whether they can meet a deadline without estimates?

I like the way we've set it up at my company. In product/engineering, we use our estimates and plan our projects in quarters and project more or less based on how many points teams have completed in the past.

Outside of product/engineering, we report milestones on our projects with expected delivery dates. We don't mention the points because they mean nothing to the rest of the business without context.

The only big problem I have with pointing is when those numbers are used as performance metrics or judged by outside stakeholders without context on the work. I think we've solved for that and get to reap the benefits

Are you using "sprint pointing" to refer specifically to the kind of pointing that you might discover in Scrum, or generally the idea of story pointing?

For the latter, my experiences and expectations seem so different from yours that it's hard to know where to start. I haven't experienced much full on Scrum to disagree.

Aren’t you saying the same thing the author is saying, except you flipped the words? Story points in your case are the arbitrary deadlines he’s talking about, and the deadline you mention is more of a preemption point used to negotiate scope.

100% this. No matter how arbitrary and irrational deadlines might seem, they at least work somewhat well.

Reply on news.ycombinator.com