The team is conducting a proof of concept related to checking the capabilities of an external software solution to be added/integrated into our platform. The PO needs to have all Epics and Stories ready and prioritized for team planning, but are there any other responsibilities that that PO should own in this situation? For example, who should communicate/coordinate/liaise with the vendor and set a plan, etc.? Should there be a Project Manager assigned? Or does the Product Manager or Scrum Master own that part?
The Product Owner role as defined by the Scrum Guide says nothing about working with a vendor.
are there any other responsibilities that that PO should own in this situation?
That depends on a number of factors, including:
- The skill set of the Product Owner
- How much time they have available
- Whether they are interested and want to get involved in non-traditional Product Owner activities
- The capabilities of other team members
Or does the product manager or scrum master own that part?
Again, the Scrum Master role as defined in the Scrum Guide says nothing about working with a vendor.
My suggestion would be as follows:
- The Product Owner continues to do their role as defined unless they specifically want to get involved with working with the vendor
- The Scrum Master does their usual role in the team: supporting the Scrum process and helping to facilitate the removal of impediments
- The development team takes responsibility for dealing with the vendor
If the development team does not have the skill set needed to work with the vendor, then it may be worth considering adding a team member with the required capability. I have worked with Scrum Teams that have included somebody with a background in Project Management, and they were often the one that got involved with vendors/clients.
In a POC the Product Owner ought to be the decision maker, the person who will assess the suitability of the product being evaluated and make or recommend the purchase - or someone nominated by the decision maker(s). It's most important that they keep the team's focus on demonstrating the required evidence or learning the lessons that the POC is intended for.
I'd also suggest that Scrum may not be the best choice for a POC unless the expected duration is more than, say, one month. For a shorter piece of work Kanban may be more appropriate. The nature of a POC is that it's about discovery, learning and adapting continuously as you go. Scrum is all about iterative delivery, cadence and works well only if the outcome of each sprint can be defined during sprint planning - difficult to achieve on a short POC I would have thought.
PO seems like the right person to own the relationship with the vendor. Collaboration and adaptability is usually more valuable than planning but that might depend on the nature of the work and the relationship with the vendor. No Project Manager in Scrum because the PO is responsible for setting scope and priorities and the team as a whole is responsible for planning.
A Proof of Concept (POC) cannot be estimated in terms of story points, hours, nor any sizing you use, since it is all about trying to prove if a suggested model works or not. That's why, it cannot be included in a Sprint.
As far as I understand, the need to include it in the Sprints arises due to:
- some of the Developers in the Scrum Team will be working on that POC
- the output of the POC will be epics, stories, and/or tasks for the Scrum Team
You should approach this POC just like how you approach a bug from the production environment; have a Kanban board for these kind of activities and add the POC there. In terms of the workload of the Scrum Team members, you can use the same model you use when a member uses paid time off (vacation).
I would recommend the PO do the communication between the external and internal teams because the POC is mainly done for the PO; the outputs of it will define what needs to be done. While the PO does the communication, they can do the planning to act faster.
First, I would argue there is no such thing as a POC in an agile organization. You merely create an iteration of the product with the vendor's solution. Then if you don't like the results, the next iteration pulls that solution out.
Liaising is easy. The PO and team together only create the user stories for their part of the process--creating specs to give the vendor, assessing the results after the solution is in--and put impediments ("blockers") on the ones they can't do until the vendor delivers something. Any team member can take on the role of answering vendor questions; logic suggests it be the person with the most relevant technical knowledge. Then focus on other stuff until the vendor delivers something, clearing the blockers on the post-delivery stories.
The Manifesto provides some answers in the "Individuals and interactions..." and "Customer collaboration..." lines. There is no need for a "plan," and it doesn't matter which job title does what. For your part, you need only break the data mapping process into small enough stories that you can deliver a portion within a sprint, and if forced to do points, only estimate for that one story. (That said, your company is missing the point of points if it includes time required in the consideration. But then, I stopped using points years ago!)
Finally, it is not the PO's job to assess the solution. Teams are self-managing, which means it is the team's call. The PO is just one equal voice in that discussion.