The Product Owner is the wringable neck in Scrum. They are responsible for:

• Write down the requirements for the project
• Prioritize the requirements
• Release schedule for the project
• Be available during the sprint and sprint planning meeting to:
  • Explain business context of each requirement to the team
  • Explain acceptance test criteria for each requirement to the team
• Provide feedback on working features developed by the team during sprint review

As seen above, the Product Owner controls the release schedule and requirements or “what is to built” and “when it is to be built“. She leaves “how it is to be built” generally to the team. The team can provide the Product Owner feedback on these two dimensions, but it is primarily Product Owners call on these two issues.  It is important to note that although Scrum and Agile are collaborative processes, the Product Owner holds the final authority for determining the value, priority and details of all work done by an Agile team. The Product Owner wields this authority by virtue of a deep knowledge of the goal and end results desired as well as a respected position among all the stakeholders. This is one of the pivots for “business alignment” in an Agile Process. Although, the term Product Owner is used mostly in Scrum, it is increasingly being used to reference a “Marketing or Business role” in most Agile teams.

Another important aspect with most software projects is that there may be more than one stakeholder for the project. However, in this case as well, there would be only one product owner. As discussed before, the product owner can discuss with as many people as she likes and use any medium to arrive at her list of requirements and their priority, but only one product owner would ideally prioritize the requirements as well as set acceptance criteria for each requirement. This is to ensure that “what is being built” and “when it is being built” are very clear through out the project. In case there are more than one stakeholders/ customers, the product owner can work with them during the sprint writing the requirements or getting market feedback on requirements for prioritization.

A product owner is sometimes also aided by testers [who help frame acceptance tests for requirements] and business analysts [who help frame requirements, business context]. That is why most business analysts and testers are ideal people to graduate to a product owner role. An ideal product owner would combine business analyst, testers and marketing profile. In addition, here are some things the product owner should not do:

• Pressurize the team into committing to more requirements than they are comfortable with for a sprint. If she feels, the team is under committing, she can bring this to Scrum Master or Agile Coache’s attention and discuss during Sprint Review. The idea is to discuss the issue, rather than use subversive and non-collaborative tactics.
• Make changes during the sprint. This is done to keep the team focused. In case the product owner feels the need to make changes to the sprint regularly, the team might want to consider whether their sprint length is too long that does not allow product owner opportunity to inspect and adapt at her end.
• Be unavailable during the sprint. It is important that the product owner or proxies are available to answer any team questions as they arise. The idea is to keep the keep on track and empowered to keep moving without having to wait for information.

A product owner hence is the window through which the Agile team interacts and integrates market dynamics in a software project.

Popularity: 20%

Posted on February 29th, 2008 by admin
Filed under: Introduction, Leadership | No Comments »

After the team has picked the requirements from the Project Backlog, during the Sprint Planning Meeting, the team normally drafts a Sprint Backlog, the team starts working on the requirements and through a Daily Stand Up during the Sprint and updates the Sprint Backlog. Once the sprint is complete, the time comes to demonstrate working functionality. For this, the team and product owner gather together for Sprint Review. A Sprint Review is a meeting where the team demonstrates working software corresponding to project backlog items they have completed in a given sprint. There are some simple rules for a Sprint Review:

• The meeting is kept very informal. The team should not have to spend time preparing for the same beyond getting working software ready.
• Powerpoints, presentations, speeches and lectures are not allowed.
• You can only demonstrate working software.
• The preparation [working environment, arranging room] is done by the Agile Coach or Scrum Master.
• The meeting generally lasts about 1 hour per week of work [but this obviously can change depending on number of team members working for the project].
• The whole team, product owner or customers and stakeholders participate in the Sprint Review Meeting.

Of the above focus on “working software” is very important. This keeps the teams focus on delivering working software and adopting processes which aid delivery of the same. Thats another reason why any aids like PowerPoint slides or lectures are not allowed. The team would typically demonstrate each code it has written either through GUI, mock objects or through API calls. Actual working software allows product owner or customer to get first hand experience of the working features and based on the same provide feedback to the team. The feedback to the team is typically of these components:

• Whether they completed enough requirements
• Whether they completed requirements quite early
• Whether they understood the requirements and translated them to working features well enough

All three help the team and product owner plan for the next sprint better. At the end of sprint review meeting, Agile Coach or Scrum Master would announce the date for next Sprint Review and confirm the date for next Sprint Planning session. This sets the tone for the next sprint. After the Sprint Review Meeting, the team moves towards the Sprint Retrospectives.

The Sprint Review also works as a feedback channel for the Product Owner in some ways. The Product Owner invites stakeholders and customers who give her the actual feedback which she can factor into her requirements for future. She can then edit or delete any requirement or add new ones. In addition, they help the Product Owner identify the correct priority for requirements and minimize the biggest risk of all - developing the wrong thing as well as the second biggest risk - developing the wrong thing, the wrong way. Hence, Sprint Review is basically a “feedback, inspect and adaptation” channel in an Agile Development Framework.

Popularity: 30%

Posted on February 28th, 2008 by admin
Filed under: Assessment, Collaboration, Introduction, Practices | No Comments »