So let's get into the roles, Product Owner. The Product Owner represents the voice of the customer and has the authority to make decisions about the product. The Product Owner is responsible for making sure that the product meets the requirements of the users and the customer. So the Product Owner needs to keep focused on the business side of product development. The Product Owner should spend the majority of their time liaising with stakeholders, and should not dictate how the team reaches a technical solution. The Product Owner needs to be able to describe and define the product in user-centric terms, typically called user stories. So it's not a technical role per se, and the Product Owner should refrain from technical discussions. 

The Product Owner owns the product backlog and is responsible for communicating the vision to the team, and defining and prioritizing backlog items. The Product Owner needs to work with the team on a daily basis to discuss requirements, answer questions and provide product guidance. Scrum teams should have one Product Owner, and the Product Owner should not be the Scrum Master. The Product Owner needs to be one person and not a committee. Communication skills are a core skill for the Product Owner to acquire and master. The ability to convey priorities, and to empathize with stakeholders and team members is vital to ensure the product development continues to head in the right direction. 

As a Product Owner you need to really get inside the user's world, to understand what they are trying to achieve. I find one on one interviews with users to be the most effective format, for finding out those user stories and understanding those requirements. However, a story gathering workshop can be used as well to capture and collect user stories from a group of stakeholders, and/or group of users. The next role is the Scrum Master. Now the Scrum Master is the advocate and the protector for the development team. The Scrum Master removes obstacles, mediates discussions within the team and negotiates discussions with external partners and team members to the team. The Scrum Master will liaise with the Product Owner and negotiate who is doing what by when in the spring tasks. 

The Scrum Master will select and assemble a development team, and the Scrum Master communicates and controls the process. But above all the Scrum Master works for the team. So the development team. While the Product Owner defines what we are delivering, the development team owns how things will be delivered. The development team is formed and facilitated by the Scrum Master, and as a self organizing unit there is no right or wrong way of shaping a development team. The development team is a self organizing and self managing group of individuals, with cross functional skills. Self managing, hmm, this idea of a team can appear a little off center to project managers, used to allocating tasks to developers and managing delivery of work units. Now remember the foundation stones of our job. We want to encourage individuals to use their skills. To show initiative and to take ownership. So at heart, accepting Agile as a process may require you to first let go of a few traditional project management beliefs. The development team size should be small enough to remain nimble and large enough to complete significant works within a sprint. 

The development team usually consists of three to nine people, and that development teams are responsible for the delivery of the features and functions agreed to in each sprint. The development team own making estimates, making task commitments and reporting status daily to each other in the daily stand up. So the Product Owners decisions are visible in the content and the ordering of this product backlog. So far so good, but here are where things can get a little difficult. No one should tell the development team to work on a different task or from a different set of requirements than that, that's in the product backlog, and the development team isn't allowed to act on what anyone else says. So that requires a bit of a change in the way most business teams tend to integrate and do things. For the Product Owner to succeed the entire organization needs to respect the decisions of the Product Owner.