Agile Product Ownership in a Nutshell
Why Project Management Stack Exchange recommends it
Project Management Stack Exchange answerers point people to it as a quick, clear explanation of the Product Owner role and as a visual guide to release forecasting with burn charts and uncertainty.
Recommended by 7 people across 12 different months, 2014 to 2018.
What it is
A 16-minute animated whiteboard-style talk by Henrik Kniberg that compresses a one-day product ownership course into a high-level overview. It covers the Product Owner role, prioritising the backlog, saying no to low-value features, and using burn-up charts with optimistic and pessimistic lines to forecast release dates.
What people said
Strong rec leenasn · 2014-12 · Project Management Stack Exchange · on “Can the product owner remove user stories?”
The best explanation for Product Owner can be found in the below video, which talks about how to do planning and prioritizing of stories. A must watch for every. [this video] The summary of the video is: PO knows the vision of the product, why the product is being built and whats the problem domain Knows the stakeholders and/or the end users Is the communicator between the Stakeholders, users and the team So in summary, PO works with the team to "build the right thing" which means: The most important tool at his disposal is the ability to say "No" to feature requests that won't provide value and "put them in the trash bin". Prioritises the Product Backlog by balancing the following risks: Cost an
Strong rec Joel Bancroft-Connors · 2016-01 · Project Management Stack Exchange · on “Optimistic vs. Pessimistic Burndown Lines - just a Project smell?”
There is a great video [this video] that shows how to use variance in trend lines in an agile project. This video is a standard part of my two day Scrum Master training class because Henrik does such an amazing job of giving a total overview of scrum and by doing it from the PO perspective, helps to pull in the most skeptical of students (the product manager). The Optimistic/Pessimistic Burnchart conversation starts about 12:20.
Recommends user3734806 · 2014-06 · Project Management Stack Exchange · on “Product Backlog for Entire Department?”
It sounds as though you might get buy-in from your boss if you make her your Product Owner and give her some more information about what a Product Owner's responsibilities are. Here's a good video that explains product ownership in 15 minutes: [this video] In terms of naming, you can call her your Primary Stakeholder. As someone familiar with Scrum, so you know that a primary responsibility for your Product Owner (Primary Stakeholder) will be the prioritization of the product backlog. Backlog Refining sessions, and sprint planning meetings will give you the opportunity to comment on why you and/or your team might think something else should take priority. This is the opportunity for your team and
Recommends Niels van Reijmersdal · 2014-07 · Project Management Stack Exchange · on “Who decides to add new feature in any project or not and what factors are taken into consideration?”
This greatly depends on the used software development methodology [LINK] , but in all cases there should be a central point to collect new features and a person to schedule a kick off of the process from design till implementation. In the SCRUM [LINK] methodology (a popular agile process framework) there is a role called Product Owner [this video] . This is the person who decides what goes in and what not. He represents the client, defines what the business value is and prioritizes new features. See the great 15 minutes Product Owner in a Nutshell video [this video] . One of the Agile manifesto principles [LINK] is: Simplicity--the art of maximizing the amount of work not done--is essential. So a driv
Recommends tdrury · 2015-08 · Project Management Stack Exchange · on “Is it possible to forecast when a scrum team will complete the product backlog?”
You can plot your teams velocity against the backlog and get optimistic and pessimistic release dates. [LINK] The wavy black line is your team's burn-up line - it fluctuates because velocity often fluctuates. The green line is an estimate of their best burn-up/velocity and red is an estimate of their worst burn-up/velocity. Where they intersect the fixed scope line provides an estimation of the release date. A video explaining this is here [this video] .
Recommends Daniel · 2015-09 · Project Management Stack Exchange · on “Is the Product Owner the Customer?”
The product owner is not the customer. While there might be some specific cases where it can work, that would usually be very problematic. Most notably, the role of the product owner is incredibly demanding and most customer would not dedicate that kind of time. The product owner will usually come from inside of the organization (or as you put it, software company). If you want a great explination of how the product owner interacts with the team and stakeholders (including customers), I'd take a look at Henrik Kniburg's video on youtube about product owners [this video] .
Recommends Daniel · 2015-12 · Project Management Stack Exchange · on “How to make Release Planning more accurate?”
Not surprisingly, I hear that question a lot. The basic problem with the question is that Agile disagrees with the fundamental idea of a fixed-scope/fixed-timeline project. In the question you were asked, there is the assumption that the end date of a set scope is knowable and the problem is that we are bad at knowing it (estimating). That's not really true. The end date of a given scope is not a knowable point in time. Rather, it's a shifting point in time. Improving team capabilities, understanding of user needs, and more sophisticated understanding of the implementation as the project progresses actually moves that date around. Take a look a this Henrik Kniberg video [this video] from 11:25 ->
Recommends Joel Bancroft-Connors · 2017-03 · Project Management Stack Exchange · on “How do I convice clients that we should use Agile and how should we charge for it”
TL:DR: Always use agile, change your reporting, not your contracts. It sounds like the root problem here isn't about using agile nor the kind of contract you use, it's about managing Change Management. Regardless of if you use agile or traditional development techniques any project over roughly a week is going to see changes. You need to help your client understand the costs of change and how this impacts the contract. Using agile development means you have metrics that are usually more accurate and reflective of changes. Even if you use classic velocity based burn downs with best case, worst case (a good example can be found in Henrik Kniberg's Product Owner YouTube video [this video] ) you can
Recommends Daniel · 2017-08 · Project Management Stack Exchange · on “How many developers do we need? How much time?”
I encourage you to look at this video from 11:28 to 14:22 [this video] - also, be careful about assuming that adding developers will make the work get done faster - as the old saying goes "Adding people to a late project makes it later". Adding people can help, but it usually isn't a simple relationship and it needs time before it has a positive effect rather than a negative.
Recommends Daniel · 2018-02 · Project Management Stack Exchange · on “Cone of uncertainty - how could we delay commitment to estimates in real life?”
This video ( [this video] ) has a nice quick and simple explanation about burn-up charts and the role of the cone of uncertainty in them from 11:28 to 14:10.