SCRUM LOG JEFF SUTHERLAND - Jeff created the first Scrum team in 1993 and worked with Ken Schwaber to formalize Scrum at OOPSLA'95.
Together, they extended and enhanced Scrum at many software companies, helped write the Agile Manifesto in 2001, and authored the Scrum Guide.
Friday, February 03, 2012
The Importance of the Product Owner
Scrum Inc.'s Christine Hegarty wrote this today, just before she went on vacation, of course, so I'm posting it for her - jj
Here at Scrum Inc. we've been thinking a lot about the role of Product Owner recently. It's something that we see a lot of companies struggle with. It’s
common knowledge in the Scrum world that a good Product Owner will increase
revenue by keeping the backlog ordered so that we are producing the higher
value sooner. But just how they accomplish that isn't always clear. So we decided to offer the definitive Product Owner classes to help educate Product Owners on how they can increase business value and revenue. I've been working with Catherine Louis, CST, to launch our first
Boston-area CSPO this month. At the beginning of March, Jeff will be teaching the Product Owner course he has developed in Los Angeles.
In building the class, Catherine and I have
spent a lot of time discussing the importance of the role to a great Scrum
implementation. The following passages reflect some of our conversations about
the role of the Product Owner and I thought they would be interesting for the community to talk about.
What is it that makes the Product Owner (PO) role particularly
A: The PO is the person who can answer this
question: "Is this the right thing to do for the customer?"
That's a tough job! The PO is someone who is market facing: he's
able to craft and relay a vision. The PO is someone very close to the customer;
the PO is the owner of a Product Backlog and focused on bringing value (and
"delight!") back to the customer. He is also responsible for keeping
a Product Backlog ordered such that the items at the top of the backlog are
sized appropriately for the team to begin working on, and are ready to be taken
in for the first Sprint.
a role that can't be done alone: the PO is considered part of the team, and may
need to have many stakeholders assisting in ordering the backlog, making sure
we're taking into consideration the Pareto factor: i.e., the top 20% of the
backlog should contain the highest value.
Q: What are some of the key pitfalls?
A: Typically we meet new POs moving from a
culture of traditional batch/phased development, dealing with larger and
specialized teams, with a goal of upfront perfection and "requirements
traditional/waterfall development, the churn of requirements is discouraged,
and there is a perfect plan and associated goal to deliver value at the end of
a Release. We cannot discount the massive cultural change needed to
manage a Product Backlog that is emergent. We want to see a flow of value, customer
collaboration, self-organized smaller and integrated teams, with value driven
cultural shift is one that moves us from crafting a fail-safe plan we want to
execute and deliver at the end of a release, to a "safe to fail"
framework where we learn and improve each iteration. Making this cultural shift
allows us to turn this expected requirements churn into our competitive
Q: So this cultural shift
involves a lot more people than just the Scrum Team, including the Product Owner...
A: The PO is key to the transition to Agile, but
because it is a change of mindset for the whole organization, and a lot of
players need to be involved from the beginning, roles not normally thought of
as Scrum roles. Supporting roles in particular, should not be forgotten.
Take HR for example. We're
now formed in self-organizing, self-motivated and self-managed teams, and the
reward structure needs to be updated to acknowledge and reward team
performance. Imagine what might happen if that doesn't change. Take
Project Management: We're now formed in these same teams, yet there is a
Project Manager who is acting accountable for results asking for daily status
reports in weekly meetings.
In making a decision to move
from traditional/waterfall product development to Lean/Agile/Scrum, I recommend
looking at everyone who is involved from initial decision, to delivery of value
to the customer. Do not forget the cadre of supporting roles who need to be
there as Servant Leaders to remove impediments, clear the path, and support the
flow of value (the deliverables) to the customer. Everyone needs to be on
this page: For every decision you make, every day, ask yourselves "Is this
the right thing to do for the customer?" If the answer is
"no", then don't do it. If the answer is "yes", say
"hell yes!" and do it right away. If the answer is "I
don't know", take the decision to the Product Owner.