The Agile Process — Meet the Product Owner
While many product managers engage with the agile development process as product owners (PO), there is no definitive need in an agile process why a PO should be a product manager. Several sites differentiate the roles of product managers from that of product owners. I find that of academic interest. Let’s understand some practical product owner challenges in an agile process. I will focus on the scrum process, the most common agile practice followed in the industry.
The Product Owner’s responsibility
A Product owner is a scrum role and has no direct link to a product manager organization function. These are the responsibilities of a product owner role:
- Defines and maintains the requirement (story) backlog
- Prioritizes the requirements
- Defines the criteria for completion of a requirement
- Understands the release timelines from the team
How about the coordination with other teams or resolving team dynamics etc. In some organizations, the management entrusts that activity to product managers. That is wrong as a product owner is not part of a team. He is not a committed resource for day-to-day scrum activities. The scrum master who is part of the team addresses such needs.
In short, product owners want to understand two things:
- Is the team having the same level of understanding of the requirements as they have?
- Will the team deliver the project by the committed timeline?
Ensuring The Requirement is Understood
POs have to ensure the team understands the stories well enough. Sometimes, even this may not work due to various factors. Here are some of the steps the PO can take to address.
- Review the test plan
- If a test plan does not exist — look at the test cases created for the individual stories.
- Even that may not be meticulously followed — create test assertions
Test Assertions
The test cases are elaborate step-by-step conditions that are detailed. The team believes there are some unknowns, so they do not have enough information to create them. POs cannot be sure about the acceptance test cases for the same reason. A test assertion comes in handy in such cases. If there is a desired behaviour in completing a story, a PO can mention he expects this desired behaviour exists at the end of the story completion. He can demand that condition be shown in the story demo, ensuring the story meets the completion criteria. Let’s take an example of a travel portal; we have onward journey date and return journey date.
The return journey follows the onward journey.
That is a test assertion. Whatever may be your user interface, as long as the story asserts the above conditions, I have an acceptable completion of the story.
A technical PO may be enchanted with story breakdown to understand the team’s understanding of the stories. But, I will suggest a PO should refrain from getting into the sprint tasks.
Adherence to Delivery Timelines
For a PO, this becomes the most challenging work. One of the reasons being it is a lot outside of the PO’s control. I will suggest a PO understand the estimation principles to ensure this.
The Ideal Scrum Process
In the ideal scrum process, all the stories for a complete release are in the backlog. The team estimates them using story points. Some scrum teams prefer t-shirt sizing estimates of Small, Medium, Large, XL, XXL, etc. I like the Fibonacci story point estimate (1, 2, 3, 5, 8, 13, 20, 100, ?); there is an approximation of a story being roughly twice the size of the previous number. You sum the story points over several sprints and take the average story points completed to determine the team velocity. The PO can use the team velocity to estimate the number of sprints needed to complete the stories.
What if there is no story point?
There are stories broken into tasks; tasks are updated with the proper completion hours — one can get a rough estimate of the team’s ability to deliver the backlog over time; again unreliable and not recommended by any scrum process. The general understanding leads to not mixing hourly completion criteria to the story point.
The classic estimation technique
What if your teams do not update the task hours meticulously. While one can complain, the scrum team is not taking their scrum tasks seriously; as a PO, it is crucial to raise this concern to the engineering management. The PO can utilize the team’s grown experience to estimate the project. A project estimate at the beginning has a 50% chance to be completed on time. There is a 90% chance that the project will consume twice the estimated time. However, a mid-project estimation has a 70% likelihood of completion on time. Keeping these past experiences in mind, a PO can take the team’s feedback on how much time is needed to complete the backlog at the end of every sprint.
Conclusion
The PO role in the scrum is challenging. More so as there is responsibility without authority. To address these effectively, they need to use the best tools to engage with the teams at the right level. The organizations should understand these challenges and involve the right level of engineering supervision over the scrum masters. Transfering SM’s activities to a PO will eventually lead to the breakdown of the scrum process.
Want to assess the scrum process of your organization with experienced product owners? Contact me at: sambit@lenatics.in.
