Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Scrum Roles: Product Owner

The Product Owner is crucial to the success of Scrum, but is considered a "Chicken" and doesn't actually take part in in Sprints - the meat of Scrum. So what do Product Owners do?

Robert Mullarky

on 18 February 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Scrum Roles: Product Owner

Product Owner Scrum Roles: Scrum Roles Product Owner
Scrum Master
Scrum Team Scrum Team Actually does all the development
Has all skills / capabilities to deliver a complete product
In each Sprint, responsible for :
What will be delivers
How it will be done
Who will do the actual work
When and what order it will be done Scrum Master Acts as the Scrum Team's representative to the world
Coordinates with the Product Owner
Removes obstacles for the Scrum Team
Runs the meetings, and keeps them on track
Makes sure that artifacts (Scrum Board, Burndown chart) are current Product Owner So what's left for the Product Owner to do?

Why is the Product Owner important?

Why does the Product Owner so often blamed for Scrum problems, or Scrum failing outright? Product Owner has the Vision of the completed product
Product Owner owns the Product Backlog - Crucial to the success of Scrum
Acts as the Customer - and sometimes is the customer
Accepts or rejects work done by the Scrum Team
Answers any questions the Scrum Team has about the product, and what the customer wants. What the Product Owner does, and why Product Owners are CRUCIAL to the success of Scrum Scrum Overview What is Agile
Iterative Development
The importance of planning Traditionally, projects are made in one big push.
Pre-written specifications
Entire development plan laid out in advance Once made, it is often discovered that the customer wanted something else. So the team must either:
Deliver a product that is not as useful as hoped
Work to update/alter their work to meet the customer's actual needs Agile projects are done in iterative stages, with customer input As the project progresses, course corrections can be made, so the delivered product is exactly what the customer wants A A A A A A A A B B B B B B B B C C C C C C C C Done Done Done Done Done Done Agile methods focus on delivering working sub-components. This way high-value portions can be used long before the entire project is complete. Also, customer input at the end of each cycle (block) makes sure the project remains both useful and on course Traditional methods have all parts of a project developed at the same time, all components completing more or less at the same time Planning is crucial A solid plan is required if the process is to work. Some planning requirements are: Selecting what part of the project to work on first
Determining which components should be released and in what order
Setting the priorities between and within components and sub-components
Identifying dependencies, and adjusting priorities to match Without solid planning, the best Scrum Team in the world is doomed to failure. Product Owner Tasks Product Owners have three main tasks:
Have a complete vision of the completed project
Own and maintain the Product Backlog
Represent the Customer to the Scrum Team Vision “The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is.” Product Backlog (Ken Schwaber "Agile Project Management with Scrum" 2004, p. 68) World Tour Vision: To travel to each continent and do some activities that are fun and exciting Clear A vision should be as clear as possible. A muddy or unclear vision can lead to confusion, poor development planning, and poor morale in the Scrum Team as they work on a product they don't believe in. Concise A vision should not be filled with detail: it gets in the way of understanding the goal. A vision should identify what the ultimate goal is, and no more. Details can come later. For example, you can have a vision statement that says:
"I want to buy tickets on an airplane - any reputable airline will do - for each and every full-time salaried and non-salaried employee of this team - to fly to Honolulu, Hawaii, for a stay of three to four days on a non-holiday weekend. I also want to get rooms at a 4-Star, or possibly 5-Star hotel for everyone going, preferably on a beach on one of the main islands of Hawaii, for the purpose of a Team reward for the successful launch of our new 'fewer words are better' communications streamlining software product" The Product Backlog is a prioritized, ordered list of tasks that the Product Owner makes and maintains. Scrum Teams use it to determine what they want to do for their next Sprint. A good Product Backlog is crucial to the success of Scum.

How the Scrum Team uses the Product Backlog is fairly straightforward - how the Product Owner makes one is not. 5 Steps to Making a
Product Backlog 1. Vision
2. Release Plan
3. Stories
4. Sprints Vision A clear idea of what the final product will look like, and how it will be used. Release Plan A plan of what functionalities to release, and in what order, to deliver as much value to the customer as early as possible. Stories Break the work items into fairly small stories that can be completed in one Sprint. Sprints This is where the Sprint Team takes over. The team selects stories, and then breaks them down into Tasks.

This is where the "What I want" from the Product Owner gets the "How, who, and when it will be done" from the Scrum Team. Release Plan This plan will be ordered by Continent: One or more activity for each continent. Us the form "As a [Person/User], I want [Functionality/Features] so that [Outcome/Use]".

This makes clear the context of the story - what use this work is needed for - and also prevents too much detail. An Example Using a non-technical, non-work example of a world-wide adventure tour, I will try to demonstrate the process in a simple way. You can decide if this example succeeds or not. Vision World Tour World Tour World Tour Initial List Asia
North America
South America
Antarctica Ordered List 1 - Asia
2 - Australia
3 - Africa
4 - Europe
5 - North America
6 - South America
7 - Antarctica Prioritize the List Next, prioritize the list by dependencies and customer value. In this case, the customer (me) is quite keen to see Asia and Australia, with Africa quite high on the list as well. aka - Release Plan Initial List Asia
- Swim in the Ganges
- Elephant Trek in Southeast Asian Jungle Mountains
- Climb Mount Everest
- Walk on the Great Wall of China
- Dive the Great Barrier Reef
- Motorcycle across the Australian Outback
- Pilot a sailboat under the Harbour Bridge and past
the Sydney Opera House World Tour Ordered List Asia
1 - Climb Mount Everest
2 - Walk on the Great Wall of China
3 - Elephant Trek in Southeast Asian Jungle Mountains
4 - Swim in the Ganges
1 - Dive the Great Barrier Reef
2 - Pilot a sailboat under the Harbour Bridge and past
the Sydney Opera House
3 - Motorcycle across the Australian Outback Stories With the main high-level stages figured out, now the Product Manager needs to start breaking things down into smaller pieces. The pieces should be small enough that the Sprint Team will be able to complete the work in less time than the length of the Sprint. For this example, each 'Sprint' is assumed to be about 3 weeks Customer Advocate Sprints Now the Sprint Teams get involved. The Team will take the top highest priority items, and start to break them down into smaller 'Tasks', discussing what will be required, how to complete it, what 'Complete' will look like, who will do the work, etc.

Here, the Product Owner is mainly responsible for answering questions about specifics and long-term goals. Initial Review Task: Climb Mount Everest
Team Question: Actually going to the top is very difficult, time-consuming, and dangerous. Much time, training, and money will be required. Are other alternatives acceptable?
- Only go to the Main Base Camp partway up Everest
- Climb another asian peak
Product Owner: Just going to the Main Base camp will be enough for this project, so long we I get to meet Sherpas and talk to people who have summited. Task Breakdown Everest Base Camp:
Research: when is the best time to go
How to travel to Nepal
How to travel to Kathmandu / accommodations
How to travel to Kumjung / accommodations
How to travel to Base Camp from Kumjong
What Material / Equipment will be needed (Tents, heaters, food, etc.)
Research: Are guides and Sherpas generally approachable Team Estimations Everest Base Camp:
Research when is the best time to go
1 Day to complete. Billy
Research materials/equipment needed
1 Day to complete. Betty
Plan Trip - Initial schedule and equipment list
2 days to complete. Barry
Make reservations: to Kathmandu and Kumjung
3 days to complete. Bobby
etc. We won't be using the "As a ... I want ... So that ..." format for stories, since they will all be the same:
"As a World Traveling Adventure Tourist, I want [this adventure trip] planned so that I do something memorable from the continent I am in."

The point of this format is to give context to the task at hand, but I've found there are times when it is more of a burden than a help. Maintain the Backlog Project requirements can change, or the order in which it makes sense to complete tasks may change. The Product Owner needs to maintain the backlog to make sure that everything reflects current needs.
This is also called "Grooming the Backlog". Example In the World Tour Example, Australia is the second continent on the list. However, if there is a sudden outbreak of 'Zombie Disco-dancing Dingos' in Australia, then Australia may be moved from the second continent on the list to the last, so that health officials can have some time to eliminate the scourge. Don't over-plan
the future Product Owners want to have a fair level of detail for stories that the Sprint Team is ready to work on, but tasks further in the future don't need as much detail.

If a Sprint Team finds something that needs to be changed in the design, then the Product Owner needs to update the future tasks to reflect that change - if the Product Owner has prepared 400 tasks, then the Product Owner needs to review them all for changes. A good rule of thumb is that the Product Owner shouldn't have details for more than about three Sprints at any one time. This gives the Product Owner a good cushion of work for the Sprint Teams, while keeping any changes that need to be made to a reasonable level. Don't change plans
mid-Sprint Things Change. Ideas that looked good at one time may not seem so hot later. Resist the temptation to change things mid-Sprint - it is very disruptive to the team, and invalidates many of the benefits Scrum brings for that Sprint:
The Sprint Team's estimations will be invalidated
The Team will lose significant effort re-planning the Sprint
The Team's ownership of the Sprint will be negated
The Teams trust in the Product Owner will be diminished. A benefit of the Sprint is that it is a short time period. Even if the task the team is currently working on is completely unusable, not a lot of time will be lost.
Also, the work will not be in vain - it gives the PO a chance to carefully review and change items, and the Team will gain in skill from doing the task, if nothing else. Just about the worst thing a Product Owner can do is to constantly change stories. The Sprint Team will lose confidence in the Product Owner, the product, and the value of the work they are doing. It is better to work on something entirely different than to repeat work again and again because the design was not well thought through. It is a Product Owner's prerogative to change their mind. It is perfectly fine for a Product Owner to go to a Sprint Review and say "That story you just completed is exactly what I asked for. But things have changed and it is not what I want."
This may not be a big morale boost for the Sprint Team, but it does leave their ownership of the Sprint intact, gives the team credit for the work they have done - even if it is not now needed - and anyone who doesn't understand that these things happen needs to learn it. Do change plans
Between Sprints But it is much clearer to just say: And then work out all of the details later. "I to reward the entire team with a vacation in Hawaii". Plan Releases to
Delight Customers Another aspect of a Customer Advocate is to make sure that the customer can use what is delivered. The Product Owner is the one who determines the overall release plan, consisting of what components are released in which order. Because the Product Owner is the Sprint Team's window to the customer, the Product Owner needs to be very clear about what the customers want, and how the product being made is to meet that need. Delivering key functionality long before the product is complete is one way to delight your customers. Product Owner IS
the customer For Sprint Teams, the Product Owner answers both types of customer question:
What do customers want?
Will this work acceptable to customers? The first question is asked (repeatedly) during the Sprint. The second is asked during the Sprint Review, when the Product Owner accepts or rejects the work done during the Sprint by the Sprint Team. The Product Owner... Owns the Vision of what the final product will be, and is responsible for making sure that the team's work is aimed at fulfilling that vision.
Creates the main Release Plan: defining what components are released and in what order
Creates the Product Backlog - the development roadmap and source of tasks for the Scrum Team to work on.
Constantly updates the Product Backlog, so the most important work is prioritized and all requirements are current
Prioritizes items in the Product Backlog, so the Scrum Team will know what to work on next
Makes sure the results of Sprints are appropriate for the product
Is the Scrum Team's customer representative, and is available to answer the questions the Scrum Team needs answered in order to develop the product the customer wants. The Product Owner is KEY to the
success or failure of Scrum! Accept/Reject Once the Sprint Team completes their work, the Product Owner will be shown the results in the Sprint Review.

In the Sprint Review, the Product Owner will be able to see if all of the Definitions of Done have been completed, and whether or not the work the Sprint Team has done is acceptable.

Remember - everything that the Product Owner accepts should be good enough for customers to use ... even if incomplete. This is a crucial step. This is where the Product Owner takes responsibility for the quality of the product. By accepting work by the Sprint team, the Product Owner confirms that the work is good enough for customers. If the quality of the work does not measure up after being accepted, it is the Product Owner's responsibility!
Full transcript