http://www.romanpichler.com/blog/roles/scaling-the-product-owner/ Roman Pichler's Thoughts on Agile Product Management Tue, 31 Jan 2012 22:03:50 +0000 hourly 1 http://wordpress.org/?v=3.2.1 http://www.romanpichler.com/blog/roles/scaling-the-product-owner/#comment-2042 Product Owner issues | Agile Management Sun, 04 Sep 2011 18:32:45 +0000 http://www.romanpichler.com/blog/?p=21#comment-2042 [...] from delegation (but also negative in situations that have been unclear). See for example Roman Pichler’s advice on Scaling the Product Owner. Sometimes I believe that a split into business-facing and team-facing Product Owners is another [...] [...] from delegation (but also negative in situations that have been unclear). See for example Roman Pichler’s advice on Scaling the Product Owner. Sometimes I believe that a split into business-facing and team-facing Product Owners is another [...]

]]> http://www.romanpichler.com/blog/roles/scaling-the-product-owner/#comment-1995 The Product Owner Role Wed, 22 Jun 2011 07:40:21 +0000 http://www.romanpichler.com/blog/?p=21#comment-1995 [...] the product owner role Scaling the product owner Avoiding common product owner mistakes Desirable characteristics of a product owner Product owner = [...] [...] the product owner role Scaling the product owner Avoiding common product owner mistakes Desirable characteristics of a product owner Product owner = [...]

]]> http://www.romanpichler.com/blog/roles/scaling-the-product-owner/#comment-39 Jutta Eckstein Thu, 11 Feb 2010 14:44:20 +0000 http://www.romanpichler.com/blog/?p=21#comment-39 Hi Roman, I agree completely with all you're saying. This is exactly how we've scaled the role of the product owner in several large projects. I have only one remark - I would only cautiously suggest 1 product owner can support up to 2 feature teams, because of one of the common product owner mistakes which is the risk of the overworked product owner. (see: http://www.romanpichler.com/blog/2010/02/avoiding-common-product-owner-mistake/) Jutta Hi Roman,
I agree completely with all you’re saying. This is exactly how we’ve scaled the role of the product owner in several large projects. I have only one remark – I would only cautiously suggest 1 product owner can support up to 2 feature teams, because of one of the common product owner mistakes which is the risk of the overworked product owner. (see: http://www.romanpichler.com/blog/2010/02/avoiding-common-product-owner-mistake/)
Jutta

]]> http://www.romanpichler.com/blog/roles/scaling-the-product-owner/#comment-28 Avoiding Common Product Owner Mistakes « All Things Product Owner - Roman Pichler's Thoughts on Agile Product Management and Product Ownership Mon, 01 Feb 2010 07:38:22 +0000 http://www.romanpichler.com/blog/?p=21#comment-28 [...] decision making, including product backlog prioritization and release planning as my post “Scaling the Product Owner” [...] [...] decision making, including product backlog prioritization and release planning as my post “Scaling the Product Owner” [...]

]]> http://www.romanpichler.com/blog/roles/scaling-the-product-owner/#comment-27 Roman Pichler Wed, 27 Jan 2010 07:14:05 +0000 http://www.romanpichler.com/blog/?p=21#comment-27 Hi Geoff, A shared product vision is certainly particularly important on a large Scrum project to help everyone move in the same direction. I also recommend using one product backlog, as the product owners and teams collaborate to create or update one product. To succeed with a large-scale development effort, specific practices have to be applied. These include extending the product backlog grooming horizon to two to three sprints, employing lookahead planning to anticipate and resolve dependencies between the teams, running Scrums of Scrums to facilitate the communication between the teams, and enabling joint sprint reviews and retrospectives to foster a sense of unity and project-wide learning. Regarding the project organisation, I favour feature teams over component teams. (The former implement a theme or set of user stories; the latter build a subsystem or component.) With feature teams, the product owners are responsible for pieces of functionality such as "Entertainment" or "Chess" with the chief product owner looking after the entire product. Hi Geoff, A shared product vision is certainly particularly important on a large Scrum project to help everyone move in the same direction. I also recommend using one product backlog, as the product owners and teams collaborate to create or update one product. To succeed with a large-scale development effort, specific practices have to be applied. These include extending the product backlog grooming horizon to two to three sprints, employing lookahead planning to anticipate and resolve dependencies between the teams, running Scrums of Scrums to facilitate the communication between the teams, and enabling joint sprint reviews and retrospectives to foster a sense of unity and project-wide learning. Regarding the project organisation, I favour feature teams over component teams. (The former implement a theme or set of user stories; the latter build a subsystem or component.) With feature teams, the product owners are responsible for pieces of functionality such as “Entertainment” or “Chess” with the chief product owner looking after the entire product.

]]>