[MUSIC PLAYING]
SPEAKER: Hello.
Let's talk about one of the most important roles of an API
program and agile--
the API product owner.
In agile, the private owner is a central role
within the team and the program.
From defining the product to guiding the API
team during a review of finished work,
everything should be in the view of the API product owner.
A great Venn diagram, courtesy of Henrik Nyberg,
positions the product owner role in the middle
of 3 responsibilities--
build the right thing, build the thing right, and build it fast.
The scrum definition of product owner
translates very well in the API context.
The API product owner is a key leadership role
when it comes to how API products should be produced,
and how it is being consumed upstream in the digital value
chain.
The product owner needs to have a connected and empathic
relationship with developers, experience designers,
and businesses leads that use the API
products to deliver on the experiences for the customer.
The API product owner also has to keep a handle
on how the API team is producing API products,
and how they're connecting into the back end
systems of the enterprise.
The API product owner is often very busy,
and the role can be quite challenging in the context
switching that is required.
For example, in the morning, the product owner
may be speaking with digital businesses leads
to plan new experiences that require additional APIs
in the next release.
Later that morning, the product owner
may be working with the scrum master and API architect
to manage the backlog and prioritize which stories are
to be worked on in the upcoming sprints.
In the afternoon, the product owner
may be reviewing the results of a recent spring and the APIs
with developers and testers.
In the last session of the day, the
is meeting with APIs architects and IT leadership
about potential changes that need to be made downstream
to systems, because the targets of the back end have changed.
What a day.
One of the key mindset traits of product ownership
is to evangelize APIs as truly products.
The way the product owner drives the communication,
the packaging, the documentation, and delivery
of each API, will heavily influence how
APIs are consumed and produced.
This might manifest in the form of API roadshows, hackathons,
or building a really easy to use and self-service developer
portal.
To summarize, the role more concretely,
the API product owner, or PO, as often called,
is responsible for the following.
Defining and delivering value but making decisions
for the team on what's more valuable,
defining the product backlog, prioritizing
the sprint backlog, defining requirements
as well as the definition of ready and done,
and because of the cross-functional demands,
a background in product management and web
based technology is a key skill set.
The API product owner has to be very involved
in the day to day sprint process.
However, depending on the size of the organization
and the number of APIs in the maturity of the API ecosystem,
this might not always be feasible or practical.
It's really important for the product owner
to recognize when demands from people and teams
become too great for the hours a product owner has available.
This self-awareness is critical since the product owner
can often become a bottleneck in the process.
In addition, since the API product owner also
needs to network across the digital value
chain for upstream and downstream stakeholders,
the scope can simply be too broad to go deep
with the development team.
In these cases, it is essential that the product owner
figures out how and where to delegate authority.
One such example is in sprint refinement.
And refinement sessions elaborate and use cases,
writing BDD use cases, and collaborating real time
with the API architect, developers, testers,
and scrum masters really requires a pretty heavy focus
and time.
If there are multiple API teams or demands on building up
the API program buy in with business and IT leadership,
this job can be very intensive.
The API product ownership bring on a business sense
that can act as the proxy to the product owner.
It's important that the product owner trains and transfers
ownership and decision making authority to the business
analyst.
The business analyst must have the authority
to make design and requirement decisions.
If there are certain thresholds that decisions cannot be made,
those lines also need to be made clear.
Looking more strategically, managing the backlog,
and the overall product roadmap is also a critical activity
for the product owner.
However, when it comes to backlog management,
the API product owner may not want to give up full authority
to the business analyst.
Certain priorities require organizational perspective
to determine what should be in an API release.
These decisions may have many strategic implications
for the overall digital transformation,
and the overall API product roadmap in orchestration
with upstream and downstream projects.
However, when it comes to the sequence in which an API
or user story should be built within a sprint
or sprint by sprint, a business analyst in collaboration
with the scrum master and API architect,
can make the decisions within the team.
At the end of the sprint, the features
develop should be up for group demonstration.
This is called a sprint review, or sprint demo.
This demo could be to the team, to the end users like app
developers, or with other interested business
stakeholders and executive sponsors.
There are several motivations to demo or do a review.
They don't have to be all crammed into one session,
and multiple demos might make sense.
Scrum provides frame-working guidelines
but it's up to each team, with the API product owner,
to discuss and determine what is the right audience and outcome.
The product owner should make the final decision on this one
as it relates heavily to how the organization will
perceive the API program.
Here are some common reasons for a sprint review.
These demos can be run by executing on a Postman
or Gherkin file, or create a simple web
app called to show how the API can be used
to illustrate a visual example.
The one thing we caution against is to use the demo as a sign
off stage gate.
Demos are often too short to allow any stakeholder, ,
a product owner or tester, to do a final acceptance.
Furthermore, the time spent to orchestrate a demo
and QA at the same time can be very inefficient use
of the team's collective time.
All testing acceptance should happen
before the sprint review.
If there isn't enough time, don't rush the sprint review,
and do it after the sprint is over.
Focus on the big picture.
Use the demo to garner excitement,
celebrate accomplishments, and gather business feedback.
Thank you.
I hope this section helped you get a deeper look
at the role of a product owner.
It's a complex role, and each product owner we meet
is different.
And what you learn can be adapted and modified based
on your style, context, .
And organization.
In addition, the role can be split between multiple people
owning different parts.
There's not just one way if you want more information,
please check out the community for ebooks, articles,
and other related topics.
Thank you again for watching.