Sunday, September 13, 2015

The scope thing ...


Does everybody buy this?
Scope is defined this 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
I hope you're buying; that's the way I wrote in the 2nd edition of "Project management the agile way"

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!
http://www.sqpegconsulting.com
Read my contribution to the Flashblog

No comments:

Post a Comment