Agile Zone is brought to you in partnership with:

Mike is a certified PMP project manager and a certified ScrumMaster. Mike was involved with the creation of the DSDM Agile Project Leader certification, holds this certification at the Foundation, Practitioner, and Examiner levels. Mike was named an honorary member of the DSDM consortium and served on the board of APLN and the Lean Software and Systems Consortium. He currently co-leads the PMI Agile Community of Practice. Mike is a DZone MVB and is not an employee of DZone and has posted 148 posts at DZone. You can read more from them at their website. View Full User Profile

The Product Owner at Scale

  • submit to reddit
Okay... everyone caught up now?

It was kind of neat to spend the time yesterday going back over all those old posts and interesting to see how the process of writing this out has shaped how I look at the whole Product Owner and scaling issue. The timing of the Scrum Gathering was good too. It was nice to get down to Orlando and talk to folks about how they are applying this stuff out in the field.

Last time around I said that the Product Owner at scale was really an issue of Product Ownership in the enterprise. How are we going to get all our teams working on the right things so we end up with a cohesive and integrated product? The key to having this conversation at an enterprise level is to have a thorough discussion around how we are going to handle the three key enterprise Scrum teams: the design scrum... the development scrum... and the QA scrum.

Product Ownership becomes a matter of deciding how to identify all the backlog items, at the beginning of the project, so we can effectively assign work and make sure the entire scope of the project is accounted for.

The role of the Product Owner... or the Product Owner Team is to break each backlog item into a design story... a development story.. and a test story. This is critical for normalizing the input to the team and making sure that each team has plenty of backlog items to work on... and most importantly... the right backlog items to work on... in the right predetermined order!

I mean... how can you write software before you have created the specification? At some point this becomes just common sense!

That said... because of the nature of Scrum at enterprise scale, some teams will inevitably have less to do at certain times in the project.

It was really cool to hear Ken Schwaber (during his keynote at the Gathering) finally discuss that to effectively scale Scrum, we need to put more definition around how to matrix people and teams across multiple projects. Ken's point was that multiple project assignments and matrixed management is the only way to normalize velocity in an enterprise Scrum implementation.

Next post we'll talk about the other mission critical teams that enable enterprise Scrum. We'll talk about the BUFD scrum team... the Governance scrum team... the PMO scrum team... and the centralized process improvement scrum team. We'll introduce some key tooling concepts like the Scrum Market Requirements Document and the Enterprise Scrum Gantt Chart.

Remember... if you do a daily stand-up and call requirements backlog items... you are probably doing Scrum! See you guys on the 2nd.
Published at DZone with permission of Mike Cottmeyer, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Mike Cottmeyer replied on Wed, 2009/04/22 - 11:03am

This was totally intended to be an April fools joke. Clearly.. I was not clear enough and many people have misunderstood this post.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.