Avoid the risk of scope leap with your agile project!

runawayhorseOne of the main benefits of agile approaches to project management is that they don’t require the customer to finalize all of their requirements at the very beginning of the project which is very useful in cases where the customer only has a conceptual understanding of the scope.  So long as the customer or product owner has a good idea as to what the desired outcomes are, through the process of regular production of usable deliverables and the progressive refinement and reprioritization of requirements, the customer’s true needs will be elicited and satisfied.

The following image provides a visual representation of this approach:


Unfortunately, providing a customer with the flexibility to frequently refine scope could also result in the following illustrated scenario in which the set of requirements never seems to get distilled:


While the previous image is clearly a dramatization, what are some techniques to reduce the likelihood of scope never getting finalized?

  • Make sure there is a clear definition on the expected outcomes forthe project – keeping a distant landmark in sight means that even if you take a random walk or stray off course on occasion, you know where you’ll need to eventually end up.
  • Track the number of user stories or work items added or significantly modified per iteration – while one expects there to be an increase in these through early iterations, if you are not seeing the volume decrease over time, this is a clear sign of scope thrashing and should be raised with the customer and project sponsor.
  • Make sure the customer is kept regularly apprised of time, funding and work items remaining.  If there is no connection between work requested and effort or time remaining, there may be less impetus to make decisions, especially if your customer is a perfectionist!
  • Release deliverables for use by staff frequently – so long as these deliverables remain within the project, there might be the perception that they are not “done” which would encourage further tinkering.  Once they are actively being used by staff, it’s a lot harder to make changes without some reasonable justification.

Critics of agile will say that it encourages scope creep but I’d argue that is an implementation issue and not an agile principles issue – regardless of the approach taken to managing a project, a little bit of discipline will go a long way!

Categories: Agile | Tags: , | Leave a comment

Post navigation

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Create a free website or blog at WordPress.com.

%d bloggers like this: