Product Owner & Team communication
Product Owner responsibilities
The Product Owner has many key responsibilities in a team. I would like to categorize them into the tangible and the intangible. Some that fall into the former category are listed below.
- Maintaining a product backlog
- Prioritizing features on the backlog
- Understanding of the business
They are so essential to the role of the Product Owner that if they aren’t done properly, it is immediately recognizable and corrective measures could be taken.
The second category of Product Owner responsibilities are largely of intangible nature. Communication, clarity, interaction with developers are some that fall into this category.
Developer Crucifixion
Usually, companies that follow Agile principles conduct a demo at the end of the sprint. This is attended by the development team, the scrum master, stakeholders and the Product Owner for the team. The product owner provides comments on the sprint deliveries.
If the delivered product meets the acceptance criterion set by the Product Owner and also meets the checklist for definition of done, the user story is marked as accepted and complete.
If not, the product owner’s comments have to be incorporated and the user story is continued in the next sprint. In most companies, this is automatically seen as a failure on the part of the development team.
To meet the expectations of the Product Owner and the stakeholders is considered as the duty of the developers.
Whether the Product Owner also has to meet the expectations of the developers is rarely considered.
The afore mentioned facts generally causes a divide in software companies between the Product Owner department and the development team. Each one believes that their own work is of far more importance than the other. This more often than not is caused by the lack of understanding about the work done by the other and lack of communication. The above is an unfortunate but common occurrence in most companies.
The issue needs to be fixed. But, in reality, to address this issue is not that simple and straight forward!
There are hundreds of things that could have caused a sprint delivery to fail. In many cases, it could even be an external factor to the team such as the organizational changes, upper management decisions, failure on the part of testers etc. Here are some to consider!
Could Product Owner be the reason for Sprint failure?
An often ignored reason for failure is the role of Product Owner. The Product Owner might be carrying out most of the tangible responsibilities with due diligence, but could be ignoring some of the intangible ones. Companies that fail to recognize this continue to fail even when everyone is working hard at their tasks.
In this post, I want to concentrate on some factors that are hard to recognize but could well be the root cause of failures.
Communication
Is there good communication between the Product Owner and the developers throughout the development life cycle?
When the sprint is progress, the Product Owner would be able to provide early feedback and clarify any doubts for the developers.
In the first few days of the sprint, the general approach of the user story could be discussed. As the sprint goes further, actual work in progress can be seen visually on the computer and may lead to a more detailed discussion.
These early meetings give an opportunity to both the developers and the Product Owner to go with a solution that both agree with. The sprint demo shouldn’t be the first day when the Product Owner is seeing the software delivered.
Requirement Scope Creep
It is important that the Product Owner doesn’t majorly change the original requirements for the user story while the sprint is in progress.
Of-course, it’s not to say that such a situation can’t occur, but if it does, it would mean that the Product Owner had brought in a user story too early into the implementation phase. Such user stories need to be identified and needs to go out of the scope of the current sprint and on to the backlog for further clarification.
On a positive note, if the implementation is headed in the right direction, the Product Owner can give finer and more detailed feedback while the work is in progress. This will result in a better product that everyone is satisfied with at the end of the sprint.
Technical knowledge
Is the Product Owner from a technical background or business? A non-technical Product Owner might be finding it difficult to communicate clearly with the developers. To make matters worse, the developers could be finding it even harder to communicate with the Product Owner.
Although there is no one size fits all solution, it is always handy if the Product Owner understands the software development principles. There are many different views on whether the Product Owner should be technical or not, but based on my observation, it is always easier to work with someone technical.
Moreover, since the Product Owner is working in the software industry, it is hard to imagine that the Product Owner would lack technical know-how.
Frequency of Meeting developers
Now comes the question of how often the Product Owner and the developers meet during the sprint? How much is too much and how little is too little?
The answer of-course depends on the company type – big or small. How busy are the developers, Product Owners etc.
The bare minimum should be at-least twice a sprint in order to have any valuable conversation between the Product Owner and the developers. There is a real problem if the answer is either Never or Only in the demo at the end of the sprint.
My personal experience working in a wide variety on companies and teams of various sizes is that a quick meeting(<15 minutes each) at-least 1-2 times a week is a good frequency for Product Owner and the developers to meet.
Summary
It is important for the Management and Scrum master to identify when the Product Owner is out of sync and cut off from the developers. Such a Product Owner not only fails to realize the product goals but may also demoralize the team. The team are lead to believe that they are incompetent.