The product owner (PO) role requires multi discipline skills, for examlpe:
– Be responsible on deciding the right features at the right time
– Manage myriad of potential sources of requirements
– Product road map development
– Release planning
– Establish ROI from various features
The previous list represents product centric aspects of the PO role. In this post I intend to talk on the PO responsibility on the hand-offs to maintain the flow.
Hand-offs from one stage to another is important to maintain flow of value and to avoid wastes. In Kanban, each stage pulls an item from its predecessor stage once it has available capacity. A typical work flow can have the following stages.
Let us talk about the hand-offs as highlighted by the circular arrows.
From user community to prioritized features list
This defines the heart of traditional business analyst role of translating user needs into business requirements.
Features List to Analysis by engineers
In this hand-off the PO explains and presents the requirements and responds to various questions from engineers. The output from analysis is prioritized software features which are engineering ready. This output is a direct input to release planning.
From Engineering ready to Dev&Test
In this stage the PO answers developers’ questions and provides feedback on whatever software they produce.
From Dev&Test to Review Demo
Here the PO provides feedback on the software increment. This feedback should be incorporated into the increment. This hand-off facilitates the flow to ship the increment to the client.
From Demo to Client acceptance
This hand-off represents a leadership aspect of the PO role as he assumes responsibility on securing client acceptance.
The hand-offs as explained above are key to enable end-to-end flow of value from client to client passing through the various groups from variety of skills. Flow related issues are generally related to non-quality hand-offs, for example:
– Developers are not able to proceed because PO is not responding. Therefore, there is waste because they are waiting.
– Developers do not know which feature to pull next, again, there is waste because they are waiting.
– Requirements are unclear as PO did not provide acceptance test cases. This can create defects which are another form of waste.
– PO detaches himself from taking responsibility on client acceptance leaving it to the developers with draining of man-hours to amend the product. This by itself combines multiple forms of waste.
Kanban board visualizes the flow and team members collaborate for pulling work to their stages. In order for the pulling activities to be effective, we should understand the hand-offs inherent in the flow of value. The product owner is the key player for facilitating the hand-offs to allow productive collaboration among team members. This better collaboration can result a pull system which drives value to stakeholders and the organization.