But the product owner has perhaps the most important and challenging role in a scrum project. Responsible for the project’s overall success, the product owner sits at the center of the constant collaboration, problem-solving and rejuggled priorities that make scrum (when done right) faster than traditional waterfall software development methods.
The product owner must collaborate closely with the team on an ongoing basis, guide it in the right direction, and make critical decisions. He or she is the voice of the customer, and is responsible for the product backlog (the “to-do” list of “user stories” or requirements) that must be satisfied before the software is ready for use. His or her role includes clearly describing the product backlog items, setting and changing their priorities as the project evolves, and ensuring the back log items are clear and understood by all scrum members.
In my experience, the cardinal qualities a good product owner must have are:
- Excellent communication skills to pass information among customers and the scrum team.
- A thorough and in-depth understanding of the customer’s requirement and vision of the product.
- The ability to proactively manage stakeholders such as those who pay for, and will use the application.
- The power to make critical decisions such as reprioritizing work items and
- Enough understanding of the software development cycle to guide their decisions.
Whenever our team struggled on velocity (the pace at which we delivered desired features) it was because product owners either lacked the power to make the decisions at the right time or lacked the true vision of what the customer needed from the application to make the right choice.
For instance, in one project that involved enhancing an existing portal, we were led by a product owner who was relatively new to the role and had only basic Scrum training. During sprint planning poker sessions, we added a complicated user story that required adding 15 fields to an existing page and complicated logic to auto-populate some of the fields. The acceptance criteria for this user story were too basic and did not include an adequate analysis of all the relevant factors (such as which user roles could access or edit these fields, the different data that users might add and all exception scenarios such as error messages). Here, the product owner did not make sure he understood the story and its purpose.
In the early stages of the sprint, these gaps didn’t seem to be a problem, as the development team was new to the portal and very few of these details were discussed during the daily sprint planning meeting. But as the sprint progressed, the developer responsible for that story started raising questions in the daily scrum meetings, which the product owner didn’t attend due to other commitments. My scrum master had to email the product owner an email asking him to join the daily scrum and address the queries, but even then it seemed like he was not sure about the exact criteria and always asked for some time to discuss with the business users.
The product owner had to meet with users and the developer to figure out the missing details, all because he had accepted the story from the users without pushing to understand its purpose and business value. As a result, the developer was unable to deliver anything for the two weeks of work he spent on this story in one sprint, and had to continue work on it in the next and final sprint.
Not only must a product owner be vital and decisive, they must devote enough time for the team. While some people think that the product owner need not be present in daily scrum meetings, I think it really depends on the project environment and criticality of the requirements. In every project, there will be some impediments or queries which can only be cleared by the product owner. At the very least, he or she should be present in all planning, review and retrospective meetings, where the team reviews their work on the last sprint and applies lessons to the next.
As the proverb says, “a good beginning makes a good ending.” Choose a product owner who has the power and knowledge to make tough decisions and get the information the team needs, and you’ll deliver more business value more quickly.
Harshal Sanjay Deole is a software developer with seven years experience in outsourced software development using both waterfall and agile scrum methodology.