Every project is initiated with a set
of objectives. Your current project
may be to create the world’s best word
processor. Creating the world’s best
word processor, however, will
typically be only one objective for
this project. There will almost
certainly be additional objectives
regarding schedule, budget, and
quality. These objectives can be
thought of as the the customer or
product owner’s conditions of
satisfaction — that is, the criteria
that will be used to gauge the success
of the project.
Way back when I was in high school and
assigned to write a paper about a book
such as Moby Dick, I would always ask
the teacher how long the paper had to
be. She’d respond something like “Five
pages,” and then I knew her primary
condition of satisfaction. There were,
of course, a number of additional,
unwritten conditions of satisfaction,
such as that the paper would be well
written, my own work, in English, and
so on.
At the start of release planning, the
team and product owner collaboratively
explore the product owner’s conditions
of satisfaction. These include the
usual items—scope, schedule, budget,
and quality—although agile teams
typically prefer to treat quality as
non-negotiable. The team and product
owner look for ways to meet all of the
conditions of satisfaction. The
product owner may, for example, be
equally satisfied with a release in
five months that includes one set of
user stories as with a release a month
later that includes additional user
stories.
Sometimes, however, all of the product
owner’s conditions of satisfaction
cannot be met. The team can build the
world’s best word processor, but they
cannot build it by next month. When no
feasible solution can be found, the
conditions of satisfaction must
change. Because of this, release
planning and exploration of the
product owner’s conditions of
satisfaction are highly iterative, as
illustrated in Figure 3.2.
Figure 3.2 Conditions of
satisfaction drive both release and
iteration planning.
Once a release plan covering
approximately the next three to six
months is established, it is used as
input into the planning of the first
iteration. Just as release planning
began with consideration of the
product owner’s conditions of
satisfaction, so does iteration
planning. For an iteration, the
product owner’s conditions of
satisfaction are typically the
features she’d like developed next and
some high-level tests about each
feature.
As an example, consider a travel site
that includes the user story “As a
user, I want to be able to cancel a
reservation.” In discussing this story
with the product owner, the developers
learn that her conditions of
satisfaction for this story include
- A user who cancels more than twenty-four hours in advance gets a
complete refund.
- A user who cancels less than twenty-four hours in advance is
refunded all but a $25 cancellation
fee.
- A cancellation code is displayed on the site and is emailed to the user.
Like release planning, iteration
planning is iterative. The product
owner and the team discuss various
ways of best meeting the conditions of
satisfaction for the iteration.
Feedback loops are shown in Figure 3.2
from the resulting new product
increment back into the
conditions-of-satisfaction boxes at
the start of both release and
iteration planning. Based on their
experience developing the product
increment during the iteration, the
team may have gained knowledge or
experience that affects planning at
one or more of these levels.
Similarly, showing the product
increment to existing or likely users
may generate new knowledge that would
cause changes to the plans. An agile
team will incorporate these changes
into their plans to the extent that
they lead to a higher-value product.
All this is very close to your understanding (although I ideally prefer the PO to provide the Acceptance Criteria rather than validating the ones developed by the team).