Hacker News Reader

Comment by crazygringo | Hacker News Reader

> ...or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers.

But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns.

I'm not saying this was a good workplace, it doesn't sound like it at all. But to me, it sounds like the devs who you think gamed the system, were mostly behaving the way scrum is meant to incentivize. Happy, stress-free development that delivers consistently improving software.

(Minimum point totals per week leading to inflated point values is terrible management, though.)

View on HN

I think what the GP means by “gaming” the system is that the teams did all the technical activities of scrum without providing much or any business value.

The issue with scrum or any process that involves estimating is that every software project will inevitably have some risky element or difficult to estimate task that is essential to the execution of the project. Scrum will incentivize teams to avoid the essential work and guide them towards work that is easier to estimate.

Certainly having a good product owner can mitigate this because she can do the work of identifying and breaking down the intractable to something more actionable.

But in that case you’re depending on the people on the team to make good choices. Smart people can do that regardless of the development process they’re using. It’s unclear what value scrum brings to teams at all. It doesn’t make bad teams work any better and it restricts how smart teams can operate.

One thing that scrum does give is it provides management metrics they can use to measure performance.

"every software project will inevitably have some risky element or difficult to estimate task"

You are exactly right here. At this company though, that risk on a personal level could mean a pip. So the happy teams inflated the story points massively to ensure that any or no risk was accounted for and they survived to code another day.

“Story points” help you predict your work in the future. Knowing what and when you deliver can be valuable!

Say you’re developing software for the next Super Bowl broadcast - it’s useful to know whether you’ll deliver what you said you would. If it’s looking like you can’t, you can start to make educated decisions about what work to cut and get a better idea of what you actually will deliver.

The criticism of the GP is that teams at his company would estimate story points differently depending on how much stress they wanted to take on and not based on the complexity of the work. This had the impact of the low stress teams not taking on ambitious work. Whereas teams that would take on ambitious work and attaching points to that work were working at unsustainable levels to meet targets.

In your Super Bowl example, you'd either get a team that would focus on doing the scrum activities but never deliver anything useful regardless of how many points it would take, or you'd get a burnt out team that's on the verge of flaming out. In either case "Story points" provide you with no predictive capacity even though predicting would provide value.

The predicting value is only per-team. If your team does 10 points per sprint, it won't deliver 20. If it does 100, it will.

But it's an important tenet of scrum that velocity is only meaningful in a single team[0], the root management failure in OP's case is comparing different teams.

[0] and teams cheat themselves too. I recall one advice early in my career that a velocity increase with no underlying process change was likely to mean.. that the team started to overestimate complexity, and one should understand what went wrong.

If your team is doing mostly similar work and the team has the same composition for a long period, points can have some meaning.

When a team shifts projects, and changes members, there are too many variables and not enough data points, so points become useless.

Since most teams change both of those thing fairly frequently, in the close to 20 years I’ve been doing this, points are generally not helpful.

They don't help you do that, even though poor non-technical managers might think they do. That's why good software projects don't use them. I don't see any story ticket velocity points used in Linux kernel development.

You can't estimate non-trivial software, and if you are doing trivial predictable work, you should be automating it, not endlessly estimating it.

I didn't say I would "deliver" anything. It's done when it's done. You can't predict the outcome of a software project. Many of them fail and micromanagement makes them more likely to fail.

> You can't estimate non-trivial software, and if you are doing trivial predictable work, you should be automating it, not endlessly estimating it.

so if you automate trivial predictable work (for example by making a CRUD app generator), you're moving to non-trivial software territory with costs unknown (as you said, you can't estimate), potentially very high

Or you don't and end up making a non-functional website for the public sector for $100M. Software projects fail often, and not for the lack of trying, there is not yet any evidence that you can micromanage them into succeeding.

OP here. You are right, but the minimum point totals eliminates any benefits that can be achieved from scrum, it forces engineers to incentivize survival over project momentum. If a story is really a 3 pointer but I know that if I close 2 3 point stories in a week then I am pipped, suddenly those 3 point stories are 5 point stories.

On the teams that played fair, it was a mix of sr. and jr. and the sr. measuring that story at a 3 meant the jr. was working the weekend. Over and over again.

Note: On the happy team, we had almost no supervision, not even a scrum master. We just looked out for each other. That 3 point story often suddenly became an 8 as the end of the week approached and no one blinked. That team incidentally was the only one that consistently got good reviews from management.

> teams that played fair

What does "played fair" mean? Did this organsiation have a fixed definition of the value of a story point?

EDIT: The reason I ask is because when story points are used "correctly" their value is defined entirely relative to the previous output of the team which produced the estimate. Like, their purpose is to allow dev teams to do relative estimation (which is pretty easy to do), but also enable someone to produce absolute estimates based on the team's track record of delivery. Team says a story is a 5 pointer? Query previously delivered stories which the team also said were 5 points and if there's enough data you'll be able to forecast with reasonable certainty how long it will take them to deliver this new story. Used this way there's no "fair" value of a story point - it doesn't matter if one team uses point values in the range 0 - 1 while another uses point values in the range 1,000 - 1,000,000.

The whole thing breaks if you start comparing point values across teams, or say that 1 point is 1 day's work or whatever.

The point of scrum is to provide employment for consultants and non-engineers.

I left engineering for an engineering job in finance. No scrums, no POs, just trader driven development and I haven’t looked back once. Glorious.

"The point of scrum is to provide employment for consultants and non-engineers" I'm actually starting to believe this. I work for a very large company that switched to agile. We have agile / scrum coaches in pretty much every big meeting and I have yet to hear one say anything. I don't mean anything useful, I mean anything at all. They just sit there blinking. I have no idea what they do.

When someone doesn’t have anything to say, I very much prefer that they say nothing at all. Especially in meetings.

You’re missing the point, it’s not about scrum it’s about making the work look like it’s way more than it is to pad the metric.

What Scrum "intends" to do, and what it actually does, are radically different.

Yes, nobody has ever really explained to me how you handle problems that don't neatly decompose into simple tasks.

In my experience this is usually handled by pushing back on the requirement or kicking the can down the road.

> But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns.

Maybe as-written but not really ever as-practiced.

They were splitting tickets to avoid being let go, not because they necessarily warranted it or comprised logically separate things. I'm pretty sure that's not how scrum is supposed to work, but if it is it doesn't sound good to me.

Stress free and delivering at a predictable rate. Nailed it.

Delivering arbitrary points at a predictable rate, yeah, brilliant.

When there's a good, engaged PO then Scrum can work.

Reply on news.ycombinator.com