 |
The primary goal of a product
owner is to represent the needs and desires of
the stakeholder community to an agile delivery
team, being the first source of information
about the problem domain for the team.
Each agile team, or in the case of large
programmes an agile subteam, has a single
product owner to go to for information and
prioritization of their work and they do so
right away. A secondary goal for a product
owner is to represent the work of the agile team
to the stakeholder community. In
traditional terms, a product owner is in many
ways an empowered
business analyst without the
burden of the bureaucracy surrounding
big requirements up front (BRUF).
The role of product owner was
introduced to the agile community by Scrum,
although the onsite customer practice of Extreme
Programming (XP) is very similar. This
role has been adopted by the
Disciplined
Agile
Delivery
(DAD)
process framework. |
|
As a stakeholder
proxy, the product owner:
- Is the "go to" person
for domain information
- Provides timely
information and decisions
- Prioritizes
requirements, defects, and
other work items for the
team
- Is an active participant
in modeling
- Is an active participant
in customer testing
- Helps the team gain
access to expert
stakeholders
- Facilitates requirements
modeling sessions, including
requirements envisioning
- Educates team in the
business domain
- Is the gateway to
funding
When
representing the agile team to
the stakeholder community, the
product owner:
-
Is
the public face of team to
project stakeholders
-
Demos the solution to
key stakeholders who weren't
able to attend the normal
iteration demo
-
Announces releases
-
Communicates team status
-
Organizes milestone reviews
-
Facilitates requirements
modeling sessions
-
Educates stakeholders in the
development process
-
Negotiates priorities,
scope, funding, and schedule
There
are
several
aspects
about
this
role
which I
think
are
critical
to
understand:
-
Product
owners
bridge
the
communication
between
the
team
and
their
stakeholders.
As
Figure 1
shows,
in
practice
there
proves
to be
two
critical
aspects
to this
role:
first as
a
stakeholder
proxy
within
the
development
team and
second
as a
project
team
representative
to the
overall
stakeholder
community
as a
whole.
-
Product
owners
are
empowered.
The
product
owner is
the
single
person
whom is
responsible
for prioritizing
requirements
and
for
providing
the
details
explaining
the
requirements
to
the
team.
At
scale
this
becomes
a
bit
more
complex,
as
you'll
see
below.
-
Product
owners
facilitate
communication.
Product
owners
need
good
communication
skills,
including
agile
modeling
skills.
They
also
need
to
know
who
the
stakeholders
are,
interact
with
them
regularly,
and
when
needed
facilitate
the
interaction
which
the
team
has
with
them.
Although
it's
convenient
for
deliver
teams
to
think
of
product
owners
as
the
"one
neck
to
wring"
because
it
puts
the
burden
of
requirements
responsibility
on
them,
the
reality
is
that
the
product
owner
can't
possibly
know
all
the
details
known
by
the
true
range
of
stakeholders
at
all
points
in
time
and
as a
result
will
need
to
bring
stakeholder
experts
to
the
team
to
share
their
expertise
with
the
team
at
appropriate
times.
The
implication
is
that
the
product
owner
isn't
always
the
direct
source
of
requirements.
-
Product
owners
prefer
direct
means
of
communication.
There
is
significant
evidence
that
the
worst
way
to
communicate
information
between
people
is
via
documentation,
and
that
the
most
effective
way
is
face-to-face
around
a
shared
sketching
environment.
Agilists
in
general
prefer
to
avoid
interim
documentation
and
instead
use
more
effective
means
for
agile
communication.
-
Product
owners
need
many
business
analysis
skills.
They
need to
be
skilled
in techniques
to
identify
stakeholder
needs,
negotiate
priorities
between
repeating
stakeholder
factions,
and then
collaborate
with
developers
to
ensure
that the
requirements
are
implemented
effectively.
This
is
business
analysis
101
stuff.
|
 |
Figure 1.
The role
of
Product
Owner.
Product
Owners at
Scale
Figure 2
depicts a typical organization
structure for a
large agile team. The
subteams will be organized
either around the architecture
of the system (a component team
approach), around the
requirements (a feature team
approach), an
internal open source
strategy, or combinations there
of. Regardless, each of
the subteams will need to have
access to a product owner
(although any given product
owner could work with more than
one subteam). The product
owners will be part of the
product owner team, lead by a
chief product owner. This
product owner team will:
- Manage the requirements
for the overall program
- Negotiate functional
dependencies between
requirements being
implemented by different
subteam, potentially
reprioritizing requirements
to reflect those
dependencies
- Manage consistency of
the requirements between
subteams
- Assign requirements
between subteams in a
consistent and sensible
manner
Figure
2. Organization
structure of a large agile
team.
To do these things the product
owner team will need to
coordinate regularly.
There are several strategies to
do so:
- Have their own daily
coordination meeting
- Have a regular, perhaps
weekly, meeting to discuss
any requirements issues
between subteams
- Adopt electronic
requirements management
tools
- Combinations of the
above
Where Do Product Owners Come
From?
| Although
a
traditional
business
analyst
could
fill the
role of
product
owner,
particularly
those
from the
business
side of
your
organization,
there is
a risk
that
they
will
fall
into
their
old
habits
of
communicating
via
documentation.
If they
can
overcome
these
tendencies
and
instead
focus on
collaboration,
knowledge
transfer,
and
skills
transfer
then
becoming
a
product
owner on
an agile
team is
clearly
a viable
strategy
for
existing
analysts.
Otherwise
the best product owners
are empowered
stakeholders who have
been educated, trained,
and mentored in the role
of product ownership.
Sadly, my experience is
that many product owners
aren't given adequate
training in their role. |
 |
 |
|
Agile Modeling: Effective Practices for Extreme
Programming and the Unified Process is the seminal
book describing how agile software developers approach
modeling and
documentation. It describes principles and
practices which you can tailor into your existing
software process, such as
XP, the
Rational Unified Process (RUP), or the
Agile Unified Process (AUP), to streamline your
modeling and documentation efforts. Modeling and
documentation are important aspects of any software
project, including agile projects, and this book
describes in detail how to
elicit requirements,
architect, and then
design your system in an agile manner. |
 |
|
The Elements of UML 2.0 Style describes a collection
of standards, conventions, and
guidelines
for creating effective
UML diagrams. They are based on sound, proven
software engineering principles that lead to diagrams
that are easier to understand and work with. These
conventions exist as a collection of simple, concise
guidelines that if applied consistently, represent an
important first step in increasing your productivity as
a modeler. This book is oriented towards
intermediate to advanced UML modelers, although there
are numerous examples throughout the book it would not
be a good way to learn the UML (instead, consider
The Object Primer). The book is a brief 188
pages long and is conveniently pocket-sized so it's easy
to carry around. |
We actively work with clients around the world to
improve their information technology (IT) practices,
typically in the role of mentor/coach, team lead, or trainer. A full
description of what we do, and how to contact us, can be
found at Scott W.
Ambler + Associates.
 
|
