Beware your project’s Schwarzschild radius
peternixey.com
peternixey.com
The Schwarzschild radius (sometimes historically referred
to as the gravitational radius) is the radius of a sphere
such that, if all the mass of an object is compressed
within that sphere, the escape speed from the surface of
the sphere would equal the speed of light.
--Wikipedia
I am unaware of a specific name for the concept that a larger rocket has diminishing returns because of the disproportionate addition of fuel weight. Like the article suggests, one has to wrestle with the payload requirements to get out of this trap.
The Scrum method advocates keeping two backlogs - a product backlog and a sprint backlog; the sprint backlog is created by the team off the product backlog at the beginning of a fixed duration sprint (and adjusted by the team if needed), and the sprint backlog belongs to the team, and can't be changed by the business / users (instead, new issues go to the product owner, who can add them to the product backlog for them to get picked up at future sprints). The team is supposed to produce something that is 'complete' for some definition of complete at the end of each sprint.
Because sprints are fixed in time (maximum of one month) and have finite scope (whatever items on the product backlog the team are able to take to completion), each sprint delivers iterative forward progress towards the long term full set of requirements, and even if the project runs out of money after a few sprints, the most important requirements will have been met. The product owner still gets to prioritise a backlog (the product backlog) according to business and user requirements.
Interesting, but if the team are choosing items from the product backlog there seems no guarantee that the product owner will get the stuff that they consider important done?
If the team assemble their sprint backlog, they'll do their own prioritisation which may not sync with the product owner's.
In a way, this reminds me more of something I read from a computing book as a child, about early time-shared mainframes, where when overloaded a mainframe would spend more time loading programs from disk to memory and saving them back than it would work on any program. At one point, called a "beached whale", the system is constantly loading and saving because there is no time for any processing, as too many processes are fighting for CPU cycles.