There are three fundamental roles in Scrum: Product Owner, ScrumMaster, and Team. This article discusses the Product Owner in how in many cases a Business Analyst is the best person to serve this role.
Product Owner is the most demanding of the Scrum roles. The Product Owner creates a vision of what needs to be built and conveys that vision to the Team. Effectively communicating this vision is key for beginning any agile software development project. In Scrum, the Product Owner is the primary person responsible for ensuring that the solution delivers business value. The Product Owner leads the development effort by conveying his or her vision to the Team, creating requirements (user stories) in the backlog, and prioritizing user stories based on business value. The Product Owner must work closely with stakeholders and the Team to make sure their interests are included in the release. The Product Owner works closely with the Team to negotiate work assignments, resolve issues, and ensure that the agreed upon work is completed by the end of the iteration. The Product Owner must be available to the Team during the sprint to answer questions and deliver direction.
This combination of authority and availability to the Development Team makes it difficult for the Scrum Product Owner not to micro-manage. However, Scrum places significant value on self-organization and, as a result, the Product Owner must respect the Team’s ability to create its own plan of action. This means that a Product Owner is forbidden from assigning the Team more work in the middle of the sprint. Even if requirements change or some business dynamic arises that renders the team’s work worthless, the Product Owner cannot alter the sprint until the next sprint planning meeting.
It is the Product Owner’s responsibility to consider which features will produce the most business value. This means making tough decisions—often putting the Product Owner and Team at odds during sprint planning. However, the Product Owner is the person who will be held accountable if the project crashes and burns. Therefore, he or she must aggressively determine which features of a product are most important and when they are developed. The Team is responsible for delivering the negotiated work to the Product Owner; the Product Owner must deliver the product to the business.
Although the Product Owner prioritizes the product backlog, during the sprint planning meeting the Team selects the amount of work they believe they can do during each sprint and how many sprints will be required. The Product Owner does not get to say, “We have four sprints left, therefore you must do one-fourth of the product backlog in this sprint.” The Product Owner’s job is to motivate the team with a clear, elevating goal. Team members know best what they are capable of and so they select which user stories from the top of the product backlog they can commit to delivering during any sprint.
In return for the Scrum Team’s commitment to completing the selected user stories from the top of the product backlog, the Product Owner makes a reciprocal commitment to not throw new requirements at the Team during the sprint. Requirements are allowed to change (and change is encouraged) but only outside the sprint. Once the Team starts on a sprint, it remains focused on what they committed to do during the sprint.
Now let’s examine why a business analyst may be best to serve this in a role. Some organizations assign a lead user or someone from the business to serve as the Product Owner. This often does not work too well because these people often cannot devote full time to the project. Having a part time Product Owner is a sure recipe for a failed agile project. In addition, these people are generally not trained in defining requirements, working with other stakeholders, and assessing business value, which are core skills for a business analyst.
The primary goal of a Product Owner is to represent the needs and desires of the stakeholder community to the Team, being the first source of information to go to when questions arise about needed functionality. Each Team has a single Product Owner to go to for information and prioritization of their work.
Product Owners must represent the work of the Team to the stakeholder community. A Product Owner operates as an empowered business analyst without the burden of the bureaucracy surrounding big requirements up front. I believe that business analysts have the right skills to best serve as Product Owner. However, there are several aspects about this role that are critical to understand:
Product Owners are empowered and have authority. The Product Owner is the single person responsible for prioritizing requirements and for providing details explaining the requirements to the Team. The main issue for BAs serving in the Product Owner role is authority. Business Analysts have mostly been facilitators and will have to make difficult decisions as Product Owners. Collaboration with other stakeholders is essential and requires time, but when the time runs out, the Product Owner (BA) will need to call the shots. This aspect of the job may be a difficult transition for some business analysts who previously served primarily as facilitators.
Product Owners facilitate Communication between the Team and Stakeholders. There are two critical aspects to this role: first, the Product Owner serves as a stakeholder representative communicating requirements to the development team. Second, the Product Owner serves as a project team representative to the stakeholder community as a whole. Let’s examine each of these roles.
As a stakeholder representative, the Product Owner:
- Is the “go to” person for domain information
- Provides timely information and decisions
- Prioritizes requirements, defects, and other work items for the Team
- Is an active participant in user acceptance testing
- Helps the Team gain access to expert stakeholders when needed
- Facilitates requirements modeling sessions, including requirements envisioning
- Educates Team members in the business domain
- Is the gateway to funding
When representing the agile team to the stakeholder community, the Product Owner:
- Is the public face of the Team to project stakeholders
- Keeps stakeholders informed about the status of the project
- Demonstrates the system to key stakeholders who weren’t able to attend the standard scheduled demo conducted by the Team
- Organizes milestone reviews
- Facilitates requirements modeling sessions
- Educates stakeholders in the development process
- Negotiates priorities, scope, funding, and schedule
Product Owners need good communication skills, including agile modeling skills. They need to know who the stakeholders are, and to interact with them regularly. They will also need to facilitate interaction which the Team.
Often, development teams blame the Product Owner when the delivered functionality is not approved because it does not meet the needs of the stakeholders or customers. However, in reality, the Product Owner can’t possibly know all the details of what is needed for all of the stakeholders, and as a result will need to bring stakeholder experts to share their expertise with the Team at appropriate times.
The Enfocus Requirement Suite™ from Enfocus Solutions provides full support for the Product Owner Role in agile development. The tool provides fully automated support for the Product Owners, allowing and facilitating collaboration between the Product Owner and the Team and the Product Owner and Stakeholders.
[cta id=”7443″]