Hacker News Reader

Comment by wonderwonder | Hacker News Reader

I worked at a company for a couple years where you had to produce 10 points a week or you got pipped. Didn't matter if you were a jr or sr. I worked on a few teams there and you could immediately tell how the teams measured points by the stress level of the developers.

Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week.

Teams that gamed the system and understood the impossible task they were assigned always gave the highest points total to a ticket they could or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers.

In an environment like that playing by the rules is a suckers game.

When I eventually quit, every sr engineer at the company; 7 total, followed me within 4 months.

View on HN

> ...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.)

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.

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.

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.

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

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.

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

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

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.

> Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week.

So in the short term, the company benefited, yeah? They got more work out of the same people than they would have if they didn't apply the pressure.

Reminds me of an old boss I had who would flat-out say that to get a project done we would "hire someone and burn them out" - he planned to only get six months of useful work out of someone, and if they were stupid enough to stick around for high stress and low pay, that's just a benefit to the company.

(I didn't last very long there either)

The question is whether you get more volume but lower quality: a team doing 60 hour weeks on a regular basis tends to be a team baking in lots of technical debt and skipping “slow” things like “do we really understand what our users really need?” or “did we correctly architect this?” Everywhere I’ve seen this there’s been a lot more rework and things like high infrastructure bills because people have [correctly] learned that the business doesn’t care about quality.

Sure, if they were going to do layoffs in 6 months anyway, I guess this anti-pattern was coporate's wet dream. them quitting means they don't even have to bother with severance packages.

But it sure is a shame we're past the days where you actually want to retain and nurture tribal knowledge. imagine if other engineering disciplines simply hopped companies every 2 years, or if they cut half their civil engineers for a better earnings call (thankfully, he government doesn't have "shareholders". just taxpayers to disappoint).

I don't think they did. If churning out low-quality code for 6 months was good project management, the Linux Foundation would be doing it.

"So in the short term, the company benefited, yeah" In hind sight, they did not. The company is publicly traded and recently sold itself for parts to avoid bankruptcy. They are in a very niche industry and are notorious for their production environment going down, and massive data corruption in their clients data set. There are worse things as well but I am trying to be at least a little anonymous here.

We called that Scrumflation at a past company. Didn't finish everything for the week? Claim the ticket was done and open a bug for the uncompleted work.

Goodhart's Law - "When a measure becomes a target, it ceases to be a good measure"

My anecdote about this is a case where I was an external consultant in a company.

The management decided to base bonuses on "number of open tickets assigned to a person measured on day X". Smaller being better.

(Un)surprisingly I got a bunch of tickets assigned to me on day X-1 and they were reassigned on day X+1. I didn't mind, since my bonuses were determined by customer satisfaction =)

The ironic thing is that may have generated exactly the outcomes management wanted.

I’ve worked at places where it was more important for management to know what to expect than to achieve raw productivity towards a goal.

The people who were estimating in good faith may have assumed that management was acting in good faith. Whereas a lot of projects are created aspirationally or have artificially short deadlines to “motivate” people. The stress they incurred may have just been for the emotional satisfaction of a manager and not have provided any more value than that.

Seems like it would just incentivise every ticket being estimated as something like an 8.

Even in an environment where story points essentially mean nothing it already ends up with some people just wanting to put high numbers on everything.

Thats exactly what happened. People that tried to do it right, got punished as they ended up working weekends all the time. People that did as you suggest and went high, were stress free.

Points are a relative value.

If its 10 points a week then you estimate based on the assumption that 2 pts is a days worth of work.

That, coincidentaly, is what ours roughly shakes out to be.

Sounds like the stressed teams were lacking in common sense.

What happens if you underestimate one time? You get a pip. Better to overestimate.

What you need to do is to multiply all costs by ten. That way even if you underestimate one week you are not threatened by this insane metric.

Measuring story points across the company is such a weird thing. The meaning of points depends on the team. Like you can decide to multiply all the feature costs by 10 from one sprint to another if you want to.

The only usage of points is to improve the predictability of the output of a team. It cannot be used to measure performance in an absolute way.

If performance metrics are built on points, it just ruins the meaning of points. There is no reason to be honest anymore.

>Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week.

I read this as the teams that attempted to measure in good faith did a poor job at estimating. If management tells you that you are required to deliver 10 points per week, then 10 points should take you 40 hours with rare exception. Whatever other idea you had in your head of what 10 points "should" mean is simply incorrect.

Reply on news.ycombinator.com