At some occasions we stop to look back. We see the trail we left behind, the bigger picture, the impact we made. Small or big. We think of the impact we hoped to make, small or big. A humbling experience before making our way forward again.
Early 2011, nearly five years ago, Scrum.org launched the Professional Scrum Product Owner course. In a blog note titled “Product Owners, not proxies” Ken Schwaber summarized the reasons for creating the course, its purpose, the improvement envisioned.
Too often ‘Product Owner’ was just seen as the new name for requirements engineer, someone responsible for collecting and writing down all requirements, and handing them over to software engineers. Only, User Stories replaced use cases. Index cards (or sticky notes) replaced paper documents. But vast amounts of energy were still spent on collecting all possible stories, and documenting all details. The traditional ‘analysis paralysis’ phenomenon was replaced by a ‘story card hell’ .
At the same time, the old barriers between product management and IT remained. Product management was kept at a distance from the actual development. They were still only remotely involved. Valuable information regarding users, consumers and stakeholders was lost, and remained unused while the actual products were being created and sustained.
Few implementations of product ownership evolved in a way that the full potential of Scrum was unleashed to the teams and organizations employing Scrum.
The Professional Scrum Product Owner course, by design, focused much on bringing Agile thinking to product management, to finally bridge the gap, increase their much needed involvement. The PSPO course introduced insights, options and ideas on how to be agile, value driven, and opportunistic – not how to be distant and merely write User Stories.
Through our Professional Scrum Trainer community, and the feedback on our Professional Scrum Product Owner courses and assessments we see a growing and genuine interest in the role of the Product Owner. We observe the increased understanding of Scrum as a framework to manage complex products, over seeing it as a new project management approach. We see organisations fitting Scrum into their product management. We see Product Owners working towards becoming a mini-CEO (of their product), while working with self-organizing Development Teams to incrementally maximize product value through Done Increments.
Requirements, expectations, hopes, desires, scope still require to be managed though. Product Owners work with stakeholders and Development Teams to create Product Backlog, while remaining accountable for managing all work against an overarching product vision. Yet, all may feel overwhelmed by the steady increase of techniques and practices in this area. In many cases these are perceived or presented as stand-alone techniques. The bigger picture is missing. How do these techniques and practices match sustaining Product Backlog? How do they fit iterative-incremental development? Where does development come in?
Many of these approaches require their own artifacts, yet they cannot replace Product Backlog. Scrum thrives on transparency. Product Backlog upholds transparency over all work for developing and sustaining a product.