Often in my classes, I’m asked for a clear comparison between the various traditional roles and the new roles in Scrum. Here is a high level summary of some of the key responsibilities and activities that help highlight some important differences between these four roles:
ScrumMaster
Product Owner
Project Manager
Team Lead
NEVER
NEVER
Assign Tasks
YES
NO
PARTICIPATES
Create Schedule
NO
NO
YES
Manage Budget
NO
Remove Obstacles
PARTICIPATES
YES
YES
NO
Define Business Requirements
PARTICIPATES
NO
NO
YES (Deliveries)
Define Milestones
NO
Facilitate Meetings
NO
YES
YES
YES (process and people)
YES (business)
Risk Management
PARTICIPATES
Organizational Change Agent
NO
NO
NO
NO
Accountable for Business Results
RARELY (just costs)
NO
Of course, there are many other ways we could compare these four roles. What would you like me to add to this list? Add a comment with a question or a suggestion and I will update the table appropriately!
The ultimate purpose of Product Backlog refinement is to ensure an ongoing conversation that increases transparency of the Product Backlog and therefore the Product itself – to orient everyone on the team to breaking out of their waterfall silos and focus on delivering business value, period.
On mature teams, a lot of the refinement work happens as ad hoc conversations while they are sitting around and thinking together about how to build something great because they are just motivated by that and it becomes part of their mode of operation.
The objective of the refinement work of any given Sprint (that often needs to be repeated over and over like a mantra with new, immature teams) is to ensure that the items at the top of the Backlog are transparent enough that the Development Team considers them ready to pull and get “Done” in the next Sprint. This is where the concept of the Definition of “Ready” (DoR) comes from – the Scrum Team defines the DoR and spends up to 10% of its capacity refining enough items at the top of the Backlog so that it can provide estimates (if required) and have a reasonable degree of confidence that it can deliver the items in the next Sprint.
Refinement is NOT solutioning – I think this is the big trap that a lot of teams fall into because there is a false assumption that technical solutions need to be hashed out before estimates can be made (part of the carried-over lack of trust and communication between the business and IT) – I would almost rather throw out estimates in cases where this is not improving – The Planning Game exercise, when facilitated well, lends itself more to increasing transparency rather than solutioning.
The fact that teams are telling us that they need to solution before they can estimate is also an indication of weak Agile Engineering practices such as refactoring, test-driven development and continuous integration (XP). The best refinement sessions are those in which the team is able to focus on the “what” – the business benefit results that the Product Owner really wants – rather than the “how” (solution). Strong teams emerge in an environment in which they are trusted by the business and management to find the right solution as a team. They don’t need to have it all figured out before giving an estimate because they are not afraid to give a bad estimate and fail. Also, if the team is struggling to give estimates, this is often a sign that the Product Backlog Items are too big. Most likely the team also needs to expand the Definition of “Done” to include testing against acceptance criteria within the Sprint so that they can estimate based on that criteria.
The “how” (solution) should be mapped out by the Development Team at a high level in the 2nd part of Sprint Planning (partly why the time box is bigger than they often think they need) and more detailed architecture, requirements and design work as part of the Sprint Backlog
But this level of maturity is very hard to do and it will take a while to get there, perhaps even years.
It also depends on your interpretation of “detail”, the word used in the Scrum Guide to describe what the team does in Product Backlog refinement. To me, it means understanding in more detail what the Product Owner really wants and needs. What does it mean to you?
Over the many years that I have been teaching Scrum (since 2005!), I have had a Scrum diagram as part of my slides and/or handouts. The diagram has gone through several major and minor changes throughout that time. Here is the progression from oldest to newest:
First Attempt
This diagram was used in some of my earliest slides when I first started delivering Scrum training. It is bad. It is woefully incomplete. But, here it is:
Second Diagram
I knew the first one was bad so after not too long, I created this next diagram as a supplement that was meant to show the whole Scrum process all in one page. Similar to other Scrum “cheat sheet” style diagrams. I used this diagram until about 2008 when I got some very good feedback from a great trainer, Jim Heidema.
Third Try
The changes I made were small, but to me, significant. Changing from a “mathematical” language of “Sprint N”, “Sprint N+1” to a more general language of “Current”, “Future” was a big deal. I really struggled with that. Probably because I was still relatively new to being non-technical.
Diagram Four
This fourth diagram made some minor formatting changes, but most importantly added “Backlog Grooming”. It’s funny how long I talked about grooming in my classes before realizing that it was missing from the diagram. I used the previous diagram and this diagram for a couple years each before making a rather major change to create the next one.
Fifth Go
A couple years ago I realized that I wasn’t really talking about the Scrum values in my classes. I started to introduce them in some of my other handouts and discussions, but it still took a while for me to reflect those values in my diagram. I had also received a lot of feedback that having two Product Backlogs in the diagram was confusing. Finally, I realized that I was missing an opportunity to use colour more systematically. So, a major reformatting, systematic colour coding and the addition of the Scrum values was my next change.
Branded Diagram (ug.)
In a rush, I added some logos to the diagram. Just made it gross, but it’s badness, combined with feedback about said badness, actually inspired a major change for the next version.
Seventh Diagram (Sep. 2014)
I was showing my brand-new branded diagram to a bunch of people who really care about design and UX. The very first comment when I handed out the diagram was: “wow, you can really tell this wasn’t done by a designer!” Well, that got me thinking deeply about the diagram (again). So, here is my newest, latest and greatest (still not done by a designer) version of my Scrum diagram!
Eighth Diagram (2016-ish)
This new diagram represents many small changes including a much stronger focus on Scrum “by-the-book”. The most important and significant change is the addition of a bit of information about the definition of done. It also includes some other very minor layout and content changes, and updated branding (again) with the new BERTEIG logo. This one has been in use since some time in 2016, but I don’t remember the exact date.
Ninth Diagram (June 2019)
A re-branding of the diagram with color and iconography meant to be consistent with our other diagrams. The work on converting from the previous diagram to this one was done by my son, Justice Berteig.
Tenth Diagram (Sep 2019)
There were quite a few things that were missing from the previous diagram and a small number of things lingering that still were not compliant with the definition of Scrum from the Scrum Guide. I think this one has all the needed changes. Big additions include the “Development Team”, “Transparency, Inspection and Adaptation”, “Product Vision” and “Marketplace”.
The Future
I would absolutely love constructive feedback about this latest diagram. Of course, if you like it, please let me know that too! The thing I like about this is that it is a way of looking back at almost 9 years of my teaching history. Continuous improvement is so important, so I welcome your comments! If you have your own diagrams, please link to them in the comments – I would love to see those too! In fact, it would be really cool if a bunch of people could make little “Evolution of a Scrum Diagram” posts – let me know if you do!!!
Whenever I run a Certified Scrum Product Owner training session, one concept stands out as critical for participants: the relationship of the Product Owner to the technical demands of the work being done by the Scrum team.
The Product Owner is responsible for prioritizing the Product Backlog. This responsibility is, of course, also matched by their authority to do so. When the Product Owner collaborates with the team in the process of prioritization, there may be ways which the team “pushes back”. There are two possible reasons for push-back. One is good, one is bad.
Bad Technical Push-Back
The team may look at a product backlog item or a user story and say “O gosh! There’s a lot there to think about! We have to build this fully-architected infrastructure before we can implement that story.” This is old waterfall thinking. It is bad. The team should always be thinking (and doing) YAGNI and KISS. Technical challenges should be solved in the simplest responsible way. Features should be implemented with the simplest technical solution that actually works.
As a Product Owner, one technique that you can use to help teams with this is that when the team asks questions, that you aggressively keep the user story as simple as possible. The questions that are asked may lead to the creation of new stories, or splitting the existing story. Here is an example…
Suppose the story is “As a job seeker I can post my resume to the web site…” If the technical team makes certain assumptions, they may create a complex system that allows resumes to be uploaded in multiple formats with automatic keyword extraction, and even beyond that, they may anticipate that the code needs to be ready for edge cases like WordPerfect format. The technical team might also assume that the system needs a database schema that includes users, login credentials, one-to-many relationships with resumes, detailed structures about jobs, organizations, positions, dates, educational institutions, etc. The team might insist that creating a login screen in the UI is an essential prerequisite to allowing a user to upload their resume. And as for business logic, they might decide that in order to implement all this, they need some sort of standard intermediate XML format that all resumes will be translated into so that searching features are easier to implement in the future.
Because that’s not what the Product Owner asked for. The thing that’s really difficult for a team of techies to get with Scrum is that software is to be built incrementally. The very first feature built is built in the simplest responsible way without assuming anything about future features. In other words, build it like it is the last feature you will build, not the first. In the Agile Manifesto this is described as:
Simplicity, the art of maximizing the amount of work not done, is essential.
The second feature the team builds should only add exactly what the Product Owner asks for. Again, as if it was going to be the last feature built. Every single feature (User Story / Product Backlog Item) is treated the same way. Whenever the team starts to anticipate the business in any of these three ways, the team is wrong:
Building a feature because the team thinks the Product Owner will want it.
Building a feature because the Product Owner has put it later on the Product Backlog.
Building a technical aspect of the system to support either of the first types of anticipation, even if the team doesn’t actually build the feature they are anticipating.
Okay, but what about architecture? Fire your architects. No kidding.¹
Good Technical Push-Back
Sometimes stuff gets non-simple: complicated, messy, hard to understand, hard to change. This happens despite us techies all being super-smart. Sometimes, in order to implement a new feature, we have to clean up what is already there. The Product Owner might ask the Scrum Team to build this Product Backlog Item next and the team says something like: “yes, but it will take twice as long as we initially estimated, because we have to clean things up.” This can be greatly disappointing for the Product Owner. But, this is actually the kind of push-back a Product Owner wants. Why? In order to avoid destroying your business! (Yup, that serious.)
This is called “Refactoring” and it is one of the critical Agile Engineering practices. Martin Fowler wrote a great book about this about 15 years ago. Refactoring is, simply, improving the design of your system without changing it’s business behaviour. A simple example is changing a set of 3 radio buttons in the UI to a drop-down box with 3 options… so that later, the Product Owner can add 27 more options. Refactoring at the level of code is often described as removing duplication. But some types of refactoring are large: replacing a relational database with a NoSQL database, moving from Java to Python for a significant component of your system, doing a full UX re-design on your web application. All of these are changes to the technical attributes of your system that are driven by an immediate need to add a new feature (or feature set) that is not supported by the current technology.
The Product Owner has asked for a new feature, now, and the team has decided that in order to build it, the existing system needs refactoring. To be clear: the team is not anticipating that the Product Owner wants some feature in the future; it’s the very next feature that the team needs to build.
This all relates to another two principles from the Agile Manifesto:
Continuous attention to technical excellence and good design enhances agility.
and
The best architectures, requirements, and designs emerge from self-organizing teams.
In this case, the responsibilities of the team for technical excellence and creating the best system possible override the short-term (and short-sighted) desire of the business to trade off quality in order to get speed. That trade-off always bites you in the end! Why? Because of the cost of fixing quality problems increases exponentially as time passes from when they were introduced.
Refactoring is not a bad word.
Keep your code clean.
Let your team keep its code clean.
Oh. And fire your architects.
Update Sep. 8, 2015: Check out this YouTube video on the closely related topic of who has authority over the Product Backlog and why developers should not set the order of PBIs:
¹ I used to be a senior architect reporting directly to the CTO of Charles Schwab. Effectively, I fired myself and launched an incredibly successful enterprise architecture re-write project… with no up-front architecture plan. Really… fire your architects. Everything they do is pure waste and overhead. Someday I’ll write that article 🙂
This Product Owner Simulation exercise rests on the idea that people learn a lot better by doing something than by talking about it. My Product Owner classes were getting great reviews, but I really felt like there was something missing compared to my ScrumMaster classes which have a full-day ScrumMaster simulation exercise. It took a little while to figure it out, but this article describes in detail how I do the simulation for the Product Owner class. I’m sure it will evolve and get refined from here since I have only used the simulation twice so far.
UPDATE: 2016-08-14 – major updates to the Product Owner Simulation after having used it at least 15 times since this was originally written!
UPDATE: 2017-07-13 – minor updates including new versions of handouts that better explain some concepts, and slightly expanded facilitator’s notes.
NOTE: Permission to use this exercise / print associated materials is granted with a simple request: please link to this page on your blog, in a LinkedIn group or Google group, like it on Facebook etc. or write a comment in our comments section!
Pre-requisites: None! No prior Scrum or Agile knowledge or experience required. However, it is recommended that participants have an introduction to Scrum or have read the Scrum Guide.
Audience: Product Owners, Business Analysts, Project Managers, Product Managers and other people responsible for business results and who interact with a Scrum team.
Timing: This simulation takes at least 7 classroom hours. I usually run it from 8:30am to 5:00pm with a one hour lunch break and two 15 minute breaks during the day.
Planning Game cards (email me if you want a bunch for free!)
Room Setup: Round tables with 5 to 7 chairs at each table. Materials distributed to each table.
Product Owner Simulation Agenda
(with facilitator’s notes in red)
Introduction to the Product Owner Simulation
Lecture: Simulation Overview, Backlog Preparation and Refinement The purpose of the overall simulation is to learn to create a good Product Backlog in preparation for a Scrum team’s first Sprint. Many of the techniques we explore will also be useable in ongoing Product Backlog Refinement. Review the agenda with participants.
Exercise: Great Products and their Vision 5 minutes – at table groups, think about the physical consumer products you know and use often. How are those products marketed and sold? How are they presented? How do you decide to use that product vs. a competitive product? Make sure you discuss specific products rather than corporate brands or product categories.
Discussion: What Makes a Great Product Vision? Ask for the group to brainstorm the qualities of a great product vision. Ensure that “simplicity”, “urgency”, and “emotion” are all mentioned. (Great reference: “Made to Stick: Why Some Ideas Survive and Others Die” by Chip and Dan Heath.)
Discussion: Choosing a Product for the Simulation Give participants three product options (suggested options: “Doggy dating web site”, “iPad app for plastic surgeons’ medical and practice management”, “POS for food trucks with social features”). A table group must agree to one of the options. They will stick with this product for the remainder of the simulation. Three minutes to decide.
Product Vision
Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.
Exercise: Product Vision Statement
5 minutes – attempt to craft a brief, compelling product vision statement that communicates “simplicity”, “urgency” and “emotion”. The audience of the product vision statement is your Scrum Team (NOT customers). Debrief by hearing from each group, then asking if the three characteristics have been communicated.
Lecture: Explain the Product Vision handout and ask for questions, insights. At this time, highlight the differences between a “product” and a “project”. Emphasize the concept that a product has customers who pay money and who have choice about what they buy, and that those customers are outside of your organization. Possible discussion about Scrum being ideally suited for Product Development vs. project management or operations.
Lecture: Product Box Talk about the need for a compelling vision as a pre-requisite for high-performance teams, and a way to decide what is in vs. out of a Product Backlog. Introduce “Product Box” as a way to do market research in an Agile compatible way (collaborative, light documentation, quick). Talk about the pattern of a product box: front to attract, back to showcase, sides to deal with objections. Use of online resources / web research is allowed but should not dominate the exercise.
Exercise: Building Your Product 30 minutes, with warnings at 15 minutes and 5 minutes remaining. Ensure that by 10 minutes in, the group has actually started using the craft supplies and isn’t just talking.
Exercise: Presenting Your Product 5 minutes – give additional time to allow groups to prepare for a trade show (in their market) presentation where other groups (or yourself) will role-play sceptical trade show participants.
Discussion: Debrief Product Box Focus on feasibility of using Product Box in real life, the power of metaphor, and the power of collaboration.
Exercise: Product Vision Statement Reprise 5 minutes – attempt to craft a brief, compelling product vision statement that communicates “simplicity”, “urgency” and “emotion”.
Discussion: Debrief by hearing new Product Vision Statements.
Product Users
Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.
Lecture: User Categories Describe “users we sell”, “users who pay” and “admin users” as the three major categories. Users can be in hierarchies where a general user type may have two or more specific sub-types.
Exercise: Identifying Users 10 minutes. One user of each main type, at least 5 users in total. More is okay.
Lecture: Personas, Usability and Empathy Introduce Persona concept (great reference: “The Inmates are Running the Asylum” by Alan Cooper). Usability as part of Agile, not separate (i.e. “working software”). Identifying personas as a way to build empathy from the development team to the end users/customers.
Exercise: Generate a Persona 10 minutes. Choose a primary user. Generate name, age, background story, and relationship to product. Find an image from a stock photography site. Important: do at least a little bit of research and tie some part of your persona to that research! Try to be specific and write the background so it emphasizes the concept of empathy.
Business Value
Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.
Lecture: Good and Bad Metrics Describe ROI, TTM and CSat as all-around good metrics. Explain red-yellow-green project dashboard and lines-of-code as bad metrics. Ask for other examples of good or bad metrics.
Exercise: Value Metrics 10 minutes. At table teams try to come up with at least 10 quantitative and 10 qualitative metrics. Use the handout as a worksheet. Focus on metrics relevant to the simulation product, but also consider metrics that might be from other businesses or viewpoints (e.g. finance metrics, marketing analytics, etc.).
Discussion: Value Metrics Throughout the classroom, share all the metrics and write them on a flip chart so they can all be seen at once. Ask for insights or questions about metrics.
Exercise: Key Metrics From the flipchart, each table team should choose 3 to 6 metrics that are most important to measure business success of their product. It’s okay for that short list to include ROI, TTM and CSat. Keep this list handy for the next part of the simulation.
Discussion: Metrics and Product Vision Discuss if/how Product Vision helped to choose the key metrics. If needed, allow a few moments for participants to reconsider the metrics they chose in light of their Product Vision.
Product Backlog Items
Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.
Exercise: Create Product Backlog Items Use the product box, the user categories, and the business metrics. For each row in the worksheet, identify a feature, decide which user interacts with the product to exercise that feature, and choose the business metric that is most improved by implementing the feature. For each, decide if the feature is visible to the user through the user interface. The resulting worksheet should be filled up such that at least ten of the features are visible in the user interface.
Lecture: Writing Effective User Stories Use the example “As a Job Seeker, I can upload my resume, so that I get a job.” Explain the user story template based on the handout. Emphasize the idea of end user functionality. Explain user stories as an important tool, but optional part of Scrum. Usually some time is spent on a discussion about physical note cards vs. electronic tools – emphasize the fact that the note cards support the values and principles of the Agile Manifesto while electronic tools (typically) subvert them.
Exercise: Create User Stories Goal: 20 user stories for each group’s product, at least five user stories for the persona, and two user stories for each other type of user, all done in 20 minutes. User Stories must be written on 3×5 note cards with a 2cm blank area on right side of each card. The groups start by writing one or two User Stories together, then divide and conquer to create the rest. At the end of the 20 minutes, there is a brief amount of time allocated to making sure there are no duplicated “features” described.
Discussion: Review User Stories Workshop examples from each group. Ensure that the “benefit” section of each story does not contain a feature. Possibly discuss the three parts of a User Story as “who”, “what” and “why”. The benefit is usually related to time, money or happiness and connects the User Story to the product vision.
Exercise: Small, Uncertain, Large Effort Estimation Small means “easily and with certainty fits within a single Sprint”, large means “definitely requires more than a full Sprint of work”, and uncertain means either “uncertain size” or “uncertain if it will fit in a single Sprint”. Teams create buckets and sort all the user stories into the three buckets – they must role play being technical contributors (Development Team Members). Start by identifying one “small” one and one “large” one, then by dividing an conquering. Final step is to verify that the small ones really are small.
Lecture: Splitting User Stories Go through each of the “top” six splitting methods. Provide simple examples where the group needs help. E.g. error conditions as an example of splitting by business logic.
Exercise: Split Some Goal: result in at least 30 user stories, use each of the top six splitting methods at least once, give 15 minutes. Focus on splitting the items that were estimated in the “Large” or “Uncertain” buckets.
Discussion: Review Splitting
Estimation and Financial Modelling
Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.
Lecture: Effort, Value and ROI Customers and business stakeholders estimate value, Scrum team members estimate effort, and ROI is the calculation of the ration of value over effort. Discuss examples of ordering based on these ratios, e.g. 8/2 vs. 8/4 and 200/20 vs. 20/2.
Lecture: The Bucket System Review process based on handout.
Exercise: Estimating Business Value 10 minutes. Goal: all user stories get a business value estimate written in the top right-hand corner of the user story card.
Exercise: Estimating Effort 20 minutes. Goal: estimate 3 user stories using the Planning Game. Use the Bucket System to estimate the remainder with the ones already estimated as the reference points.
Lecture: Ordering a Product Backlog Review ROI as a method to order the PBIs. Reminder that the Product Owner has final authority and can ignore the estimates in deciding on the order.
Exercise: Calculating ROI and Ordering 5 minutes. Just simple divide-and-conquer calculations of business value divided by effort for all the user stories.
Lecture: Simulation Wrap-Up – Where Does This Fit? Reminder of the idea of creating an initial Product Backlog that is “good enough” to start the first Sprint.
NOTE: Permission to use the Product Owner Simulation exercise and print associated materials is granted with a simple request: please link to this page on your blog, in a LinkedIn group or Google group, like it on Facebook etc. or write a comment in our comments section!
If you are interested in experiencing this Product Owner Simulation first-hand, please consider attending one of our Certified Scrum Product Owner learning events.
One of our big plans this summer is to have a selection of advanced Scrum and Agile – related training courses. We are delivering some of them ourselves, but we are also bring in outside experts for others.
Here is the course list at a high level:
– a 1-day “Advanced ScrumMaster” course
– a 1-day “Advanced Product Owner” course
– a 1-day “Managing for Success” course
– a 1-day “Enterprise Agile” course
– a 2-day “Agile Engineering Practices” course
– a 2-day “Agile Coach Training” course
Our schedule for these events will be finalized in the next few weeks. If you are interested in any of these courses, please pre-register here. Pre-registration will give you a guaranteed spot and a discount of 10% above and beyond the early-bird registration price.
Recently, in my work helping teams to learn and implement Scrum, I have deliberately not been using diagrams. Having participants create their own ways of describing Scrum based on their own understanding is often a much more powerful approach to learning than showing them a diagram. If you give someone a map, they tend to assume that all of the exploring has already been done. If you give them a space to explore, they tend to create their own maps and provide new knowledge about the space being explored. Maps and diagrams do serve a purpose. They are useful. What’s important to always keep in mind is that they should not be regarded as definitive but rather as one contribution to a body of knowledge that can and should grow.
Anyhow, this isn’t intended to be a blog post about diagrams but rather as a post sharing a diagram that I have created. One of the participants of a Scrum training that I recently facilitated asked me for a diagram and I said I would find one for him. All of the other diagrams out there that I could find didn’t exactly convey my own understanding of Scrum. So, I decided to create my own.
This is the first increment. I am open to feedback and I look forward to finding out how this interacts with others’ understanding of Scrum.
The Product burndown chart tracks the amount of work remaining in the Product Backlog Sprint-by-Sprint. This burndown chart is updated every Sprint and is visible to the Scrum Team and its stakeholders. This activity is part of the Product Owners duty to facilitate transparency around value delivered over time. The Product Owner is responsible for making the overall progress of the work visible to the Scrum Team and other stakeholders. This activity is part of the Product Owners job to satisfy stakeholders as it allows them to easily see how the Scrum Team is trending on planned deliverables. This information allows the team and the Product Owner to discuss any necessary adjustments to the team’s plans for the upcoming Sprints in a timely fashion. What happens if the Product Owner fails to create and/or maintain the team’s Product burndown chart? Most likely we will be unable to see if the team is on track, late or early in its delivery of value. In a traditional waterfall approach we would find out this information near the end of the project which is much too late. Also, without regular updates on the trend of the team it is highly probable that stakeholders and/or team members may slip back into an individualistic approach to work instead a team based approach.
The Product Owner has complete authority over the ordering of the Product Backlog. However, it is strongly recommended that the Product Owner put all known defects at the top of the Product Backlog so that the Team fixes them in the very next Sprint. By defects is meant features of functions of the system that have been built by the Team in previous Sprints where those features or functions do not behave according to the expectations of the Product Owner and where such mis-behavior is exposed to users of the system. There may be other quality problems with a system which are not categorized as defects (e.g. duplicated code). This prioritization of defects generally results in extremely high levels of quality in a system and a long-term reduction in costs for the system (total cost of the system) by making future features easier to add, and reducing effort spent on maintenance and support. Failing to put defects on the top of the Product Backlog generally leads to decreasing overall quality and in particular can severely damage the morale of a Scrum Team thus preventing them from getting into a high-performance state.
The Product Owner is involved with the other Team Members throughout the Sprint, but after the Sprint Planning meeting is completed, the Product Owner cannot add to the scope of the work being done during the Sprint. New Product Backlog Items, no matter how high their priority, must be put onto the Product Backlog for the team to look at in the next Sprint. This restriction is meant to allow the team to truly be focused and committed to the work of the Sprint and to allow them to make commitments and learn to keep them, thereby building trust. The Product Owner can, of course, collaborate on the details of the PBIs the team has chosen for the Sprint. If the Product Owner does indeed force a team to take on extra work during the Sprint, it breaks the focus of the team and can lead to the team’s failure to complete the work they planned.
Solving technical problems is the job of the product developers on the Scrum Team, not the Product Owner. The Product Owner is responsible for the product from a business and user perspective and has authority over the team only in this limited realm. By overstepping the bounds of authority in this way, the Product Owner becomes an obstacle for the team by reducing its ability to self-organize. A Product Owner who is part of a team that has reached a high-performance state may be able to safely make technical suggestions, but should always be careful not to push the team to accept those suggestions.
The Product Owner’s main responsibility is to maintain the Product Backlog through direct communication with the users and stakeholders. To do this well it will take most of his time and effort to be effective. Hands-on technical is done by the Team Members not the Product Owner since this is not the Product Owner’s strength or area of expertise. If the Product Owner refrains from doing the hands-on technical work, then he is able to provide the vision and share the “what” that the team needs to accomplish. If not, he will be bogged down by the tasks and lose the time and ability to provide product guidance and connect with the stakeholders.
The Product Owner needs to be highly available to the Scrum Team. If the Scrum Team has a question about a Product Backlog Item, then the Product Owner should be able to respond within minutes to that question. Responding this quickly ensures that the Team is building the Product in a way that best satisfies the Product Owner. In particular, it helps to avoid surprises about basic aspects of the Product during the Sprint Review Meeting that then lead to wasteful changes or re-work. If the Product Owner does not have this level of availability, it may not cause any immediate problems, particularly if there are other team members who know the business and the product well. However, since Scrum holds the Product Owner accountable for what is built, it is often better for the Team to check its assumptions with the Product Owner.
The Product Owner is responsible for the Return on Investment (ROI) of the Product. In order to manage that responsibility, the Product Owner needs to estimate how much financial benefit the Product Backlog Items for a specific Sprint will generate, and compare that to the effort of one Sprint’s worth of the Scrum Team’s labor. This calculation then allows the Product Owner to decide if a given Sprint is worth doing or if the Scrum Team should turn its attention to other work… possibly even a different product. If the Product Owner has these estimates, then it is possible for the Product Owner to maximize the ROI of the Scrum Team. When these estimates are missing, it is difficult to ensure that the Scrum Team is working on the best possible PBIs. In the worst case, the Product Owner will spend the Team’s time working on very low ROI items and cause substantial problems for the business.
The Product Owner has the sole authority on putting the work of the Scrum Team at the end of a Sprint into the hands of users. This means that at the end of a Sprint, after the Sprint Review has occurred, the Product Owner considers the state of the Product (features, quality, performance, etc.) and the state of the business/market, and decides if the product should be sent out. In an IT or web environment, this means deployment. For other types of software this might be live updates or sending out DVDs to customers. There should be no other individuals who have the authority to do extra releases without the Product Owners approval, nor should there be anyone who can stop a release from going out if the Product Owner makes that decision. If the Product Owner has this authority, it can create a high level of efficiency in addressing the needs of the business or the needs of the market. If the Product Owner does not have this authority, then it undermines their authority over the ordering of the Product Backlog (since that ordering becomes meaningless) and it undermines the broader organization’s ability to hold the Product Owner accountable for results.
The team may look at a product backlog item or a user story and say “O gosh! There’s a lot there to think about! We have to build this fully-architected infrastructure before we can implement that story.” This is old waterfall thinking. It is bad. The team should always be thinking (and doing) 
