Product Owner: The Voice of The Customer

In recent years, it has become evident that organizations which use Scrum as their preferred project delivery framework consistently deliver higher Return on Investment (ROI).

The Scrum framework is not meant to be prescriptive, which means there is room for flexibility in its application. But facilitating the best application of the Scrum framework involves more than just routine implementation and improvement of processes. Scrum Teams play a critical role in delivering significant value quickly, irrespective of its complexity. Each individual in Scrum holds one of the three core roles that are ultimately responsible for meeting the project objectives. These core roles include –

• Product Owners who want to fully understand and articulate customer requirements. They are also concerned with a customer or stakeholder-related issues involving business justification, quality, change, and risk aspects associated with Scrum projects.
• Scrum Masters who are experts in the Scrum framework and are responsible for the proper application of the Scrum framework in Scrum projects.
• Scrum Team members who want to better understand Scrum processes and the associated tools that may be used to create the project’s product or service.

Together they are referred to as the Scrum Core Team. It is important to note that, of these three roles, no role has authority over the others.

Understanding defined roles and responsibilities is very important for ensuring the successful implementation of Scrum projects. In this article, we’re going to discuss how a Product Owner contributes to the challenges encountered in a project and its success along the way.

Who is a Product Owner?

A Product Owner represents the interests of the stakeholder community to the Scrum Team. He or she is responsible for ensuring clear communication of product or service functionality requirements to the Scrum Team, defining Acceptance Criteria, and ensuring those criteria are met. In other words, the Product Owner is responsible for ensuring that the Scrum Team delivers value. Now, let us take a look at the many roles and responsibilities of a Product Owner.

A Product Owner:

• creates the project’s initial overall requirements and gets the project rolling.
• helps appoint appropriate people to the Scrum Master and Scrum Team roles.
• helps secure the initial and ongoing financial resources for the project.
• determines Product Vision.
• assesses the viability and ensures delivery of the product or service.
• ensures transparency and clarity of Prioritized Product Backlog Items.
• represents a user(s) of the product or service with a thorough understanding of the user community.
• decides minimum marketable release content.
• provides Acceptance Criteria for the User Stories to be developed in a Sprint.
• inspects and approves deliverables.
• focuses on value creation and overall Return on Investment (ROI).

In today’s fast-paced world, a Product Owner must always maintain a dual view. He or she must understand and support the needs and interests of all stakeholders, while also understanding the needs and workings of the Scrum Team. Because the Product Owner must understand the needs and priorities of the stakeholders, including customers and users, this role is commonly referred to as the Voice of the Customer.

Implement Phase of a Scrum Project

A Scrum project often goes through a number of phases. Five phases, composed of nineteen processes, are suggested in A Guide to the Scrum Body of Knowledge (SBOK™). After the Plan and Estimate phase comes to the Implement phase.

This phase includes three processes related to the execution of tasks and activities—creating various deliverables, conducting Daily Standup Meetings, grooming the Product Backlog at regular intervals—to create a project’s product. It is important to note that the processes are not necessarily performed sequentially or separately. At times, it may be more appropriate to combine some processes, depending on the specific requirements of each project.
Create Deliverables
In this process, the Scrum Team works on the tasks in the Sprint Backlog to create Sprint deliverables. A Scrum board is often used to track the work and activities being carried out. At the end of each Sprint, a product increment or deliverable is completed. The deliverable should possess all features and functionality defined in the User Stories included in the Sprint and should have been tested successfully. As the Scrum Team executes the work of creating deliverables according to the User Stories in the Product Backlog, they carry out the mitigating actions that have been defined to address any previously identified risks. The team documents any newly identified risks and mitigating actions taken. The record of project risks is a living document, continuously updated throughout the project by the team.
Conduct Daily Standup
In this process, every day a highly focused, Time-boxed meeting—referred to as the Daily Standup Meeting—is conducted. This is the forum for the Scrum Team to update each other on their progress and any impediments they may be facing. Daily Standup Meetings propagate the idea that each member of the team is important and is a major contributor, which improves individual and team morale. This, along with the concept of self-organizing teams, improves overall motivation, leads to enhanced performance of the team and improves the quality of deliverables produced.
Groom Prioritized Product Backlog
In this process, the Prioritized Product Backlog is continuously updated and maintained. Remember, the Prioritized Product Backlog contains a prioritized list of project requirements written in the form of Epics, which are high-level User Stories, and is based on three primary factors: value, risk or uncertainty, and dependencies. A Prioritized Product Backlog Review Meeting may be held in which any changes or updates to the backlog are discussed and incorporated into the Prioritized Product Backlog, as appropriate. The Prioritized Product Backlog may be updated with new User Stories, new Change Requests, new Identified Risks, updated User Stories or reprioritization of existing User Stories.
Following the three processes of the Implement phase will guide effective execution of the project at hand. Remember that the processes do not need to be performed sequentially or separately. They can be adjusted to complement the specific requirements of each project. Before leaving the Implement phase, however, it is imperative to follow the blueprints of earlier phases to produce quality deliverables.

It is widely known in the software development industry that Agile values “working software” over “extensive documentation.” This leads to the common misconception that Agile does not believe in documentation. It is true that documentation in Agile does not always mean typing code descriptions or lengthy time-consuming information that may come in handy sometime in the future. However, Agile does not condone little or no documentation—Agile encourages the “right” documentation.

Agile encourages “just enough” documentation as is required for the project.  This documentation can be in the form of flip-chart notes or writing on a whiteboard

. Then, one could take pictures of the documentation with a digital device and store it for reference. Agile does not believe in the documentation just because someone feels that each and every detail of the project has to be captured in writing in order to retain knowledge for the future. The aim of Agile is to be better and faster. “Just enough” documentation helps to save time and cost during the project development process.

However, for projects that demand descriptive documentation, such as projects related to armed forces and defense, Agile practitioners are required to document necessary data and information. When documentation adds value to the customer, it is accepted and worked on using the Agile methodology.

Another misconception surrounding the Agile method is that this approach involves no planning. On the contrary, Agile involves planning as much as any traditional approach does. However, its take on planning is different from other methodologies; Agile focuses on getting started with familiar architecture and requirements rather than spending crucial time on setting up a long-term plan. The Agile manifesto emphasizes “responding to change” over “following a plan.” Owing to this value, an Agile team can adjust and accommodate changes in the project plan much better than other traditional teams. Along with planning, Agile also accepts its limitations in a blustery situation.

Agile planning is not a rigid structure but a progressive one. Laying out a strict plan before the initiation of a project may look organized, but is most likely to become a hindrance in the long run because plans tend to change as the team begins to learn from feedback and iterations. Agile planning is based on the project features and is systematically organized into iterations with a time frame of one to two weeks. Agile believes in implementing a short plan efficiently rather than wasting efforts on preparing an elaborate plan that may not be successful in the end.