The scope of a project keeps expanding as new features are added
The scope of a project keeps expanding as new features are added in response to requests from stakeholders. This changing scope is frequently accompanied by changing priority.
The generic problem of UndefinedScope is discussed elsewhere. Here the scope is well defined, but the definition keeps expanding to include new features. That in itself is not a problem, assuming adequate approaches are in place to manage the process and prevent disruption. At its worst, the developers keep getting pulled off the work they are doing to start work on a new, high priority feature, and continue work on this until pulled off to work on a newer, higher priority feature. As a result, no features ever get completed. See also the related topics on distractions; ProductiveDistractions and UnproductiveDistractions.
One potential cause of this is where the project is suffering from LackOfVision. Where there is a VisionStatement, features can be validated against this to weed out requests for irrelevant features. Where features are relevant, the problem of feature creep is most severe in Waterfall (non-iterative) projects, where requirements, analysis and design keep getting revisited to accommodate the new features, thus little coding gets done. IterativeDevelopment can help cure this problem as long as it can be accepted that any new features do not get added to the current iteration, but must wait their turn at being included in the next iteration. This latter objective can be achieved by use of a WorkQueue. The manager responsible for this queue is thus acting as a FireWall shielding the developers from constant requests to change direction.
Modern Agile approaches take IterativeDevelopment as almost mandatory, and usually work from a prioritised list of requirements to determine what goes into each iteration. There are a couple of modern variants on the WorkQueue; Scrum has the ProductBacklog, while XP has the PlanningGame.