do by eliminating one kink at a time. The highest priority features then can be worked through to acceptance, by completing chunks small enough to have potentially shippable software ready for use at the end of each iteration.
Scope verification is accomplished within each iteration, as customers get to review, test, and accept the implemented features. Ideally this happens throughout the iteration, but it can also happen at the end of the iteration during the demo of the working code. Those features that were not accepted (either because they weren't ready or weren't right) move into the backlog or into the next iteration. The management of this backlog addresses scope change control, as discussed in Part 1 of this series of articles.
You can see that PMBOK best practices aren't really that different from agile methods; they're simply done more often, iteratively and incrementally, with the attention to detail that's appropriate for the timeframe. This means that scope has the potential to change at the end of every iteration, as new information is learned about the technology and the customer's preferences. And because it's the customer who's deciding what the team should work on next, satisfaction rates rise with every iteration.
In my next article, the third in this four-part series, I'll discuss quality management and risk management in agile projects.
Click Here to Read Relating PMBOK Practices to Agile Practices Part 1 of 4
Click Here to Read Relating PMBOK Practices to Agile Practices Part 3 of 4
Click Here to Read Relating PMBOK Practices to Agile Practices Part 4 of 4