Scrumly

  • Features
  • Process
  • Pricing
  • Contact
  • My Account
  • Features
  • Process
  • Pricing
  • Contact
  • My Account

Product Owner

As a Product Owner, it is your responsibility to identify and prioritize the specific goals for the project.

Manage the Product Backlog

All the goals are captured as Backlog Items in the Product Backlog.  This is an ordered list of goals, with the most important being on top, i.e. the top priority!
Add goals to the Product Backlog

Create new Backlog Items and add them to the Backlog to capture the goals of the project.  It is important to remember that clarity is important here, as you must properly communicate what is desired to other people.  It is also equally important to remember that the other team members, who are doing the work, will best know "how" to do the work.  The Product Owner's job is to describe "what" is desired and "why" it is desired.  This is typically done using a format of Backlog Item known as a User Story.  It is a "story" in simple form to help communicate the value that is desired to be created once this work is done.
  • Learn more about the Product Backlog
  • Learn more about writing User Stories
Approve goals suggested by the team

In a typical project, it isn't just the Product Owner that has all the ideas.  Other people on the team or who have visibility into the project or product may have suggestions and recommendations about what should and should be a goal.  However, it is important that the Product Owner helps to keep the focus on what is truly important for the project and what is a potential distraction.  Anyone on the team is able to contribute new items to the Product Backlog, and the Product Owner gets an opportunity to review and approve those items before the team will take action on them.

Review and Approve the Sprint

During a Sprint, the team will remain focused on a certain set of Backlog Items.  This set is referred to as the Sprint Backlog, and once the team is active on a Sprint, it is not a good idea to interrupt the work.  Interruptions during a Sprint can cause serious delays to the project, as well as demoralize the team who may be right in the middle of their work.  So, it is important that the team is comfortable with what is expected during a Sprint, and the Product Owner is provided an opportunity to review and approve the Sprint before it begins.  This is your final chance to add or remove items from the Sprint.
Approving the Sprint

Once a Product Owner approves the Sprint, the Team Members will begin to actively work on the Backlog Items in that Sprint.
Rejecting the Sprint proposal

Since this is your last opportunity to prioritize the work, you can reject the Sprint proposal and communicate with the team on any of the priority changes.  It's better to do it before the Sprint begins, than to disrupt the team as their working.

Review and Approve Completed Work

Once work is completed on a given Backlog Item, the Product Owner is provided an opportunity to review the work and approve it.
Approving the Backlog Item

Begin the verifying phase on the Backlog Item, and carefully inspect the work.  You are looking for two things: 1) is this what you asked for, and 2) is this what you really want.  Those may seem like the same thing, but sometimes they are not.  Sometimes we find out that what we thought we wanted, is not actually what we wanted after all.  This is a good time to check out expectations.
Rejecting the Backlog Item

You've often got to keep working util you get something the way you want it.  Since this is a team of people, we can find out during this verifying phase just how clear or unclear our explanation of the Backlog Item was.  Each team member may interpret things slightly different, come from different backgrounds, or make different assumptions.  If you need to clarify and continue, this is a chance to do that.  One thing to keep in mind however is to properly inform the team if you simply changed your mind.  Sometimes the rejection of work can be taken personally by the team, after all, these are just people too.  Rejecting a Backlog Item is likely to create re-work for the team, and possibly make the team feel like they're not making as much progress as they thought.  It is sometimes better to accept the Backlog Item, and simply add a new Backlog Item that improves on the work that was done, rather than to reject work.
Learn how the Product Owner fits into the whole Scrumly Team
Terms and Conditions
Privacy Policy
© 2020 Aprisa Labs LLC.  Scrumly is a trademark of Aprisa Labs LLC.