A follow-up to the sunk cost post. While easier said than done, how do you make the choice between cutting a feature (or features) you’ve sunk so much time into or just giving it more to complete it?

Determining scope is actually the main responsibility of the production team. It is up to the producers to look at the amount of work being done (e.g. tasks, bugs fixed, etc.) over time to calculate the team’s “development velocity” - the rate at which the project is approaching its goal. If the team’s calculated velocity is on target to reach the goal, things are good - everyone keeps doing what they are doing.

If the team’s velocity isn’t enough to hit the required goal, then changes must be made. Either the velocity must increase (e.g. hiring more people, be more productive, crunch, etc.), the goal must be reduced so the current velocity can hit it (e.g. cut features and reduce scope), or some combination of both must happen in order to reach that goal. When deciding whether to cut a feature, the largest determining factor is the priority of the task. If the feature is low priority, the decision to cut is easy. If the feature is a major part of core gameplay, it is likely much too important to cut. Lower priority tasks always get cut first.

Production may choose to cut the sunk cost feature, or they might try cutting other lower-priority tasks to put more resources into the sunk cost feature. If the sunk cost feature is mission-critical it may fester and metastasize like cancer and end up killing the entire project. It certainly would not be the first project that was destroyed by throwing too much of their resources away on a pipe dream.

[Join us on Discord] and/or [Support us on Patreon]

Got a burning question you want answered?

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *