What is scope (baby don’t hurt me)

The other night in a pub, Neil and I (and @karhatsu ) had an interesting chat about what does “scope” mean. We kind of disagreed then and I think we still do:

Maybe it’s just semantics or because I’m not a native English speaker, but I don’t agree. Let’s dive into this a little bit by first exploring the most common use case of that term: “X is out of scope“. So what does it mean when you say that something is out of scope? To me, X in this sentence is:

  • A feature (“supporting single sign-on is out of scope for now”)
  • A hardware change (“hardware changes are out of scope for you guys, they’re handled by the HW team”)
  • A certain testing type (“I’m not doing performance testing yet, it’s out of scope for this story”)

Then again, when I hear “amount of work”, I’m immediately thinking hours or days as the unit. Amount of work could be 16 hours or 2 weeks for example. But, in my opinion it’s wrong to say that scope = amount of work. There is a correlation between the scope and the amount of work needed to deliver that scope, but they’re not the same thing.

scope

 

This image above tries to illustrate this difference. We have a “fixed scope” in our naive book store example but different amount of work needed between the two teams. You could also imagine that the amount of work needed to deliver that scope is variable to a single team as well.  Team A could reduce the amount of work needed by making the process better etc. You know, the usual inspect and adapt, but that’s not the point of this post.

So what, one could argue. Well, maybe it’s just semantics, but on the other hand it’s easier to communicate if the community shares same terms and concepts. At least I’m still going to be on my toes when discussing “scope” with Neil. =)

3 thoughts on “What is scope (baby don’t hurt me)

  1. There seems to be a penchent in parts of the agile community (the #NE parts) to redefine standard agreed upon terms. Starting with PMI – Product Scope. The features and functions that characterize a product, service, or result.

    Wikipedia says (referenced from PMBOK as well)

    Scope involves getting information required to start a project, and the features the product would have that would meet its stakeholders requirements.
    Project Scope – “The work that needs to be accomplished to deliver a product, service, or result with the specified features and functions.”
    Product Scope – “The features and functions that characterize a product, service, or result.”

    Redefining other terms like risk, real options, chaos, capabilities, seems to bring up the question – “did the author read the definition of the term in the standard project management dictionary?”

    With the scope defined, resources can be applied to deliver that scope. These resources, over the period of performance, define the “work” and the cost of that work. But this work is not the scope.

    It does take much of the challenge out when we read the directions.

      1. Thank you for your input.

        With wiser now with the terminology, I’m tending to think:
        – fixed product scope -> is a feasible option, can be done
        – fixed project scope -> problems!

Leave a Reply

Your email address will not be published. Required fields are marked *