The Core Role And Responsibilities Of A Product Owner In Scrum

The primary role of the product owner in scrum is to actually “own” the product and function as a “decision maker” on behalf of the stakeholders and project owners. The PO is employed by the stakeholders to represent their interests while implementing scrum framework in their projects. Contrary to what most people new to scrum believe, a product owner can ‘own” a product, but is not necessarily its “owner,” in most cases.

The core job of the product owner, or rather the main responsibilities, are:

• Plan the product release and work out how to “make” the product through consistent product increment
• Ensure that the sprints are successfully completed during the project
• Shippable and “bug free” products are delivered at the end of sprints
• Ensure that the project is successfully completed

The product owner’s job is a difficult one, and a full-time one.   

 

The product owner as the core determinant of a successfully completed scrum project

It is essential to deliver the product value at all times. The scrum “mechanism” requires efficient, reliable, and accurate methods, which can help to support the product vision as envisioned by the stakeholders, and create an effective pipeline having the capability to distil the product vision into shippable, concrete, and deliverable user stories that can successfully demonstrate the tangible benefits of the product. It is the primary reason why the role of a product owner is a very important one while implementing scrum.

While the product owner participates in most scrum rituals, his or her main function, parallel to that of the scrum master, is to act as a facilitator for the entire team, and be available to the team when problems and issues arise. 

The main tasks of a product owner are:

• Envisioning the product and facilitating its development
• Creating an iterative or sprint release strategy which can incorporate the changing market conditions and product requirements
• Distilling the high-level product related requirements into developable and deliverable user stories linked with acceptance criteria
• Prioritizing the product backlog
• Communicating difficult and complex system architecture issues to the clients
• Negotiating all client-sided disputes and concerns associated with the product design, development, and user story priorities

 

Responsibilities of a product owner

The PO is mainly responsible for:

• Representing the interests of, and acting as the voice of stakeholders and customers
• Understanding project profitability and delivering high ROI
• Managing and communicating with the stakeholders
• Promoting collaboration amongst the team members
• Undertaking on-the-spot tactical decisions and ensuring that the product development cycle is not affected
• Participating in the release meetings and planning
• Writing effective user stories
• Maintaining and updating the product backlog
• Helping the team in estimating the development time for each scrum scenario
• Participating in the sprint review meetings, accepting the user stories as “Done”, and providing effectual feedback
• Monitoring the project progress and suggesting constant adjustments based upon important strategic objectives

Find out more, and subscribe to the permanently free "limited users" QuickScrum tool which can help you in implementing scrum framework in your projects!

The Main Reasons Why Work Is Not “Done” In Scrum, And Why The Acceptance Criteria Is Not Met

Perhaps the most important aspect of scrum methodology is the concept of “Done” or meeting the acceptance criteria while developing the tasks. The product owner, who represents the interests of the stakeholders, approves and certifies the acceptance criteria defined in individual user stories, or the product backlog items. It is very much important for the user stories to be accepted as “Done” because in scrum an item can only be considered as “shippable” and “complete” when its “Done” criteria is met. The terminology used to describe “Done” is synonymous with the acceptance criteria in scrum methodology. The words describe the same thing.
 

There are times when the acceptance criterion is not met, and the user stories are not considered as complete. This can be the worst possible scenario as far as conducting the daily sprint is concerned, since the basic objective of the sprint cycle is to meet the acceptance criteria and deliver a shippable product at the end of the iteration. Unaccepted and unfinished user stories reflect unsuccessful sprints and improper implementation of scrum.
 

It is worth knowing about some scenarios, which can result in a condition when the “Done” criterion is not fulfilled in scrum. 
 

Lack of a good cross -functional team 

By “cross functional” we mean a team, or a group of individuals having different areas of specializations, who work in unison to achieve a common objective or a cause. In scrum, if the product is technically complex, or if the functionality associated with the product is varied and extensive, it is essential to have a cross functional team. When individuals with different areas of specializations work together to develop a solution, it becomes very easy to carry out the development activity, since the technical requirements are catered to by developers who have required levels of expertise and can provide clear and concise solutions for a given task or a problem. Queries are resolved in a more successful manner, and in the least amount of time.
 

During the sprint, when or if a team member faces a particular problem, it is possible for other cross-functional team members to contribute their knowledge and skills, and provide a proper solution for the problem in hand. This makes the development work easy, fast, precise, and effective. It is very important, and recommended, for scrum teams to be cross-functional. 
 

Non cross-functional team members may find it exceedingly difficult to find quick solutions when problems arise during the sprint activity. The primary reason why this happens is because they lack the required experience, or do not possess sufficient skill sets to offer effective solutions, which can solve the problem currently impeding further product development. The levels of expertise typically required may include designing, business analysis, development, database designing, testing, and other similar skills. It is essential for the developer to be proficient and very good in his or her work. Failing to have such technically sound team members in the sprint may result in substandard or defective developmental activity. Tasks which are not technically perfect, or which have bugs in them may not be accepted as “Done”. 
 

Unclear or undefined acceptance criteria in the user stories and tasks 

It becomes very hard and almost impossible for the development team to successfully complete the tasks included in the sprint backlog if the meaning of “Done” is not properly explained in the user story, of if the story simply fails to include the acceptance criteria required for its development. Typically, in such cases the team starts working blindly, and often pursues a vision of what the actual “Done” should ideally include in the user story. Rather than the product owner explaining the meaning of “Done”, the team assumes what the “Done” criteria is and starts developing the task based upon their assumptions.
 

This can prove to be a dangerous habit as far as the project is concerned since the entire team starts pursuing unclear and even undefined objectives which have no relevance whatsoever as far as the project is concerned. The result is a lot of “wastage” suffered by the stakeholders and the management in terms of unproductive working hours and human resources.
 

Using outdated or obsolete technologies for development purposes 

Technology keeps on changing continuously. For the team members, it is essential that they remain in touch with the latest development techniques and trends. As it quite the norm, existing technology tends to “phase out” over time, and is replaced by emergent technologies, which are more powerful, dynamic, and effective.
 

Using older technologies may lead to incomplete development, simply because phased out technologies do not have the potential to offer the functionality needed to develop a competitive product. Moreover, the team may find it very hard, or impossible, to meet the acceptance criteria, and not be able to develop the task. At times, the definition of “Done” may not be satisfied by using out dated technologies. Using old engineering practices can lead to undue wastage of development time, and even lead to the development of sub standard products. It is very important to use upcoming and newly emerging technologies to deliver quality products.
 

An overworked development team 

The stakeholders and the management are mainly concerned with marketing the product once its development is completed. Their objective is to launch the product as soon as possible, and benefit from the amount they have invested in the project. They often compel the scrum team to take up more work, or even complete the project well before the decided completion date.
 

This can make the development team to cut corners while completing their sprint tasks. Since the team is forced to work against time, it is going to affect the development and quality of the finished tasks. As enough time is not available to check and verify the acceptance criteria, the team may simply decide to carry out the development and submit their tasks in the sprint review meeting without verifying the acceptance or “Done” criteria. The team fails to perform properly because it is compelled to “deliver more” and it simply lacks the time to check the acceptance criterion.
 

Lack of collaboration and integration activity 

The main essence of scrum is collaboration. Team members should work in a joint manner to achieve common objectives. Scrum methodology also advocates team members to co-operate and help each other when problems arise and solutions are required. Moreover, collaboration is essential when the team is undertaking the sprint. Collaborated efforts lead to a well-organized team and improved productivity.
 

When the team members start working individually and stop collaborating, it leads to a situation where in the tasks are not properly linked up, or integrated in a proper manner, to be effective. Generally, during the sprint, the segregated user stories are developed in the form of tasks, and the tasks have to later integrated to fulfill the acceptance criteria. If the team members are working individually, the tasks cannot be integrated or linked up as specified in the acceptance criteria. The definition of “Done” is therefore not fulfilled.
 

Unfocused sprint planning meetings and product owners uncertain in their thoughts 

Scrum is very clear about what needs to be done, in what manner, and when. There is a clear-cut indication about the project flow and the development cycle as to how they are supposed to function, and what they are set to deliver. During the sprint planning meeting, the product owner transfers a set of user stories or product backlog items into the sprint backlog from the product backlog for development purposes. Once the first half of the meeting is over, the team members segregate the user stories into individual tasks during the second half of the sprint meeting, and distribute the tasks amongst themselves. Subsequently, the sprint is carried out to develop shippable items. This is the normal process flow, and scrum can be successfully implemented if this flow is followed in a preplanned manner.
 

If the product owner starts developing second thought regarding the user stories included in the sprint backlog for development purposes, it can lead to a lot of confusion and disarray, especially if the sprint backlog items are “changed“, or some of the items in the backlog are transferred back to the product backlog and replaced by new ones. The team loses it focus since some of the tasks which have already been completed before cannot be linked up with other ones because other tasks have not been developed yet. The team may have to re-plan the development schedule and may not be so clear about the acceptance criteria associated with the new items included in the backlog. The programmers may fail to fulfill the “Done” criteria because they have not been able to plan for it in an organized manner before the inception of the sprint.
 

Lack of proper planning and mutual disagreement regarding “Done”
One of the perquisites in scrum is to have proper planning amongst the team members. Each individual has a specific role to play while scrum is being implemented in the project. In scrum, everything depends upon planning and group efforts. The sprint planning meeting, sprint review meeting, the sprint retrospective meeting, and the product backlog refinement activity are also carried out as per plans. If scrum activities are not properly planned, it can lead to a disarray of related events, and the development activity may suffer as a result thereof.
 

If the product owner and the team fail to reach to a proper agreement regarding the acceptance criteria mentioned in the user stories, the upcoming sprint may be seriously affected in terms of submitting the deliverables. Since there is no mutual acceptance of the definition of “Done” within the scrum team, the development team may not have a clear objective as to how, and in what manner, the tasks should be developed during the sprint. In fact, the team may not have an objective in the first place when it undertakes the sprint since the meaning of “Done” is not defined mutually or accepted by all involved.
 

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

Sprint Review Meeting Pitfalls – What Should Be Avoided To Get The Most Out Of Scrum Implementation

The sprint review meeting is held at the end of each sprint. It is very difficult to avail the benefits out of scrum implementation if the review meetings fail to remain effective. It is important to know about certain pitfalls, which can render a review useless and meaningless.
 

Use the review meetings for show casing purposes
Generally, during a sprint review meeting, as per the norm the team members demonstrate the development carried out during the sprint, which has just completed. The tasks and functionalities developed are exhibited to the product owner in the meeting. The PO verifies the tasks developed as to whether they comply with the acceptance criteria and if they are “shippable”. The team is apprised whether the task is accepted as “Done”, or is still incomplete since it does not meet the acceptance criteria as defined in the user story. In many ways, the sprint review is often utilized as a “Show and Tell” meeting, and there is nothing wrong with this. However, if the meeting ends with this activity, it is wrong because the main purpose of the review is not satisfied.
 

The objective of the review is not to focus only upon the items which have been developed during the sprint, and which of them have been accepted as done. It is important to update the product backlog with the items, which have been accepted as done, and transfer those items which have not been developed during the sprint, or which have failed to fulfill the acceptance criteria, to be moved back to the product backlog. It is imperative that the entire review should be conducted in whole, and the product backlog updated appropriately at the end of the meeting.
 

Management and stakeholders “take over” the meeting 

Even though it is not mandatory for the stakeholders and the management to attend the meeting, they can do so if they desire. Scrum supports transparency, and since the stakeholders have invested money into the project, they have a right to know about how the project is proceeding. The review provides an opportunity to find how much development has taken place during the sprint, and how the team is performing. Ideally, the stakeholders should participate as guests and keep a low profile while the meeting is in progress. They should refrain from making comments or participating in an overt manner by asking questions directly to the team members. Moreover, at times the stakeholders tend to focus upon individual team members and keep a track of what they are doing, and how they are performing. This is in antithesis of what scrum advocates. Scrum encourages and promotes team efforts. It is what the team delivers as a whole, which is more important than individual efforts.
 

The product owner should limit the participation of the stakeholders in the meeting so the guests do not overcrowd the meeting place, and the team members have enough room to conduct the meeting. The comfort levels of the team should not be compromised upon. The product owner should also warn the guest to participate in the meeting as passive participants, and not carry out any activity which can disturb the proceedings in any way or manner. Reviews can become meaningless if the management or the stakeholders dominate them.
 

Skipping the sprint review meetings 

There is a general tendency amongst the team members to skip the review meeting if they have failed to complete all the user stories taken up in the sprint backlog, or if they consistently fail to get the user stories accepted as “done” by the product owner. The team believes there is no point in attending the meeting since the user stories are not being accepted.
 

It is important to understand that the purpose of the review is not just to accept or reject the user stories. The main objective is to “review” the performance of the team members and carry out self-correction activity after identifying potential pitfalls. Scrum promotes self-learning, and it is imperative that the team members actively participate in the process and learn lessons from prior sprints so they can auto correct their mistakes. Skipping the reviews can halt the self-correction process, and render the review ineffective.
 

Team members remain absent 

It is very important for the product owner to remain present during the review meeting. In fact, the entire review revolves around the product owner, since the basic purpose of the meeting is to get the user stories accepted or rejected by him or her. Therefore, if the product owner remains absent, and does not attend the meeting, the objective of holding the meeting is defeated.
 

The team members should also remain present in the meeting along with the scrum master. The review offers an opportunity for the team to exhibit its work, and generally each member demonstrates the development carried out. The team members take turns to display their work. As per the norm, each member is supposed to demonstrate his or her development. The review also offers an opportunity to avail the feedback from the product owner regarding the acceptance criteria, and know more about the future user stories to be developed by the team. If the team members remain absent during the meeting, they miss the chance of getting informed about how the future user stories ought to be developed.
 

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

The Responsibilities Of A Product Owner

As far as scrum methodology is concerned, the product owner plays a very important part in creating new products, and enhancing the value of existing ones for an organization. Many businesses struggle to implement the role in an effective manner, but often fail to do so. There are several reasons why this happens. One of the commonest causes is that the organization fails to properly understand the exact role played by the product owner, or may be unsure as to what kind of role is best suited for their project related requirements. The product owner “owns” the product on behalf of the investors and the stakeholders. The person is responsible for the success of the project, and is answerable to the management for the project.
 

A multifaceted role
The role of a product owner varies in real life depending upon several factors such as the market conditions, product life cycle, and management related concerns. The aims and objectives of a project depend upon the type and nature of the product to be developed, and how the owners desire to manufacture and market the product. The product owner has to oversee the completion of the project, whatever the project related requirements might be. There are times when the person has to think as an owner and ensure the project is being properly executed, so it benefits the management. The person may be required to act as a facilitator and coordinate the working of the team. It may be required to think like an entrepreneur while suggesting project related ROI solutions to the stakeholders. The role is not an easy one, and the product owner required to be a bit of everything – a team leader, entrepreneur, project manager, facilitator, and a product owner! 
 

Responsibilities of the product owner
A product owner should take up certain responsibilities:

People

• Understand the needs of customers and end users
• Collaborate with the development team
• Successfully manage the stakeholders

Strategy

• Create an effective business model
• Working out proper strategies for conducting sprint planning meetings, sprint review meetings, and sprint retrospective meetings 
• Develop the product definition and road map
• Define and explain the user experience and the product features

Learning and delivery

• Set up the sprint goal, detail the user stories, and decide what to do next
• Collect relevant data and analyze it for goal validation
• Update the business model and product features as per need
• Monitor and track the project progress (time and budget)
• Coordinate with the stakeholders for the product launch

Scrum

• Have the correct vision about how and where to take the product
• Prioritize the product backlog as per business value associated with user stories  
• Advise and offer help to the scrum master when asked for or required
• Analyze and understand the business model including the value proposition as well as the business benefits desired from the product development
• Ensure effectual sprint goals are set up and followed
• Choose the correct research and/or validation technique to exhibit the product increment

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

Sprint Review Meetings In Scrum – Objectives, Who Participates, And Why

The main purpose of a sprint review meeting is to:

• Exhibit the development carried out by the team
• Get a proper feedback about the work completed until date
• Collaborate for a smoother functioning of the project

The reviews form a part of the inspecting and adapting process, which is one of the major advantages of scrum. Scrum methodology advocates self-learning. The scrum process supports several processes which help the team members to undertake self-correction activities, and adjudge where the project is heading. The sprint review meeting is conducted after a particular sprint is completed.
 

Sprint review meeting
Sprint reviews are informal in nature, and primarily held to display the work, in the form of user stories and development tasks, carried out by the team members during the sprint activity. The completed work is demonstrated to the stakeholders. The individuals who have invested funds into the project need to know about the status of the project and how much work has been done, so they can make proper plans to market the product. The review aims to update the stakeholders so they can get an idea regarding the quality and the quantity of development carried out in the project. It aids in increasing the user participation. The stakeholders can accept the work, or reject it in case they are not satisfied with it. They can also reject the work if the user stories fail to adhere to the acceptance criterions specified when the product items are created in the product backlog. 

The product owner represents the stakeholders’ interests. He or she remains present during the meeting and decides about the work. The stakeholders can attend the review meeting, but they are supposed to function as passive attendees, and not speak or volunteer opinions during the meeting.

Objectives of the review

• Present the user stories completed during the sprint to the product owner
• Have the user stories and tasks accepted as “Done”
• Rejected and/or incomplete tasks should be transferred back to the product backlog

 

Who attends?
The product owner, team members, scrum master, and the stakeholders (only if interested – not mandatory)

Time boxed to
1 hour per week of the sprint duration/length decided (I.e. for a 2 week sprint, the meeting should be time boxed to 2 hours, for a 4 week sprint it should be 4 hours, and so on)
 

Roles played by the scrum team members while scrum is being implemented
Several individuals attend sprint review meetings, each having his or her particular interest in the project. The roles of the individuals attending the meeting are explained as follows:
 

Product Owner
The product owner accepts the ownership of the project as far as scrum is concerned, and acts as a “true” owner on behalf of the stakeholders. He or she takes up all the responsibilities, as well as the accountability of the overall team, and represent the entire project to the stakeholders. The person:

• Presents the product increment activities
• Provides an insight into the state of the ongoing scrum project
• Generate a burn down chart displaying the work completed till date
• Successfully and effectively deliver the views and opinions of the stakeholders to the team members

Scrum Master
The main, and the only important role of the scrum master while the project is underway, is to:

• Facilitate the working
• Act as a representative of the development team

He or she ensures that scum is properly implemented at all times, in the proper manner, and should make sure that the team members are collaborating while they work. Another role of the scrum master is to resolve difficulties and remove impediments as and when they arise.   
 

Scrum Team
The entire project is developed by the scrum development team. It is important to know the main difference between the scrum team and the scrum development team – the scrum team comprises of every member associated and involved with the project, while the development team consists only of those individuals who are directly associated with the development of the user stories and the tasks which constitute the product. Their responsibilities include:

• Carrying out the development of user stories and tasks
• Sharing ideas and concepts
• Help each other out when a particular problem is faced by a team member during the sprint
• Collaborate to get the most out of scrum 

 

Company Executives/Stakeholders
The stakeholders own the project. They benefit if the project is successfully completed, and suffer a loss in the event it fails to do so. The objective of the stakeholders is to:

• Invest funds into the project
• Appoint scrum leaders to execute the project
• Monitor the development activity
• Instruct the product owner to add more requirements or user stories if needed to complete the project
• Eventually sell the product to make a profit

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

How Are Sprint Review Meetings Different From Sprint Retrospective Meetings In Scrum? Where Do They Differ?

The primary objective of a sprint review meeting is to present the development work carried out by the development team, avail proper and reliable feedback regarding the work completed until then, and support collaboration. The review meetings are a part of the inspecting and adapting process associated with scrum. Scrum methodology supports self-correction and self-learning methods. There are several processes, which help the team to self-correct, and find where the project is heading. Both the sprint review and the sprint retrospective meetings are conducted after a particular sprint is completed. It is important not to get confused between the two. 

Sprint review meeting
Sprint reviews are informal meetings, and specially conducted to present the work – user stories and development tasks – carried out and completed by the team members during the sprint. The work completed is ideally demonstrated in the form of a “demo” to the stakeholders and investors. The main idea is to put the completed work in front of individuals who have invested into the project, so they can get an idea regarding the quality and the quantity of development carried out. It helps to increase the user participation levels. The stakeholders can subsequently accept the work, reject it if they are not satisfied, or if the work does not adhere to the acceptance levels as specified at the time of creating the product backlog items. The product owner represents the stakeholders’ interests, and he or she decides about the work during the meeting. In reality, the stakeholders may attend the meeting, but they are passive attendees and are not allowed to speak or volunteer opinions during the review. The product owner does all the talking. 

Goals

• Present the sprint development work to the product owner
• Get the user stories and tasks accepted as “Done”
• Rejected and incomplete tasks to be transferred back to the product backlog

Who attends?

• Product owner, team members, scrum master, stakeholders (only if interested)

Time boxed to

• 1 hour per week of the sprint duration/length (I.e. for a 2-week sprint, the time to be allotted = 2 hours for the meeting and for a 4-week sprint = 4 hours, and so on…)

 

Sprint retrospective meeting
The entire team, product owner, and the scrum master ought to put in efforts to find out about what lessons need to be learnt from prior sprints, what more can be done to streamline the sprint process, and what kind of pitfalls and problems are likely to arise in the future and how they can affect the project.    

Goals

• What can and should be learnt from the sprints already completed
• Identify potential pitfalls and impediments likely to affect the team during the sprint activity
• Plan for the next print

Who attends?

• Product owner, team members, and the scrum master

Time boxed to

• 3 hours

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!

The Dos And Don’ts Of Servant Leader Role For Scrum Masters

What is understood by the term “servant leader”?

Several experts have tried to define the role of a servant leader, as to what it should ideally include, and what scrum masters should do to be considered as good servant leaders. To summarize what the authors have to say about the role, individuals desiring to function as good servant leaders should be compassionate, exhibit humane characteristics, act as a facilitator, and be a mentor for individual team members. Rather than discussing in details about each characteristic, the role can be briefly understood by going through the Dos and Don’ts associated with the servant leader role.

What the scrum master should ideally do to become a good servant leader

• Protect the team and its members from distractions and diversions
• Facilitate the planning activities and sessions
• Encourage team members to participate in sprint reviews and retrospectives  
• Implement scrum methodology and coach scrum to team members
• Help the team to collaborate
• Publicly represent and protect the team’s position
• Anticipate issues and problems likely to occur during the sprint activity
• Discover ways and means to remove the impediments faced by the development team
• Ensure daily scrum meetings are properly conducted as per scrum principles and rules
• Support and encourage transparency while implementing the project
• Properly understand and present the team’s progress to the investors and stakeholders
• When necessary, arbitrate on behalf of the team members

What should be avoided or prevented

·      Provide instructions directly or indirectly to the development team
	The scrum master should act as a facilitator and help the team members to find solutions on their own through guidance, advice, and suggestions.
·      Manage the daily scrum meeting
	Rather than directing the team and providing development related solutions, the person should supervise scrum and ensure the team members follow it properly.
·      Estimate the work taken up by the team
	If the team is coming up with an estimate, the scrum master should not interfere by suggesting or advising as to what the estimate should ideally include. If required, the person can arbitrate on behalf of the team.
·      Remain uninvolved or be unconcerned about where the team is heading
	Always try to maintain a holistic attitude about how the project is proceeding, and how the project can be affected by the work carried out by the development team. One should be clear about the project goals and how the team is currently achieving them.

Find out more, and download our free QuickScrum tool which can help you in implementing scrum in an effective and profitable way!