
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.