Hacker News Reader

Comment by Arcanum-XIII | Hacker News Reader

And now we’re abused by velocity chart, retrospective about our failings, continuous change because we’re agile, under pressure all the time because of the two weeks « sprint » which end being a disguised death march…

So how is it any better?

View on HN

I worked at a place where the managers did everything they could to close out all the points by end of sprint, no matter what. A co-worker is taking longer than expected, says there is no way he'll be done in couple of days... so we close out his story, declare it done, and open a new one in the next sprint for "testing", "deployment", or whatever it takes to claim the points and move something into the next sprint.

I found this truly sad. If you want accurate "velocity", you need to track it accurately. Our estimates were wrong.

Seen exactly the same, sadly not just in one shop. Half completed stories would be split into part 1,2,3, or worse: renamed to "Attempt to implement...", just to make the burndown chart align at closure of sprint and give people the pleasure of dragging items to the done-column. Didn't get better when some higher up scrum master once had the brilliant idea that all stories should be max 2 story point large, otherwise need to be refined further. Together with a company-wide policy that a story point is roughly equal to one day, for all teams, because it made the high level jira dashboards easier to aggregate.

Not sure what it was meant for, since with this practice it would tautologically just show headcount * days in a sprint. More like time reporting rather than measure of progress.

The beautiful thing is there is a built into Scrum solution to this.

You alter estimation.

The fact story points are made up BS numbers means developers have full control over the velocity chart.

My favorite part of Scrum is it makes it IMPOSSIBLE to track velocity.

By making velocity IMPOSSIBLE to track, management MUST pivot to OKR lead management.

And OKR lead management is by far the best approach to software development.

If your estimates are too crazy, you are forced to break them down into smaller tasks. This means lots of meetings. I think most engineers would rather have a bad estimate and "face the consequences" (generally not much), rather than put up with more meetings.

Can you describe "OKR lead management"? I am familiar with OKRs.

And at the very least with waterfall they thought about their requirements, now it's: shove 3 sentences in a JIRA and off you go, clairvoyant developer!

Reply on news.ycombinator.com