An iterative process with an increasing scope is totally fine.

Using it as an excuse for crunch is insane, because an iterative process with increasing scope needs to also have a flexible deadline.

If you routinely run out of employees in your change of scope, you might just need to hire more people from the start.

Sure people cost money, so why hire them when you can exploit the ones you have already? The only way to stop that are unions/worker rights.

Can't change the holiday season timeline.

"Activision Blizzard employees developing the upcoming dark fantasy action role-playing game “Diablo IV” say it will be hard to meet a June 6, 2023, release date without working significant overtime, in a process they say has been plagued by mismanagement."

Not exactly a holiday release.

That gives them 6 months to get the servers reliably online, if I recall Diablo III correctly...

If you cant change the time line, don't change the scope. This isn't rocket surgery. This late into the project, the scope should be well defined.

I mean, especially in this era of DLC, why the need to increase the scope, anyways? Punt the extra ideas for later release.

I don't think crunch works but trying to define game scope 3 years out doesn't work either.

That's how you get Half Life 3..

That's fine, but then you should aggressively limit scope expansion.

I love how scope "evolves" as if it was a natural process and not just the result of poor planning.

You can't plan for unknown unknowns.

If you develop a feature and it turns out the feature is not great, you can choose to ship a game that's not great, or fix it.

Once you have committed to a ship date and moving the date is no longer an option, fixing it means working over time.

These crunches often come from the team themselves who are identifying that things aren't as good as they could be, want to fix it, but don't have the power to push dates back.

Update: One problem is that creative teams are rarely satisfied, and would love to polish things forever. The production team needs to be constantly pushing back on the creative team to leave things alone and call it done.

Working out what is "good enough" is really really hard.

Update: Also, I wrote this comment before reading the article, and I don't mean to defend 6 months of crunch. That clearly _is_ bad management and exploitative. When you have a few bad features you can take a few weeks or a month to fix them. When you are 6 months out and only now just announcing a release date, there is lots you can do. You can cut the bad bits, you can hire more staff, you can move the date.

All software projects have changes in scope. And yes, that scope evolves. You get new customers (internal or external), new feature ideas, and functionality that is discovered to be unwanted or too complex.

And deadlines are moved or features are cut in order to make them. “Pizza during weekend at the office” is just bad planning.

For a game the scope evolves since you can't know how things play or feel until you test it.

So if your plan for the game is not fun when you play it, you should just ship a turd sandwich?

That's what Ubisoft does.

Like any project, sometimes you have to drop the game and work on something else. Ideally using the assets you have from the failed game.

It's not an unusual tack to take even for regular software developers. Not all feature work. Smart folks will cut bait and focus on something that does.

I feel like my team lead has forgotten what iterative means, and expects much shorter turnout times in recent months for things that will absolutely not fit into a 2 week sprint. Since he kept going on about tickets that were getting stale due to last-minute unrelated scope expansions and me not being able to reprioritize new commitments on old tickets, I've just started being more strict. No, this ticket intended to literally just fix a typo is not also going to fix this unrelated bug qa discovered while testing.

I've found success in cutting tasks up in things that will fit in a sprint. If I have to write a feature, I commonly split it into a few tickets:

- Write the code - Test the code - Documentation changes - Deploy the code

If it's a big enough change (or a new app), I might create a few sets of those tickets. E.g. one "write/test/document/deploy" set for the database schema to do Y, another one for the business logic to do Y, another for the HTTP endpoints for Y, etc.

The tickets are specific to the implementation, not to the feature, so they can't be expanded. New work can only come through new tickets, which get prioritized. Manager is happy because tickets get cleared. I'm happy because I can fight scope creep by pointing to my sprint and asking which tickets they want to bump for their new scope creep.

Tickets like "implement X feature" with a 2 week estimate are a landmine for engineers because it's broad enough for the scope to expand infinitely, and it starts to look like nothing is getting done to management.

This is similar to what I've been thinking, but on the frontend. Tests/Design changes/Core JS for x. Seems like the only way.

> No, this ticket intended to literally just fix a typo is not also going to fix this unrelated bug qa discovered while testing.

That's basically how it is supposed to work. If you need something to get fixed, create an item/bug for it and let it get prioritized.

I think this is a top-down issue caused by people in charge who fundamentally do not understand development lifecycles. When the requirements change at all I have to completely reassess the timeline.

Alternatively, evolving scope is decreasing scope as they cut ever more critical parts of the game to make the fixed deadline. Either way it isn’t a good sign to be changing scope this late in the development process.

I’m not in the games industry but all the war stories I’ve heard trend in the opposite direction. They start out with really broad scope and then increasingly drop and cut content and features as the deadline approaches. The only time I’ve heard of features being stuffed in and blowing out the timelines is in the major boondoggle cases where management was a complete shambles and it’s far more than just feature creep that goes wrong in those cases.

It's not really an iterative process if you fail at every iteration.

Let's call it what it is: a series of waterfalls, all with unreasonable schedules

It was nearly 12 years from Diablo 2 to Diablo 3, and they didn't have to deal with a pandemic.

I don't think waiting another year for Diablo 4 will be the end of the world.

Though I'd like to see a WarCraft 4 someday too.

> I don't think waiting another year for Diablo 4 will be the end of the world.

Exactly. As I see it such things are much more crucial for games that might look/feel dated if they come out too late. The magic within the Diablo games (especially the first two) comes from the world it places us into, the way it is presented, the music, the story.

All of these are things that shouldn't break with one year of delay. The worst thing that xould happen with a Diablo 4, would be that fans of the series get the impression it was rushed.