Scrum : Responsibilities of a Product Owner in a Scrum Project

Understanding defined roles and responsibilities is very important for ensuring the successful implementation of Scrum projects. Scrum roles fall into two broad categories, namely, core roles and non-core roles. There are three core roles in Scrum that are ultimately responsible for meeting the project objectives. The core roles are the Product Owner, Scrum Master, and Scrum Team. 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. Now, let us look at the Product Owner role in detail.

The Product Owner represents the interests of the stakeholder community to the Scrum Team and is the person responsible for maximizing business value for the project. He or she is responsible for articulating customer requirements and maintaining business justification for the project. The Product Owner, thus, ensures 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. The Product Owner must always maintain a dual view.

The Product Owner 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. Corresponding to a Product Owner role in a project, there could be a Program Product Owner for a program or a Portfolio Product Owner for a portfolio.

Before we check out some of the key responsibilities of a Product Owner, here is a video on the Product Owner role: http://www.scrumstudy.com/watch.asp?vid=455. 

The key responsibilities of a Product Owner in relation to a Scrum Project are:

•                    Defines the Project Vision and helps create the Project Charter and Project Budget

•                    Helps finalize Scrum Master for the project and identifies Stakeholder(s)

•                    Helps determine Scrum Team members and helps develop a Collaboration Plan

•                    Helps develop the Team Building Plan with Scrum Master(s)

•                    Creates Epic(s) and Personas and prioritizes Prioritized Product Backlog Items

•                    Defines Done Criteria and creates Release Planning Schedule

•                    Helps determine Length of Sprint along with helping creation of User Stories

•                    Defines Acceptance Criteria for every User Story and approves the created User Stories

•                    Facilitates Scrum Team and commit User Stories

•                    Explains User Stories to the Scrum Team while creating the Task List

•                    Provides guidance and clarification to the Scrum Team in estimating effort for tasks

•                    Clarifies requirements to the Scrum Team while creating the Sprint Backlog

•                    Clarifies business requirements to the Scrum Team

•                    Grooms the Prioritized Product Backlog and accepts/rejects Deliverables

•                    Provides necessary feedback to Scrum Master and Scrum Teams

•                    Updates Release Plan and Prioritized Product Backlog

•                    Helps deploy Product Releases and coordinates this with the customer

•                    Participates in Retrospective Sprint Meetings

SCRUM : Definition of Quality in Scrum

There are numerous ways to define quality. In Scrum, quality is defined as the ability of the completed product or deliverables to meet the Acceptance Criteria and achieve the business value expected by the customer. To ensure that a project meets quality requirements, Scrum adopts an approach of continuous improvement whereby the team learns from experience and stakeholder engagement to constantly keep the Prioritized Product Backlog updated with any changes in requirements.

The Prioritized Product Backlog is simply never complete until the closure or termination of the project. Any changes to the requirements reflect changes in the internal and external business environment and allow the team to continually work and adapt to achieve those requirements. Since Scrum requires work to be completed in increments during Sprints, this means that errors or defects get noticed earlier through repetitive quality testing, rather than when the final product or service is near completion. Moreover, important quality-related tasks (e.g., development, testing, and documentation) are completed as part of the same Sprint by the same team—this ensures that quality is inherent in any Done deliverable created as part of a Sprint.

Thus, continuous improvement with repetitive testing optimizes the probability of achieving the expected quality levels in a Scrum project. Constant discussions between the Scrum Core Team and stakeholders (including customers and users) with actual increments of the product being delivered at the end of every Sprint, ensures that the gap between customer expectations from the project and actual deliverables produced is constantly reduced.

Here is a video on how Scrum defines quality: http://www.scrumstudy.com/watch.asp?vid=524

Now, let us look at how quality is linked with scope, business value and other aspects or elements of a project. The scope of a project is the total sum of all the product increments and the work required for developing the final product. Quality is the ability of the deliverables to meet the quality requirements for the product and satisfy customer needs. In Scrum, the scope and quality of the project are captured in the Prioritized Product Backlog, and the scope for each Sprint is determined by refining the large Prioritized Product Backlog Items (PBIs) into a set of small but detailed User Stories that can be planned, developed, and verified within a Sprint.

Quality and business value are closely linked. Therefore, it is critical to understand the quality and scope of a project in order to correctly map the outcomes and benefits the project and its product must achieve in order to deliver business value. To determine the business value of a product, it is important to understand the business need that drives the requirements of the product. Thus, business need determines the product required, and the product, in turn provides the expected business value.

Quality is a complex variable. An increase in scope without increasing time or resources tends to reduce quality. Similarly, a reduction in time or resources without decreasing scope also generally results in a decrease in quality. Scrum believes in maintaining a ʺsustainable paceʺ of work, which helps improve quality over a period of time.

Scrum : Tools and Techniques for Estimating Tasks in a Scrum Project

The Scrum Core Team uses various tools and techniques such as Task Estimation Meetings, Estimation Criteria, Planning Poker, Fist of Five, etc. to estimate the effort required to accomplish each task in the Task List. When estimating tasks, the core team create the Effort Estimated Task List which is a list of tasks associated with the Committed User Stories included in the ensuing Sprint. Now, let us analyze some of the important tools used by the Scrum Core Team to estimate tasks. Here is an introductory video on estimating tasks: http://www.scrumstudy.com/watch.asp?vid=614

The first tool or technique is the Task Estimation Meeting. This meeting enables the Scrum Team to estimate the effort required to complete a task or set of tasks and to estimate the people effort and other resources required to carry out the tasks within a given Sprint. In Task Estimation Meetings, the Scrum Team members use the Task List to estimate the duration and effort for the User Stories to be completed in the Sprint.

One of the key benefits of this technique is that it enables the team to have a shared perspective of the User Stories and requirements so that they can reliably estimate the effort required. The information developed in the Task Estimation Meetings is included in the Effort Estimated Task List and it is used to determine the velocity for the Sprint. In this workshop, the Scrum Team may use various techniques such as decomposition, expert judgment, analogous estimation, and parametric estimation. Task Estimation Meetings are sometimes also referred to as "Sprint Planning Meetings" - such meetings may also be combined with Task Planning Meetings.

Next is Estimation Criteria. The primary objective of using Estimation Criteria is to maintain relative estimation sizes and minimize the need for re-estimation. Estimation Criteria can be expressed in numerous ways, with two common examples being story points and ideal time. For example, an ideal time normally describes the number of hours a Scrum Team member works exclusively on developing the project’s deliverables, without including any time spent on other activities or work that is outside the project. Estimation Criteria make it easier for the Scrum Team to estimate effort and enable them to evaluate and address inefficiencies when necessary.

Planning Poker is another technique that can be used to estimate tasks. Planning Poker, also called Estimation Poker, is an estimation technique which uses consensus to estimate relative sizes of User Stories or the effort required to create them. In Planning Poker, each team member is assigned a deck of cards. Each card is numbered in a sequence and the numbers represent complexity of the problem, in terms of time or effort, as estimated by the team member. The Product Owner chooses a User Story from the Prioritized Product Backlog and presents it to the team. The Scrum Team members assess the User Story and try to understand it better before providing their estimate for developing it. Then, each member picks a card from the deck that represents their estimate for the User Story. If the majority or all team members select the same card then the estimate indicated by that card will be the estimate for that User Story. If there is no consensus, then the team members discuss reasons for selecting different cards or estimates. After this discussion they pick cards again. This sequence continues until all the assumptions are understood, misunderstandings are resolved, and consensus or agreement is reached. Planning Poker advocates greater interaction and enhanced communication among the participants. It facilitates independent thinking by participants, thus avoiding the phenomenon of group think.

Another technique that can be used in this regard is Fist of Five. Fist of Five is a simple and fast mechanism to achieve consensus in a group and drive discussion. After initial discussion on a given proposal or a pending decision, the Scrum Team members are each asked to vote on a scale of 1 to 5 using their fingers. The value in using this technique is not only consensus building but also driving discussion because each team member is asked to explain the reason for their ranking. They are also given the opportunity to express any issues or concerns. Once the team has discussed it, a collective decision will be made. The number of fingers used to vote indicates the level of agreement and desire for discussion:

1.       One finger: I disagree with the group's conclusion and have major concerns.

2.       Two fingers: I disagree with the group's conclusion and would like to discuss some minor issues.

3.       Three fingers: I am not sure and would like to go with the group's consensus conclusion.

4.       Four fingers: I agree with the group's conclusion and would like to discuss some minor issues.

Five fingers: I wholeheartedly agree with the group's conclusion.

Scrum : Conflict Management Techniques Relevant to Scrum

Organizations applying the Scrum framework encourage an open environment and dialogue among employees. Conflicts among Scrum Team members are generally resolved independently, with little or no involvement from management or others outside the Scrum Team.

Conflict can be healthy when it promotes team discussions and encourages debates, as this usually results in benefits for the project and the respective team members. It is therefore important that the resolution of conflicts be encouraged, promoting an open environment where team members feel welcome to express their opinions and concerns with each other and about the project, and ultimately agree on what is to be delivered and how the work in each Sprint will be performed.

Conflict management techniques are used by team members to manage any conflicts that arise during a Scrum project. Sources of conflict evolve primarily due to schedules, priorities, resources, reporting hierarchy, technical issues, procedures, personality, and costs. Usually there are four approaches to managing conflict in an organization applying Scrum processes:

·         Win-Win

·         Lose-Win

·         Lose-Lose

·         Win-Lose

Win-Win technique is usually best for team members to face problems directly with a cooperative attitude and an open dialogue to work through any disagreements to reach consensus. Organizations implementing Scrum should promote an environment where employees feel comfortable to openly discuss and confront problems or issues and work through them to reach Win-Win outcomes.

Next is Lose-Win. Some team members may at times feel that their contributions are not being recognized or valued by others, or that they are not being treated equally. This may lead them to withdraw from contributing effectively to the project and agree to whatever they are being told to do, even if they are in disagreement. This approach is called Lose-Win. This situation may happen if there are members in the team (including managers) who use an authoritative or directive style of issuing orders and/or do not treat all team members equally. This approach is not a desired conflict management technique for Scrum projects, since active contribution of every member of the team is mandatory for successful completion of each Sprint. The Scrum Master should encourage the involvement of any team members who appear to be withdrawing from conflict situations. For example, it is important for all team members to speak and contribute at each Daily Standup Meeting so that any issues or impediments can be made known and managed effectively.

The next technique is Lose-Lose. In conflict situations, team members may attempt to bargain or search for solutions that bring only a partial degree or temporary measure of satisfaction to the parties in a dispute. This situation could happen in Scrum Teams where team members try to negotiate for suboptimal solutions to a problem. This approach typically involves some “give and take” to satisfy every team member—instead of trying to solve the actual problem. This generally results in an overall Lose-Lose outcome for the individuals involved and consequently the project. The Scrum Team should be careful to ensure that team members do not get into a Lose-Lose mentality. Scrum Daily Standup and other Scrum meetings are conducted to ensure that actual problems get solved through mutual discussions.

Finally, the Win-Lose technique. At times, a Scrum Master or another influential team member may believe he or she is a de facto leader or manager and try to exert their viewpoint at the expense of the viewpoints of others. This conflict management technique is often characterized by competitiveness and typically results in a Win-Lose outcome. This approach is not recommended when working on Scrum projects, because Scrum Teams are by nature self-organized and empowered, with no one person having true authority over another team member. Although the Scrum Team may include persons with different levels of experience and expertise, every member is treated equally and no person has the authority to be the primary decision maker.