Product Backlog and the tea leaves effect (a message to Product Owners)

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.

Having explained Product Backlog and the Tea Leaves Effect in the past, I have now summarized it in a short movie. It takes less than 2 minutes of your time. Enjoy!

Product Owner, actually owns the product

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.

Promoting Professional Scrum (in Ukraine)

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. 

De Product Owner, mag het wat meer zijn (dan functioneel beheerder)?

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.

ScrumAnd - Product Owner

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 paradigma-overgang

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”

“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.

In my book “Scrum – A Pocket Guide” it is summarized as follows:

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.

Product Owner role summary

What does a Product Owner do?

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.

ScrumAnd - Product Owner