Product Backlog is a strategic instrument of high value; for stakeholders, product management, the organization, the Development Team(s), and the Product Owner. When employed well, Product Backlog reflects the vision, ambitions, roadmap, needs and wants for a product or a service, all in one place. Imagine how your competitors would love to have access to it!
Product Backlog has the potential, as a single artefact, to replace a multitude of other predictive plans and traditional documents. In Scrum, Product Backlog is all the plan you need. For Product Backlog to enhance simplicity and transparency, Product Owners maintain Product Backlog continuously. The Product Owner, actually owning the product, orders and manages it to reflect the actual needs, wants and ambitions.
Product Owners likely apply multiple hands-on strategies to keep Product Backlog tidy and accurate. It helps for many Product Owners to realize how the tea leaves on a Product Backlog impact transparency.
The description of a Product Owner’s work reads as no existing job summary. “Product Owner” is not just a new name for the old roles and titles originating in the industrial beliefs that dominated businesses and society far too long.
Our dependence on software and technology keeps accelerating. We live and work not only in a globalized but also in a digitized age where technology, knowledge and the availability of information prevail more than ever, through a variety of technology products more than ever. Product Owner is a new, modern role, that fits that new world.
Product Owner, within an organization, actually owns the product, is a product-CEO. Product Owner is the many-faceted servant-leader in an eco-system revolving around the product, an eco-system that stretches beyond the borders of the organisation that creates the product. Product Owner is a strategic role, that is still ignored too much.
In March 2017 I enjoyed being in Kyiv (Ukraine) to open the first Scrum Day Ukraine, introducing “re-vers-ify“.
I am continuing to support my local friends of Scrum, Slava Moskalenko and Bogdan Misyura (Brain Rain UA) in promoting Professional Scrum in their region. On 27-28 April we organise a Professional Scrum Product Owner class in Kyiv. Join if you want to explore the diverse aspects of product ownership in Scrum!
With ‘Professional Scrum‘ we promote the use of Scrum beyond the mere following of the formal ceremonies (‘mechanical Scrum’), but employing Scrum from an understanding of the underlying values and principles. In our Professional Scrum workshops we follow the difficult path of helping people explore how to build on the empiricism of Scrum, the intelligence of people and the Scrum Values, to tackle difficult and complex challenges. The easy path would be to be instructors, treat attendants as mindless robots and give people easy black/white solutions.
Please find herewith a short movie in which I introduce the Product owner role of the Scrum framework.
It is in Dutch with English subtitles. It was created for Xebia with the Xebia marketing wizzy Ted Stravers, and recorded and processed by Higher View:
Alle werk in Scrum wordt georganiseerd in Sprints en wordt gerealiseerd door Scrum Teams. Sprints zijn 4 weken, en vaak korter. Een Scrum Team heeft alle aansprakelijkheden noodzakelijk voor een goede uitvoering van productontwikkeling in zich, verspreid over 3 rollen:
Het Development Team organiseert alle werk om binnen het tijdsbestek van een Sprint, volgens de prioriteiten van de Product Owner, productiewaardige software te creëren.
De Product Owner beheert de Product Backlog, de enige bron van invoer voor de ontwikkelactiviteiten, en het budget van de ontwikkeling.
De Scrum Master bewaakt, promoot en faciliteert het Scrum-proces, en verwijdert alle (vaak organisatorische) Impediments (blokkeringen) die het team in de weg staan.
Jawel, je past Scrum toe als deze rollen, en alle andere regels van Scrum, worden gevolgd en gerespecteerd. Maar dat is niet meer dan een noodzakelijk begin. De uiteindelijke resultaten die je door Scrum behaalt, zijn vooral afhankelijk van de wijze waarop je de rollen en de regels toepast.
Scrum en de rol van de Product Owner.
Scrum wordt vaak ingevoerd vanuit de IT-tak van organisaties. Scrum wordt daarbij aanzien als het nieuwe IT-proces, het proces volgens hetwelke software wordt opgeleverd naar ‘de’ Business. Scrum schrijft voor dat er een Product Owner moet zijn, en een oppervlakkige lezing van de rol doet mensen overhaast besluiten dat dit wel de nieuwe benaming moet zijn voor de zogenaamde business analist. Een zucht van opluchting aangezien dit een bestaande rol binnen de IT-organisatie is. Merk op hoe het denken wordt bepaald door de historische tweedeling IT versus Business.
Organisaties gaan op deze wijze met Scrum aan de slag, maar stellen vast dat deze invulling van de Scrum-rol van Product Owner toch niet de verhoopte resultaten oplevert. De beslissingsbevoegdheid van de business analist is namelijk beperkt. Nog beperkter zijn de inzichten in de leefwereld van de Business. De analist moet nogal vaak in de richting van de projectmanager kijken voor beslissingen, of de stuurgroep, of is afhankelijk van andere instanties die extern zijn aan het Scrum Team. Het Development Team moet geregeld het werk onderbreken, stopzetten, ander werk tijdelijk oppikken, enz. Geen flow, geen waarde.
Dat was zelfs in de klassieke aanpak al een gekend probleem. Vaak werden daarom aan de grens van IT, maar duidelijk binnen IT, reeds aparte afdelingen opgericht om een brugfunctie richting ‘de’ Business te vormen. Vervolgens worden mensen uit deze afdeling gerekruteerd om de Product Owner-rol op zich te nemen en requirements te verzamelen en aan het Developent Team door te geven. De Product Owner-rol krijgt zo een proxy-invulling, wordt een tussenpersoon. De kloof met de echte beslissingscentra wordt iets kleiner, maar IT wil niet verder gaan wegens het behoud van controle over de rol. De wachttijden voor beslissingen en bijsturingen worden kleiner, de start-stop-situaties nemen licht af. Maar het blijft een moeilijke, want lange-afstandsrelatie.
We zien vaak dat in deze situatie de Business ook inzicht krijgt in het gevolgde proces, Scrum, en de rol van de Product Owner. Terecht groeit de behoefte om deze rol zelf op te nemen. De Business eist de rol op! Functionele, klant- en marktinzichten komen zo sneller tot bij het Development Team, en zorgen ervoor dat er meer focus is op het juiste product bouwen, en niet enkel een product op de juiste wijze bouwen. Echter, de afgevaardigde Business-persoon heeft niet steeds een breed mandaat.
De voordelen die met Scrum worden gerealiseerd worden nog groter als dergelijk mandaat en het bijhorende vertrouwen wel gegeven worden. Het is tevens een signaal dat de Business de rol ernstig neemt, het belang ervan inziet. Scrum ontstijgt de perceptie van het nieuwe IT-proces, en wordt een middel voor business agility, een instrument dat de organisatie toestaat sneller in te spelen op verandering, om sneller nieuwe, zakelijke kansen te ontdekken. Scrum wordt een tool die de organisatie holistisch helpt om business-, markt- en gebruikersnoden sneller en beter in te vullen.
De ultieme invulling van de rol is deze van de ‘mini-CEO’. ‘Mini-CEO’ is een metafoor die aangeeft dat er binnen de Business een persoon is die als een echte eigenaar van het product fungeert. Deze Product Owner heeft de volle bevoegdheid over het product, zowel budgettair als inhoudelijk. Deze persoon beschikt over alle contacten binnen de nodige departementen om het product vanuit een 360° perspectief te beheren; marketing, marktonderzoek, gebruikers, wettelijk, financieel. Deze persoon wijdt haar/zijn professioneel leven 100% aan het product, de ontwikkeling, groei en evolutie ervan.
De Product Owner, een functioneel beheerder?
Naarmate het inzicht van bedrijven in Scrum groeit, groeit ook de nood om te ontleren, om oude gewoontes en inzichten radicaal te bannen, en te vervangen door Agile inzichten.
De rol van ‘Functioneel Beheerder’ is geworteld in het oude denken. De opzet en het takenpakket van de Functioneel Beheerder zijn perfect. Op papier. In de praktijk werkt het niet. Te veel voorschriften, te veel detaillistische overhead, te methodologisch. Het voegt te veel zwaarte toe aan Scrum, legt zwaarwegende constructies op Scrum. Scrum is licht. Dat is de kracht van Scrum. Scrum bestaat uit een set minimale voorschriften. De rol van de Product Owner houdt engagement in, betrokkenheid, waarde-gedreven gedrag. Laat ons de schoonheid van deze nieuwe rol niet ten onder doen gaan in een aanpak die geworteld is in het oude, industriële paradigma.
Ik vrees dat het geloof dat de Product Owner-rol de aangewezen functie is voor de functioneel beheerder, behalve in de menselijke drang naar job-, status- en titelbehoud, geworteld is in de misvatting dat in Scrum de hoofdverantwoordelijkheid van de Product Owner de aanlevering is van uitgeschreven requirements. Echter, de Product Owner is in eerste instantie aansprakelijk voor het bestaan van een Product Backlog, en voor de sortering van alle items op de Product Backlog. Intelligente Product Owners doen voor het uitschrijven van de items een beroep op business-inzichten binnen het Development Team, bvb. via de skills die een business analist, of -wie weet- een functioneel beheerder, toevoegt aan het team.
Scrum zet het product centraal.
Scrum maakt abstractie van interne structuren en departementen. Scrum kent geen tweedeling Business-IT. Scrum zet het product centraal, en de waardeverhoging die via het product gerealiseerd wordt, zowel voor de organisatie als voor haar klanten, gebruikers en consumenten. Dit vereist intense en nauwe samen-werking tussen de rollen voor productontwikkeling die Scrum beschrijft. Gun het jezelf om alle voordelen te halen uit je keuze voor Scrum. Leg net dat beetje meer ambitie in je toepassing van Scrum dan enkel de termen van Scrum te gebruiken als de nieuwe verpakking voor een oude aanpak.
Laat de Product Owner vooral een echte producteigenaar zijn. Daar is de rol uiteindelijk ook voor bedoeld.
In 2013 publiceerde ik mijn boek “Scrum – A Pocket Guide (A Smart Travel Companion)”. Vanuit mijn werk bij Scrum.org heb ik een goed beeld van de mondiale verspreiding van Scrum. Het doet me plezier vast te stellen dat Nederland wereldwijd (!) koploper is qua invoering van Scrum. Dankzij de vele mensen, teams en organisaties waarmee ik mocht werken sinds 2010 is Nederland zowat mijn thuisland qua Scrum geworden. Het is een belangrijke drijfveer geweest om mijn boek te vertalen naar het Nederlands, zodat dit in 2016 nog beschikbaar kan zijn voor mijn feitelijke thuis (België) en mijn Scrum-thuis (Nederland).
“Accepting the work product” is a respectable expectation for a Product Owner. It sounds off and scary but I should add it to my Product Owner role summary.
In a worldview rooted and drenched in hand-overs, separation and blame, anything related to ‘acceptance’ triggers negative sentiments. It brings back memories of rejection. We recall the resentment we felt every time we were blamed for the past and for past actions taken without any room left or given to remediate.
In the iterative-incremental continuum however there is only one way, and that is FORWARD. GO!
The Product Owner identifies and expresses the hopes and desires for the currently most important work. The Development Team acts on these hopes and desires and creates a Done Increment in no more than 30 days, and often faster. The Product Owner accepts the resultant work product against the ultimate goal to discover what is most important to do next with the key stakeholders present.
The collaborative Sprint Review provides the Product Owner with the best possible information on which to decide whether the Product will be shipped, and how additional Sprints can further improve the value of the product taking into account a balance of risk, effort, budget and cohesion. (p. 53, chapter 2.5.2 “Time”)
There is no absolute guarantee that reception of the presented work product makes a happy Product Owner. However, a Product Owner not being happy with the work product is not the same as the Product Owner rejecting the work product. There is no rejection. There is but one way, forward. Go!
Looking forward the Product Owner might:
Not release the Increment
Update Product Backlog to better reflect his/her intents
Have the work re-done via an updated Product Backlog
Decide to increase her/his participation in the creation process
Look to increase business skills in the Development Team
I sure hope the Product Owner keeps in mind a close collaboration with the Development Team, as summarized in my book “Scrum – A Pocket Guide“:
Although a Product Owner may have various strategic product management tasks outside of the Scrum Team, it is important that the Product Owner actively engages with the other players of the team regularly and repeatedly. (p. 48, chapter 2.5.1 “Players and accountabilities”)
And, eventually, a Product Owner might not fund a next Sprint or release.
The Product Owner brings the business perspective to the software product being created and sustained into a Scrum Team. The Product Owner represents all stakeholders, internal and external, to the Development Team. Although a Product Owner is likely to have various strategic product management tasks outside of the Scrum Team, it is important that the Product Owner actively engages with the Development Team regularly and repeatedly.
The Product Owner assures with the Development Team that a Product Backlog exists. The Product Owner manages Product Backlog based on the product vision as a long-term view of the road ahead. A product vision captures why the product is being built.
Product Backlog shows all of the work currently envisioned for the product. This work may comprise initiatives, functional and non-functional expectations, enhancements, fixes, patches, ideas, updates and other desirements. If anybody wants to know what work is identified and planned for the product it suffices looking at the Product Backlog.
The Product Owner expresses the expectations and ideas captured in the Product Backlog to the Development Team, and orders the items in the Product Backlog to optimize the value being delivered. Lower value items are actively removed from Product Backlog (see the Tea Leaves Effect). Lower value functionality is actively removed from the product.
The Product Owner invites stakeholders to the Sprint Review to come work with the Scrum Team; what got done, what didn’t got done, what are relevant market or competition trends. The goal is to collaboratively identify what is the most valuable work to do next for the Product. This is captured in Product Backlog. Obviously.
The Product Owner manages the product budget to balance value, effort and time for the represented stakeholders. The Product Owner maximizes value. Period.
What does it take to be a Product Owner?
Being a Product Owner requires specific skills and traits. There are too many to mention, but an entrepreneurial spirit is certainly a helpful one. Being a Product Owner requires ownership of a product, implying strong organizational adoption of the role. Being a Product Owner is being a servant-leader in working with self-organizing teams. Being a Product Owner is not easy. It may take some time to get there.
A vast majority of software development work concerns new product development. Every software product is essentially unique. We create previously non-existing products, suites, integrations and product extensions. We never create the same product twice. We expand existing products into the new product area. Competition, market expectations and technologies move so fast that acquired concepts, practices and approaches are outdated by the time they become well adopted, forcing us de facto into new product development anyhow.
Software development, as new product development through and in complex conditions, requires a startup mindset, no matter the size or age of the product or the master company. The Product Owner, as promoted in the Scrum framework, becomes an Agile Product Manager, the product’s president, its mini-CEO, an entrepreneur. The rise in complexity and uncertainty renders big plans into meaningless waste. The Product Owner drives iterative development from an exploratory attitude, aiming at incremental progress through continuing discovery and validated learning.
Every Sprint has a Sprint Goal as next horizon to work against. The Sprint Goal describes a (business) challenge, from an assumption of (market) value for the (Increment of) product. The outcome of a Sprint provides an important learning option. But the learning is only meaningful when it can be assessed against the product’s external impact and adoption; in affirming or negating the assumption of value underlying the Sprint Goal. The goal of the learning is to find out whether an opportunity is real, whether there is an audience willing to use the product, whether the audience appreciates the delivered functions.
In the absence of a release, value remains an obscure assumption. It is a major unknown and a risk for further investments. The unknown remains unresolved, and the risk is out of control, until the product is brought to market; be it a contained market segment, be it a limited or the full user base. With every Sprint without an actual release, the risk increases exponentially that the Product Owner runs out of tune with the evolving market and is wasting money, time and creativity. Increments of product, seemingly incomplete but offering minimal usable feature sets, provide the foundation for validated learning. Users need it to provide the Product Owner with feedback on the actual value of the performed work, the base to decide on the best future direction of the product. No document, design, paper document or simulation provides the same, high level of validation. Without that ultimate validation no informed decision over strategies or tactics can be taken, not in the least the decision whether to continue on the chosen path or to change direction.
Learning requires not only goals and feedback loops, but also measurements and data to support the validation process. Evidence of value is needed to confirm or contradict the assumptions. Evidence-Based Management can guide the entrepreneur and the stakeholders in their investment decisions.
Scrum can be at the heart of such entrepreneurship. Scrum frames the creativity of people to better deal with complexity and uncertainty. The empirical foundation of Scrum is a structured way to steer experimentation and discovery through frequent validation. In a situation where uncertainty is too big to plan, it is a way to make real progress; progress that is founded in reality, not in plannified imagination.
Seeing the Product Owner in Scrum merely as a requirements engineer, a requirements provider or someone to prioritize a preset Product Backlog is unlikely to help organizations capitalize on the entrepreneurial potential of Scrum. Seeing Scrum as a goal in itself results in gazing at internal performance, volume (of features, of hours, of points) and productivity (velocity or derivatives). Scrum is designed as a mean, a mean to maximize the value of software; value to the market and value to the organization and its people. Scrum is designed to make progress, grow and prosper trough validated, incremental learning. The Product Owner, the owner of the product, takes up the essential role of entrepreneur.
In today’s complex and unpredictable world, Scrum can be the engine of innovation and exploration. It is a choice though. It is your call on how you want to use Scrum.
Product Backlog is a strategic instrument of high value; for stakeholders, product management, the organization, the Development Team(s), and the Product Owner. When employed well, Product Backlog reflects the vision, ambitions, roadmap, needs and wants for a product or a service, all in one place. Imagine how your competitors would love to have access to it!
Product Owners likely apply multiple hands-on strategies to keep Product Backlog tidy and accurate. It helps for many Product Owners to realize how the tea leaves on a Product Backlog impact transparency.
