Does everybody buy this?
Scope is defined this way:I hope you're buying; that's the way I wrote in the 2nd edition of "Project management the agile way"
• Scope is all the things we must do, all the things we want to do, and all the
things we actually do
• Backlog is the scope parsed into work units, stories, use cases, tasks, and
the like
• Architecture is the scope mapped into form and function
Of course, "... all the things we must do, all the things we want to do, and all the
things we actually do" probably don't fit in v1.0 ... that's why we have v2.0. That's why we do release planning and that's why we parse the backlog to fit project capability and capacity.
Waxing on: There are some must-do's that influence scope— must-do's as a matter of
governance and must-do's as a matter of custom and expectation.
Now, the lecture: Projects must adhere to standards that have become generally accepted practices; processes and protocols must be applied in a manner that is consistent with certifications; and projects must meet the unspoken demands of the market that, over time, have become routinely expected—demands for reliability, availability, compatibility, responsiveness, and eco-friendliness, to name a few.
Bottom line: Scope is too important to be left to the customer/user. There's a lot stuff to consider for which they don't bring the clues
Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!
Read my contribution to the Flashblog
