Home  Spotlight Articles It's a Tough Job... but Somebody Has to be the Product Owner
|
It's a Tough Job... but Somebody Has to be the Product Owner |
|
|
|
|
Written by Tim Snyder
|
|
Sunday, 07 September 2008 |
 With so many corporate developers and IT teams beating a path to
Scrum adoption there seems to be a lot of ScrumMaster training (both certified
and otherwise) as well as coaching going on these days. Putting aside any worries about people
receiving just enough training to be dangerous (e.g. 2-3 day ScrumMaster
training is available from many sources) for moment, most of us think this
trend towards Scrum and Agile Development is a very positive one indeed. That said, what concerns me the most is what
I perceive to be an oversight of the need for product owner selection,
investment and support.
Having coached many aspiring Scrum teams, I've noticed a trend or
two among the converts. In particular I've witnessed a considerable lack of
understanding and commitment when it comes to the significance of the product
owner role. This is evident every step
of the way, from initial selection of the person to play the role of product
owner, to the lack of time dedicated to product owner duties, to the failure to
recognize the need for investing in skill development (training, coaching, etc)
for the role. In far too many corporate
environments that are making the move to Scrum or similar Agile development
methods, it seems that the assignment of product owner is all too often an
afterthought. Many an IT/Product development group dons their current
development manager/director with the added moniker of product owner. In other
cases they nab someone from the marketing team and hand them the designation,
with little thought as to just how much work is involved, let alone getting
them the proper help (training or coaching) that they really need.
The product
owner is a crucial, full time role in Scrum and it is a demanding one. The product
owner is ultimately responsible to the creation of the product. They own the
backlog, reconcile the needs and interests of all other stakeholders,
prioritize the sequence of items in the backlog, provide feedback and guidance
to the Scrum team, and ultimately pull the product they want from the Scrum
team according to their vision.
So what's a newly appointed product owner to do? Well, the first
step is to gain a better understanding of the responsibilities of the job, and
a good second step would be to gain some appreciation for the effort required
and skills necessary to fulfill these responsibilities.
Scrum is a collaborative game that emphasizes personal
responsibility. So we'll start by identifying a few of the product owner's
responsibilities that are key to success. These include:
-
Reconcile stakeholder requests
-
Manage the product backlog
-
Participate in the planning events
-
Inspect the product and provide feedback to the Scrum team
Reconcile stakeholder
requests
The product owner is not likely the only source of product
requirements. There may be many stakeholders who request functional,
performance and other capabilities. The IT Infrastructure group may require
that the product abide by certain security constraints and policies. Operations
and Support may require that all company applications meet their logging or
traceability specifications, Marketing may insist on particular branding or
user interface guidelines. Even the essential business functionality may aim to
satisfy the needs of a user community that includes several business units.
The one thing that all of these stakeholders have in common is
that they all probably want their particular requests met first. It's up to the
product owner to weigh these requests, as well as the purpose and value behind
them, and determine which requests will be met and when. The product owner is
the arbiter of stakeholder requests.
Information should flow in both directions. It is easy to fall
into the trap of thinking of stakeholders as requirements donors, who make
requests and get to see their results when the product is released. But that's
counter to the principles of Scrum and likely to lead to very unhappy
stakeholders. Keep that name in mind: stakeholders.
These folks have a vested stake in the success of the product. As product owner,
it's important to wear the hat of promoter.
Keep your stakeholder community aware of the progress of the product. Since the
best way to judge progress of product development is by inspecting the product
itself, make sure your stakeholders have frequent and easy access to the
product increments as they emerge from each sprint. These folks should at least
receive demos at the end of each sprint. It would be better if they also have
access to an internally hosted copy of the most recent product increment and
encouraged to take it for a spin at
will. Regardless of how far you or your team is prepared to go to accommodate
informed stakeholders, the product owner should make it his responsibility to
keep the stakeholder community engaged in the process.
Manage the Product Backlog
I don't want to get into the mechanics of backlog management here,
but it should be said that the product owner is in many ways the owner and gatekeeper
of the product backlog. That is, everything on the backlog has been placed
there by the product owner. The items may have been conceived of, and requested
by others, it is the product owner's duty to vet the requests and ensure that
the items on the backlog do belong there, and presumably adhere to some vision.
The backlog must be sequenced,
and the sequence maintained as new
items appear. Many refer to this as prioritizing
the backlog. I can live with that word too, but prefer sequencing because a sequence emphasizes the need to make explicit
choices about what comes first, when comes next and so on. To some, prioritizing implies determining business value. While business value may
constitute the biggest consideration in sequencing, other attributes may also
play some role.
Depending on the volatility of your backlog, a product owner may
need to pay weekly or even daily attention to an evolving product backlog.
Participate in the
planning events
Agile teams plan at multiple levels. Mike
Cohn's planning onion offers a great summary of the planning events pursued
by agile teams. Two significant planning events that are common to Scrum teams
are the release planning and sprint planning events. Both require the
participation of the product owner. The sprint
planning event in particular is one that I'd like to call out.
Sprint planning is an event that takes place at the beginning of
each sprint. Sprint are typically two or four weeks in length. While Scrum
recommends monthly sprints, most teams that I've encountered prefer a shorter
period of two weeks. Regardless of the
length of the sprint, there are two fundamental achievements in sprint planning:
1. Select the scope (i.e. review the
backlog items, select the scope for the sprint, and ensure the team understands
the requirements in this scope).
2. Work breakdown (breakdown each
backlog item into the specific tasks necessary to implement and verify
completion. The tasks should be estimated in hours or days.)
While the second of these accomplishments is the domain of the
Scrum team, the first - select the scope - requires the full participation of
the product owner. To this end, during sprint planning, the Scrum team members
will want to review each backlog item in scope and ask the product owner to (a)
confirm the sequence of the items, and (b) explain what they will want to do
and see in order to verify completeness of the items when the time comes.
Confirming the sequence of the backlog is usually straightforward
enough. But clarifying exactly what outcome is desired for each backlog item
really is a skill. Consider the question "what
will it look like when it's done?" in reference to each backlog item. In
other words, when a team member tells you "it's done!", what exactly will you do and what
will you expect to see to verify that it really is "done". What does done look like? This clarity is
essential to the Scrum team.
Inspect the product and
provide feedback to the Scrum team
Everyone understands that the product
owner should inspect the product and give feedback to the Scrum team
frequently. The gap is in our understanding of the frequency. I find that many
aspiring Scrum teams assume frequently to mean once per sprint - i.e. at the
end of the sprint. In other words, they mistakenly assume that product
inspection means demonstrate to the product owner at the end of the sprint. I
find this to be a risky practice. When you inspect the product, you're likely
to find shortcomings. If you wait until the end of the sprint to inspect the
product, then you're likely to find shortcomings when you have no time left (in
the sprint) to deal with them.
A Scrum team should be engaging the product owner daily - or at
least every few days - to inspect progress to date and seek feedback on their
results and assumptions. Question: When do you not want to find gaps or
problems in any process? Answer: At the end. If you wait until the end of each
sprint to inspect the results of the team's labor, then whatever issues are to
be found will be found when there's no time (in the sprint) to deal with them.
On the other hand, if the product owner inspects the product daily (or
thereabouts) as I recommend, then the product owner should be able to
demonstrate the product to the extended stakeholder family at the end of each
sprint.
Conclusion: The Product
Owner Is Crucial
When coaching teams that are new to Scrum I tend to focus on getting
three things right first: A truly iterative lifecycle (i.e. sprints), good product
owner behavior, and Retrospectives. Anything and everything else that is
necessary will come soon enough if you can master these fundamentals. Teams who fail to select a good product owner
who will dedicate ample time to their responsibilities, and commit themselves
to develop the skills of product ownership are likely to fail at adopting Scrum
or realize the benefits of this empirical process.
About the Author
Tim Snyder is a Product
Development Coach and co-founder of Gemba Systems LLC. He and the coaching staff
at Gemba Systems help their clients learn to minimize waste and maximize the
throughput of business value. Tim and his family reside in Coppell, TX. He can
be contacted at
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
or via www.gembasystems.com
Comments () |
 |
|
|
|
Tags:
Click to add your tags...,
|
|
