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.
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.
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.
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.
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.
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.
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.
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.