fbpx

The Agile Product Owner: How does a product owner bring value to the software development process?

today
timer
agile software development

Agile product development within enterprises grew to 59% in 2017, more than doubling the rate of adoption from two years earlier. Forrester predicts this adoption will continue to grow during 2018 as more developers embrace Agile product development.

Agile software development is a methodology encompassing the key Agile concepts laid out in the Agile Manifesto. More value is placed on individuals and their interactions, collaboration with customers, and response to change, versus processes, tools, and rigid plans.

The Agile product development method introduced a new role to the software development process: the Agile Product Owner (PO). This role can be confusing for those new to the Agile process, as it sounds very similar to the role of a product manager.

The product manager’s role in software development is to oversee the product roadmap, taking a high-level view of the product and where it is going. The product owner’s role is quite different; this person is tasked with guiding the product development process from the standpoint of the customer, or end user, of the product.

What is an Agile product owner?

An Agile PO is a non-technical team member who has just the right amount of technical knowledge to pick up technical concepts quickly, without devaluing the user experience. They are an advocate for the user experience, maintaining clear and constant communication with the development team and business stakeholders.

The PO works comfortably in an Agile work environment, leading team meetings with confidence and ensuring all team members understand the Product Vision.

Five tasks of the Agile product owner

The Agile product owner is responsible for five main tasks during Agile software development:

1.    Drive communication

The PO efficiently communicates with both critical business stakeholders and technical team members. They quickly identify how each team member best communicates so the necessary information can be exchanged and understood. This supports the constant improvement of the end product. The PO also identifies each team member’s knowledge expertise so questions are immediately directed to the right team member. Issues and questions are resolved rapidly and information is promptly shared with business stakeholders.

2.    Guide the product vision

Without a designated PO, the daily responsibilities get placed on different team members, with technical leads, project engineers, and project managers each taking on a portion of the duties. This results in poor communication and unclear requirements, and the product suffers from conflicting ideas and misdirection.

A PO provides a clear product vision based on the customer requirements and a deep  understanding of the stakeholders’ business priorities. Business requirements are captured in formal Acceptance Criteria that can be easily understood by the development team.

The PO makes quick and informed decisions as priorities shift and change during the development process. These priorities are slowly developed in two-week sprints that the PO manages with the help of the team’s technical lead.

3.    Create user stories with acceptance criteria

The PO is responsible for creating User Stories with detailed Acceptance Criteria in a ticketing system. A User Story summarizes the business requirement using a format such as: “As a user, I want the ability to send a text message.” This is a brief description of a requirement that can be quickly identified by the development team.

The Acceptance Criteria included in each User Story is written in Gherkin format, which is comprised of steps that address a “given,” a “when,” and a “then.” This provides development and Quality Assurance (QA) with background information (GIVEN), actions to perform (WHEN), and expected outcomes/results (THEN). It is written from the perspective of a user and describes the scope of the business requirement in explicit detail. In the absence of a PO, developers waste time trying to understand requirements, often creating the wrong requirements or increasing their scope .

4.    Refine the backlog

The PO is responsible for prioritizing and organizing the product backlog. The backlog contains a business’s crucial requirements – short descriptions of all desired functionality. Clear communication with business stakeholders is required to efficiently organize the backlog. Prioritization is based on the PO’s understanding of the stakeholders’ high priority requirements.

The PO must use additional communication methods, such as documentation, visual diagrams, and spreadsheets, to bridge the communication gap between business stakeholders and the development team so priorities are understood. When a software development company does not have a PO, the organization of the backlog is neglected, making it difficult to understand the product’s upcoming development tasks.

5.    Analyze business processes

The PO analyzes current business processes and gradually implements new ones.  During process integration, the PO must know what elements of Agile product development bring the most value to pre-existing business processes. A good PO deeply believes in the benefits of the Agile methodology and its practices – a  belief that comes with time and hands-on experience.

The PO cannot be ignored in Agile product development. It is arguably one of the most important roles in the Agile process, with the PO responsible for smooth communication, change management, and ensuring the product matches the needs and criteria of users and stakeholders. A solid PO has a knowledgeable background in the Agile process, is capable of understanding technical concepts, has strong communication skills, and is adept at managing change. If you do not have an individual with this skill set in-house, you should consider consulting with a proven PO for your next Agile project.