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 Desirable Characteristics Of A Good And Effective Product Owner

The role of a product owner is very important in scrum. Besides representing the client and the stakeholders in the project, the  “PO” also has several responsibilities to fulfill with regards the scrum team and the scrum master. The role is not an easy one. The challenges faced by a PO extend far beyond the capacity of a traditional product manager. Besides being responsible for the project’s success, the PO has to carry out several other activities such as:

• Preparing the product backlog
• Defining the product backlog items
• Working out the sprint releases
• and reviewing the work carried out by the development team.

The person is also responsible for defining the acceptance criteria linked with the user stories, and accepting the work as “Done” during the sprint review meetings. Product owners are often pressed for time, and may face certain difficulties while carrying out their work.

It is worth knowing what makes an ideal product owner. Some of the most important characteristics are mentioned herein.

A visionary and a “Doer”

The individual should have the vision to imagine what the final product should be like, and communicate his or her vision to the entire scrum team. The person should also be a “Doer.” He or she should lead by example and preferably use a servant-leader role while delegating authority. The effort should be made to facilitate the scrum proceedings, rather than to issue orders and wait for the team to fulfill them. The person should be able to capture the ideas regarding the requirements as to how the development should be carried out, in what manner, and collaborate closely with the team to avail proper and useful feedback, and analyze it to make informed decisions. The PO should possess the capability to steer the project in the right direction and forecast its progress from time to time. The individual should also think as an entrepreneur and provide valuable suggestions regarding the product to the stakeholders and the investors. It is important to facilitate creativity, encourage and support new ideas and vision, motivate the team members, and feel comfortable while dealing with the changes in the product definition as and when the stakeholders apprise him or her about new product related requirements to be carried out in the functionality developed till date.

Be a leader and a great team player

While talking about the scrum framework, a good PO should be able to create a vision, articulate it, passionately own it, nurture it, and relentlessly strive to achieve the vision in real life by presenting the product to the stakeholders – exactly as they want it. It is exceedingly important to guide the team and everyone involved with the project, and be ready to make tough decisions when they are called for. Above all, the PO should encourage and promote collaboration as it is the base upon which the scrum methodology operates and delivers the results. It is not recommended for a product owner to dictate decisions and delegate authority in an autocratic manner. Moreover, even though the PO is empowered to make decisions, the person should ideally seek the team’s consensus for all scrum related activities. If possible, the team ought to be involved in the decision making too, although few product owners actually prefer to do it in real life.

A good communicator and an effective negotiator

To be a good product owner, and an effective one, the person should possess the skills necessary to negotiate successfully with the customers, end users, development and engineering teams, marketing and sales executives, service personnel, operations department, and the management. It is also important to be a good communicator and have the ability to explain complex ideas and thoughts in a simple and straightforward manner to people who are not technically sound or who are naive.

Subscribe to the permanent free version of the Quickscrum project management tool to get an idea about how the tool works and what it has to offer.

Explanation Of Scrum Burndown Charts – The Plotting, Requirement, And Purpose Of Burndown Charts

What is a burn down chart?
A burn down chart is an important tool in scrum. It provides a visual representation about the progress achieved in a sprint while it is underway. They are very common and extensively used by scrum masters while scrum is being implemented in a project. The quantity, or the amount of work remaining, in the form of pending tasks, is typically exhibited in a burn down chart. The chart is simple and easy to understand, even by people who are not familiar with scrum methodology. Burn down charts are very useful for estimation purposes, and are essential for determining the sprint velocity – the rate at which work in the form of user stories is being completed by the development team – and planning the sprint release.
 

Plotting the burn down chart
A burn down chart can be plotted by including the work remaining in the form of story points along the vertical Y-axis and the working days along the horizontal X-axis. The pending work is typically represented in story points – a unit of measurement to calculate the importance and priority of user stories in the sprint backlog – instead of user stories. The reason is user stories are broken down into tasks during the second half of the sprint planning meeting by the development team. It becomes difficult to read and understand the chart if tasks are represented along the Y-axis. User stories are descriptive in nature, and do not have a number or a value associated with them, so it becomes difficult to estimate them. Therefore, the story points, which are numeric values associated with each user story, are used for plotting purposes.
 

On the first day of the sprint, the total number of days completed in the sprint is zero while the pending work constitutes of the entire sprint backlog. Conversely, when the entire sprint is processed, the number of days is equivalent to the days the sprint has actually lasted – generally two weeks – and the pending work should be zero. The burn down chart can include an “ideal” working line, which originates from the top left-hand-side corner of the graph where the number of days is equivalent to zero along the X-axis and the story points are maximum on the Y-axis. The ideal line extends or runs diagonally, and connects to the bottom right-hand-side of the graph, on the X-axis where the days are maximum i.e. equal to the total number of days the sprint lasts. The story points are zero on the Y-axis. The ideal line reflects the desired level of work and sprint completion status.   
 

Starting from day zero, when the story points are maximum, as the sprint progresses, the days increase along the X-axis while the story points start decreasing along the Y-axis. On day one, when some of the user stories are completed, a point is interpolated on the graph which correlated to the first day of the sprint on the X-axis and a value equal to the maximum story points in the sprint minus the value of story points completed on that day. For example, if 25 story points are included in the sprint, and on day one of the sprint if work equal to 5 story points is completed, the total pending work remaining in the sprint is equivalent to 25 – 5 = 20 points. The coordinates of the point would be (0, 20) on the graph. Similarly, on the second day of the sprint, if work equal to 1 story point is completed, the total work remaining is equivalent to 20 – 1 = 19 story points. The coordinates for the second day would be (1, 19) on the graph. Many scrum masters prefer the dates to be displayed along the X-axis in lieu of days to make the chart more readable.
 

Reading the chart
Many burn down charts actually have the “ideal” line plotted on them – for reference and estimation purposes. It is a good visual indication whether the particular sprint is proceeding as per schedule, or whether the development work is carried out behind schedule.  The line represents the ideal “burn down” required for attaining the sprint goal or the ideal position to be in at the end of sprinting day. The actual work carried out is plotted on the graph with the help of coordinate points. All the points plotted on the graph are connected with a line, which passes through them. If the actual line extends above the ideal line, it indicates that the sprint is proceeding behind schedule, and the required number of tasks is not being completed as per the sprint planning. This basically indicates two things – one, the team has to put in more efforts to compensate for the pending work which should be completed the next working day, and two – the team is required to introspect and find out why the tasks were not completed on time. It is important to self-correct and ensure the same mistakes are not repeated since scrum advocates self-learning and self-correction processes.
 

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