Posted on 1 Comment

What are you defining as „Done“?

Agility is why most organizations adopt Scrum.

The actual agility an organization achieves is rooted in how sophisticated Scrum is being employed. Beyond the mere adoption of Scrum, enterprise agility is much accelerated if the organization re-emerges its structures around Scrum. With re-vers-ify I remind people that structures need to be re-imagined, rather than predicted or copied, often upon re-imagining Scrum.

Through Scrum, teams and organizations create, deliver, maintain and evolve great products and services. Through Scrum, teams and organizations create the opportunity of potentially releasing a version of product no later than by the end of each Sprint, where a Sprint takes no more than 4 weeks, and often less. This provides an organization with foundational agility, the potential to thrive on its market, while creating a motivating working environment.

The state of an Increment of product by the end of a Sprint is named “Done” in Scrum.

In order for everyone to understand what “Done” means, teams have a definition of Done in place. The definition of Done holds the shared understanding of what it means for work to be complete, and ensures transparency over the completeness of the work.

At several points in time this provides crucial clarity:

  • When forecasting work deemed feasible for a Sprint.
  • When assessing whether work on Product Backlog items and the product Increment is complete.
  • Progress of development throughout a Sprint.
  • When considering the opportunistic value of the product functionality offered in the Increment (not having to turn the inspection into a quality interrogation).

Without a definition of Done, Scrum cannot be applied effectively.

Ideally, a professional organization defines quality requirements to be incorporated into a product. Regardless, Scrum professionals adhere to an appropriate definition of Done. Always. No undone work is part of the Increment. No undone work is put into production. Ever. Meanwhile committed professional teams keep looking for ways to improve product quality as reflected in the definition of Done.

Many teams across the world seem to be unable to create actually releasable Increments of product. Code is entered, and potentially tested, within a team. But the actual Increment remains scattered and hidden in long-lived branches. Or the work delivered at the end of a Sprint still needs to be integrated with fellow product teams. Or -even worse- it is to be shipped to different departments for that purpose. In those cases Scrum reveals important information over critical organisational impediments that prevent the teams from creating actually releasable versions of product. There is a substantial amount of “Undone Time”, the time it takes to go from an undone piece of work to a Done Increment. This time impedes the agility that the organisation desperately needs. It kills the option of opportunistic releases.

The purpose of a Sprint in Scrum is not to just result in a piece of work that can be shipped to another team, functional group or department. An Increment is expected to be in a useable condition, ready for production. When released, nothing breaks. No unpredictable amounts of open work accumulate in the system, waiting to be handled at some unknown point in time, meanwhile corrupting everybody’s understanding of the progress and quality. The actual release decision depends on how useful the product is, a decision that lies with the Product Owner, the sole representative of users and stakeholders to the Development Team(s).

At least an Increment is integrated across teams and systems to have it in a production-deployable state. Most often teams define as “Done” all the development activities (of which in general a lot of testing) to be performed to consider an Increment as “Releasable”.

Imagine however any non-software industry. Can you imagine ‘quality’ being expressed in terms of the machines, tools and practices to be used? Is this not ‘how’ to create quality, but not a definition of quality?

Quality is defined through the characteristics of a product.

Quality is in the qualities that a product should exhibit. A “Done” product in Scrum is not just a product on which rigorously proper development standards were applied, and therefore can be released. A “Done” product is a product that exhibits your organization’s definition of product qualities.

Valuable Increments are at the heart of Scrum, as I already indicated in my book “Scrum – A Pocket Guide” (2013).

Shifting the balance toward creating Valuable Increments is truly enacting Scrum, and living by the highest Agile principle:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software (bold-indication by me).

A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value (bold-indication by me).

So, do you have a definition of Done? If so, what are you defining as “Done”? Is it ‘Releasable’, or ‘Valuable’? Is every Increment you create valuable? Why not? Does your Scrum Master know? Your management? And what are you doing about it?

 

Posted on 1 Comment

The Future Present of Scrum (Are we Done yet?)

Scrum turns 21. Thank YOU!

Scrum was for the first time publicly presented and described in the paper “Scrum Development Process” in 1995. Scrum is turning 21 years old.

It starts and ends with people.

Scrum can only last and prosper -across the globe, across industries- because thousands and thousands of people, organized in teams, departments, organizations, employ Scrum to deal with complexity, to tackle difficult challenges, to create valuable product. Day in, day out. (Depending on the source, 70-90% of all Agile teams worldwide say they use Scrum.)

Regardless of region, organization, culture, or background, every individual has the intrinsic capability to self-organize and thrive by working in the context that Scrum creates. Through people those benefits can be unlocked to wider ecosystems.

Are we Done with Scrum?

Verheyen, Gunther - Scrum - A Pocket Guide (A Smart Travel Companion)In my book “Scrum –  A Pocket Guide” I present 2 major challenges, that will help define the future state of Scrum:

1/ The Power of the Possible Product

From having implemented Scrum for the ‘how’ of product development, adding more focus now to ‘what’ needs to be built is crucial. That shift will help organizations discover the power of the possible product, reduce the amount of product built, instead of merely optimizing the way that the product is being developed. (Scrum – A Pocket Guide, November 2013)

2/ Upstream Adoption

More than about process and techniques, moving from the old, industrial paradigm to the new Agile paradigm is about culture and behavior. The common bottom-up enthusiasm that arises from doing Scrum is unlikely to be sufficient for such transformation. For a lasting effect the common bottom-up enthusiasm needs to be supported and facilitated by upstream adoption.  (Scrum – A Pocket Guide, November 2013)

Besides these ones there are obviously many more challenges related to implementing and adopting Scrum, related to getting more benefits, a higher agility out of Scrum, a higher ability to adapt:

Scrum Challenges

Let alone the secondary-order challenges that many organizations get themselves into with attempts to re-define, wrap, package, and rename Scrum, although the core engine they build upon is still… Scrum.

Scrum, essentially

What if, moving forward, we focus on the essence, the core purpose of Scrum?

If Scrum was to be reduced to one purpose, and one purpose only, that is the creation of a Done Increment in a Sprint. (“Done is a crucial part of Scrum, actually“, May 2015)

Scrum is a tool that supports people, teams, departments and organizations to gain agility; ‘agility’ being the ability to adapt, to change course, to explore unthreaded paths. Agility is not achieved at the insides of an organization. It is validated through external impact.

Hence the purpose of Scrum to create a Done Increment of product, no later than by the end of a Sprint, where a Sprint takes 4 weeks, no longer and often shorter.

Closed Loop Feedback (Scrum)

An Increment in Scrum is not really Done if it can’t potentially increase such impact. An Increment is not Done if it’s not releasable. An Increment in Scrum can be Done before a Sprint expires, but no later.

How Done are you?

Over the past year I started actively inquiring on how many people using Scrum create Done Increments, with “Done” reflecting a state of actually ‘releasable’. From all people and teams saying to be using Scrum, at most 10% indicate their Increments are in a releasable state. And even then the biggest struggle is to maintain this high state of quality Sprint after Sprint after Sprint. I recently heard Jeff Sutherland say his experience says it is certainly no more than 20%.

The crucial questions for every Scrum practitioner are:

  • Do you have a definition of Done?
    • Does your definition of Done reflect releasable?
  • Do you create actually releasable Increments of product?
    • Every Sprint?

Then ask yourself, “What is stopping me?” and take action. Involve your Scrum Master in removing the Impediments that are preventing you from creating releasable Increments of product. Expect your management to be involved as well.

The future present

It is obvious that we are not Done yet with Scrum. We’re not sufficiently employing Scrum to the level that every Sprint, or sooner, we have a Done, releasable Increment of product. This however is the foundation of agility, of empiricism, and the ultimate sense of fulfilment.

The future present of Scrum is the creation of Done Increments. It is an ambition that will get us a long way, if not another 2 decades.

Scrum begins with Done.
Let the next 20 years be about enacting Scrum.

Posted on Leave a comment

My PSM class of May 2020 will be online.

A virtual and integral learning experience.

In April 2020, I facilitated my first PSM course (‘Professional Scrum Master’) in an online mode. Ever. Looking at the feedback received, I needlessly worried over the ability to have some great conversations and interactions:

I was pleasantly surprised with the online setup. It did really work and definitely with the size of our group. It was a job well done!

It was amazing to see how Gunther can tell a story and take you into the wonders of Scrum seamlessly. I read the guid upfront but he made it comprehensible and into one story.

So, that certainly increased our confidence and allow our next Professional Scrum Master course to happen online again. Check your agenda for your availability on 28 and 29 May 2020. Seats are limited. Get in touch via my partner Sugar-Me.

Posted on Leave a comment

Mueve tu Scrum al Centro del Campo (Seis Rasgos Esenciales del Juego)

In my paper “Moving Your Scrum Downfield” I have described the six essential traits of the game of Scrum. They are the traits to make Scrum work, and underly the rules of the game.

Francisco López, aka Paco Cacheda, has kindly translated my paper to Spanish, as “Mueve tu Scrum al Centro del Campo (Seis Rasgos Esenciales del Juego)”. Paco said it helps him to better understand my words. Maybe it does that for other Spanish speaking people too.

How the six essential traits of the game are indicative of Scrum coming to life?

  1. Scrum Is Simple, Yet Sufficient. The players unfold the potential of Scrum by using the simple rules that apply and explore how tactics, interactions, behaviors, and the six essential traits make Scrum work.
  2. Scrum’s DNA. The players form a self-organizing unit around the challenge of collectively creating observable, Done Increments of work, while employing empiricism to manage all work and progress.
  3. Players Demonstrate Accountability. The players contribute to valuable system outcomes through spirited collaboration, and sharing and challenging rules, agreements, skills, practices, ideas, and viewpoints.
  4. Transparency for a Flow of Value. The players use the Scrum artifacts to uphold transparency over all work done and work to be done, manage for a flow of value and preserve the ability to capitalize on unforeseen opportunities.
  5. Closing the Loops. The players regularly and repeatedly close the many intertwined loops within a Sprint toward full closure by the end of a Sprint and preserving unburdened adaptability at the macro level.
  6. The Scrum Values. The Scrum Values of Commitment, Focus, Openness, Respect, and Courage take prominence in the behaviors, relationships, actions, and decisions of the players and their ecosystem.

Cómo los seis rasgos esenciales del juego son indicativos de que Scrum cobra vida:

  1. Scrum es simple, pero suficiente. Los jugadores despliegan el potencial de Scrum usando las simples reglas que se aplican y exploran cómo las tácticas, interacciones, comportamientos y los seis rasgos esenciales hacen que Scrum funcione.
  2. El ADN de Scrum. Los jugadores forman una unidad auto-organizada en torno al desafío de crear colectivamente incrementos de trabajo observables y hechos, mientras emplean el empirismo para manejar todo el trabajo y el progreso.
  3. Los Jugadores Demuestran Responsabilidad. Los jugadores contribuyen a los valiosos resultados del sistema mediante una colaboración enérgica, y compartiendo y desafiando reglas, acuerdos, habilidades, prácticas, ideas y puntos de vista.
  4. Transparencia para un Flujo de Valor. Los jugadores utilizan los artefactos Scrum para mantener la transparencia sobre todo el trabajo realizado y el trabajo por realizar, gestionar un flujo de valor y preservar la capacidad de capitalizar oportunidades imprevistas.
  5. Cerrando los Ciclos. Los jugadores regularmente y repetidamente cierran los muchos ciclos entrelazados dentro de un Sprint hacia el cierre total al final de un Sprint y preservando la capacidad de adaptación sin trabas a nivel macro.
  6. Los Valores de Scrum. Los Valores del Scrum de Compromiso, Enfoque, Franqueza, Respeto y Coraje toman prominencia en los comportamientos, relaciones, acciones y decisiones de los jugadores y su ecosistema.
Posted on 7 Comments

Velocity in Scrum, actually

In complex and uncertain environments, more is unknown than is known. There is much we don’t know. What we know is subject to change. Only what we have achieved is known (unless we prefer to cover up). Progress is in what we have done, more than in what we plan to do. What we plan to do are assumptions that need validation by emerging actions and decisions. We make and incrementally change decisions based on what is known.

In Scrum it is considered a good idea for teams to know about the progress they have been making. It is one parameter (of several) to take into account when considering the inherently uncertain future.

From the Scrum Guide (Sprint Planning):

The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team.

Teams express this Scrum Guide guidance of ‘past performance’ often as ‘Velocity’. Although not a mandatory concept, it is a good tactic to apply in Scrum and for many teams even useful to increase their proficiency in self-management.

Painful problems arise however if Scrum gets managed through the distorting lens of the old, industrial paradigm. Purpose gets lost and ideas get corrupted. No more than an illusion of agility is created. One such case is when Velocity becomes an indicator of volume (of tasks and features produced) and is measured for external justification (i.e. beyond the team boundaries).

Although Scrum can be employed to address any complex challenge, Scrum is foremost applied as a framework for complex product delivery. For many organizations the availability and usage of their products and services is life-critical. They adopt Scrum because they need to act with more agility against that life-critical purpose. Scrum is designed to deliver agility to these organizations under the form of releasable versions of products, called Increments. The purpose is to enable organizations in having an effective impact on the market place no later than by the end of each Sprint. This is a crucial trait of agility for organizations that are highly product or service-dependent.

Against that purpose it is not helpful to not have a releasable product version by the end of a Sprint. We allow even what we have done to remain full of unknowns. We undermine the only base we have for making decisions. We undermine the solidity of our already fragile decision process even more. In terms of real progress, Velocity is actually… zero.

In the face of the purpose of increased agility through Scrum, it doesn’t add much value to discuss Velocity at Sprint Review when no releasable Increment has been created throughout the Sprint. There are probably more serious problems to address first. There are more important challenges than measuring how many points were burned. Let alone the completely futile attempts to standardize, normalize, industrialize, or equalize Velocity across an organization.

In the absence of teams’ capability to effectively produce releasable Increments, such discussions do no more than distract from the more serious problems. Velocity becomes an obfuscating indicator. The definition of Done provides the real transparency for inspection and adaptation. The definition of Done shows what is lacking to increase product quality up to the point of Increments being releasable. In the face of the urgency of agility, the question of what is defined as Done is much more important than registering the amount of unreleasable work produced.

You can obviously measure the Velocity at which undone work is created, and be more predictable in creating even more undone work. It will not help you make progress towards increased agility and having an impact.

Rather, at the Sprint Review ask yourself “What is our impact on the market? What is our ability to go to market?” It will steer the conversation in very different directions than merely reporting how much tasks were completed. Take the findings to your Sprint Retrospective to figure out what is needed to improve on the possibility to go to market next Sprint. Have the ambition of going through an engaged retrospective, rather than one of unfocused fun. Aspire to start creating valuable Increments with a demonstrable impact, no later than by the end of your next Sprint. Nobody external to the team will care about your Velocity, as an external indicator of progress, anymore.

In the face of the purpose of increased agility through Scrum, Velocity, actually, only makes sense if a measure of a team’s capability to create releasable Increments of product, no later than by the end of a Sprint.

Posted on Leave a comment

Moving Your Scrum Downfield (Six Essential Traits of the Game)

Apparently, it is easy to get stuck at interpreting the rules of Scrum. In the publication “Moving Your Scrum Downfield” I have described the six essential traits of the game to help you get unstuck and up your game. As they express rather intrinsic and implicit principles, they are too often disregarded. Yet, they are needed for a more unconsidered performance of Scrum, which allows minding the goal of the game–push back the old adversary of predictive rigidity–rather than the rules. These six essential traits are indicative of Scrum coming to life.

Having worked with Scrum since 2003, I am fascinated by its ever-expanding use, which is not limited to software and (new) product development.

Jeff Sutherland and Ken Schwaber moved the development of Scrum forward in the early 1990s. They are the co-creators and gatekeepers of (what is) Scrum.

Ken Schwaber first documented Scrum in 1995 in the paper “SCRUM Development Process.” In 2010 he initiated the creation of the Scrum Guide. Upon Jeff Sutherland’s consent, the Scrum Guide became the definitive body of knowledge holding the definition of Scrum (and what is not Scrum). A few small, functional updates were released since then, without drastic changes to the core definition of Scrum.

Scrum was instrumental in embracing software development as a form of new product development, and thus as complex work. An ever-increasing variety of work in modern society however is inherently complex too. Software and (new) product development are a subset of complex challenges, but the use of Scrum is not limited to it.

As an independent Scrum Caretaker, I care for people and organizations asking for guidance and support on their journey of Scrum, no matter the nature of their problem.

My work builds on the belief that organizations best envision their Scrum. I don’t believe in mechanistically reproducing past or others’ ways. Every case of Scrum is unique. Your Scrum is unique. No external instance—expert or otherwise—can devise your Scrum for you. There is no copy-paste. What works today might not work tomorrow. Rather than cookbook solutions, I offer help in developing people’s ability to think in terms of Scrum.

Apparently, many get stuck at interpreting the (exactness of the) rules, meanwhile losing sight of the goal of their game. Having authored the books Scrum – A Pocket Guide (2013, 2019) and 97 Things Every Scrum Practitioner Should Know (2020) I took a step back to consider what it is that makes Scrum work. The rules of the game are well documented. Assuming they are understood, what is needed to get unstuck, engage, and up your game?

I believe it is in embedding the six essential traits of the game. As expressions of rather intrinsic and implicit principles, they are easily disregarded. Yet, they are crucial to excel at Scrum and need to underly your game strategies. They are indicative of Scrum coming to life. They need to be ingrained and embodied for a more unconsidered performance of the game, for you to focus on the goal of the game again rather than on the rules.

Consider how the six essential traits of the game are indicative of Scrum coming to life:

  1. Scrum Is Simple, Yet Sufficient. The players unfold the potential of Scrum by using the simple rules that apply and explore how tactics, interactions, behaviors, and the six essential traits make Scrum work.
  2. Scrum’s DNA. The players form a self-organizing unit around the challenge of collectively creating observable, Done Increments of work, while employing empiricism to manage all work and progress.
  3. Players Demonstrate Accountability. The players contribute to valuable system outcomes through spirited collaboration, and sharing and challenging rules, agreements, skills, practices, ideas, and viewpoints.
  4. Transparency for a Flow of Value. The players use the Scrum artifacts to uphold transparency over all work done and work to be done, manage for a flow of value and preserve the ability to capitalize on unforeseen opportunities.
  5. Closing the Loops. The players regularly and repeatedly close the many intertwined loops within a Sprint toward full closure by the end of a Sprint and preserving unburdened adaptability at the macro level.
  6. The Scrum Values. The Scrum Values of Commitment, Focus, Openness, Respect, and Courage take prominence in the behaviors, relationships, actions, and decisions of the players and their ecosystem.

Are you ready to start moving your Scrum downfield, push back the old adversary of predictive rigidity and sustainably increase your agility?

Gunther Verheyen
independent Scrum Caretaker

Posted on 4 Comments

Availability of the book “97 Things Every Scrum Practitioner Should Know”

I am excited to share that my new book “97 Things Every Scrum Practitioner Should Know” is now widely available, electronically as well as in print.

Following are a few channels: eBooks.comAmazon.com, Amazon UK, Amazon Netherlands, Amazon Germany, Amazon France, Amazon SpainGoogle Books, Barnes & Noble, Bol.com., Computer Bookshop India, and Amazon India.

No fewer than 68 practitioners expended the effort to write one or more essays about Scrum for you. We did not invite them for their titles, ranks, or positions. We invited them because they have valuable insights to share with fellow practitioners like you. I thank every single one of them.
I thank you, reader, for buying the book, but even more for employing Scrum and for sharing and spreading how you make use of Scrum in addressing your specific challenges. Keep being an inspiration to other Scrum practitioners.

Find the full description of the book also at the website of the publisher, O’Reilly Media.

– – –

O’Reilly Media and I started collaborating on the book in August 2019. Looking back, I had no idea what I was getting into, where it would take me, or how much 97 is (a lot, actually, as I discovered). Inviting and working with authors from around the globe was an exciting endeavor however.

The work has much consumed (and sometimes drained and overwhelmed) me, but I am very happy with the result. Given the tons of available literature on Scrum, it proved not an easy feat trying to still make a difference. Thanks to the generous and insightful contributions of the participating authors, I believe we have done that.

I enjoyed looking for commonalities and shared themes as essays poured in. I have tried to group and order the collected essays in a way that makes sense to the many seeking Scrum practitioners out there. It was a way to create some flow across the book:

  • Part I. Start, Adopt, Repeat: 11 Things. Because adopting Scrum is more than just a one-time effort of introducing Scrum; it is a continual exercise of thinking, rethinking, and discovery.
  • Part II. Products Deliver Value: 11 Things. Because in a complex world of unstable requirements and ever-evolving technologies, “product” provides a minimal form of stability to organize your work with Scrum.
  • Part III. Collaboration Is Key: 10 Things. Because creating, sustaining, and evolving complex products and services in complex and changing environments requires collective intelligence, skills, and expertise.
  • Part IV. Development Is Multifaceted Work: 12 Things. Because development of complex products (in often complex circumstances) requires more than technically producing work (like coding or programming only).
  • Part V. Events, Not Meetings: 10 Things. Because what are commonly called the Scrum meetings are actually events that provide specific opportunities for inspection and adaptation.
  • Part VI. Mastery Does Matter: 12 Things. Because mastery matters not just for Scrum Masters, although they are quite important as masters of ceremony.
  • Part VII. People, All Too Human: 8 Things. Because development is done by people, often resulting in work for people. And people are…people.
  • Part VIII. Values Drive Behavior: 6 Things. Because Scrum is a framework of rules, principles, and…values. And values drive behavior.
  • Part IX. Organizational Design: 9 Things. Because introducing Scrum is not possible without impacting the organization and existing organizational structures.
  • Part X. Scrum Off Script: 8 Things. Because for Scrum practitioners to help shape the future of Scrum, we need imagination combined with historical awareness.

Fortunately, the essays can be read separately as well. At the end of the book, a Scrum Glossary was added, listing and explaining in the simplest way the terms used in the book.

Warm regards
Gunther
independent Scrum Caretaker

Online PSPO class (Professional Scrum Product Owner) on 17-18 December 2020

Professional Scrum Product Owner is the cutting-edge course for organizing product ownership in the most effective way. It explores the worldwide challenge that many Scrum implementations run into, i.e. how business people and product managers should engage in Scrum and in collaborating with Scrum Development Teams.

Professional Scrum Product Owner is a 2-day course that covers the role and accountability of a Product Owner on a Scrum Team and being an Agile product manager within the organization. The class builds on the core expectation for Product Owners to maximize the value of the work done for a product, thereby serving customers, users and the organization.

Scrum.org selects only the most qualified instructors to deliver this course and maintains the defined curriculum and materials to assure consistency and quality for students worldwide.

Agenda

  • Agile Product Management
  • The Product Owner in the Scrum framework
  • Managing Product Backlog
  • Managing releases
  • Value driven development

Basic information

  • Dates: 17-18 December 2020 (9-17h CET)
  • Language: English
  • Price: 1195€ + VAT
  • Price includes:
    • Two attempts on the Professional Scrum Product Owner level I assessment (“PSPO I”). The total value is 2 x 200$.
    • The official course materials.
    • A signed copy of “Scrum – A Pocket Guide,” the acclaimed book by the trainer, Gunther Verheyen.

What to expect?

Our online classes are very much case-driven with plenty of room for interaction and conversation. We keep them as low-tech as possible:

  • We will connect on Zoom and use Zoom breakout rooms for discussions in smaller teams.
  • We will use Google Jamboard in a virtual team space on Google drive.
  • The trainer will occasionally use PowerPoint and a flip chart.
  • After the class the full slide deck and pictures from the flip charts will be shared via the Google Drive.

Online PSPO class (Professional Scrum Product Owner) on 15-16 October 2020

Professional Scrum Product Owner is the cutting-edge course for organizing product ownership in the most effective way. It explores the worldwide challenge that many Scrum implementations run into, i.e. how business people and product managers should engage in Scrum and in collaborating with Scrum Development Teams.

Professional Scrum Product Owner is a 2-day course that covers the role and accountability of a Product Owner on a Scrum Team and being an Agile product manager within the organization. The class builds on the core expectation for Product Owners to maximize the value of the work done for a product, thereby serving customers, users and the organization.

Scrum.org selects only the most qualified instructors to deliver this course and maintains the defined curriculum and materials to assure consistency and quality for students worldwide.

Agenda

  • Agile Product Management
  • The Product Owner in the Scrum framework
  • Managing Product Backlog
  • Managing releases
  • Value driven development

Basic information

  • Dates: 15-16 October 2020 (9-17h CET)
  • Language: English
  • Price: 1195€ + VAT
  • Price includes:
    • Two attempts on the Professional Scrum Product Owner level I assessment (“PSPO I”). The total value is 2 x 200$.
    • The official course materials.
    • A signed copy of “Scrum – A Pocket Guide,” the acclaimed book by the trainer, Gunther Verheyen.

What to expect?

Our online classes are very much case-driven with plenty of room for interaction and conversation. We keep them as low-tech as possible:

  • We will connect on Zoom and use Zoom breakout rooms for discussions in smaller teams.
  • We will use Google Jamboard in a virtual team space on Google drive.
  • The trainer will occasionally use PowerPoint and a flip chart.
  • After the class the full slide deck and pictures from the flip charts will be shared via the Google Drive.

Online PSPO class (Professional Scrum Product Owner) on 19-20 November 2020

Professional Scrum Product Owner is the cutting-edge course for organizing product ownership in the most effective way. It explores the worldwide challenge that many Scrum implementations run into, i.e. how business people and product managers should engage in Scrum and in collaborating with Scrum Development Teams.

Professional Scrum Product Owner is a 2-day course that covers the role and accountability of a Product Owner on a Scrum Team and being an Agile product manager within the organization. The class builds on the core expectation for Product Owners to maximize the value of the work done for a product, thereby serving customers, users and the organization.

Scrum.org selects only the most qualified instructors to deliver this course and maintains the defined curriculum and materials to assure consistency and quality for students worldwide.

Agenda

  • Agile Product Management
  • The Product Owner in the Scrum framework
  • Managing Product Backlog
  • Managing releases
  • Value driven development

Basic information

  • Dates: 19-20 November 2020 (9-17h CET)
  • Language: English
  • Price: 1195€ + VAT
  • Price includes:
    • Two attempts on the Professional Scrum Product Owner level I assessment (“PSPO I”). The total value is 2 x 200$.
    • The official course materials.
    • A signed copy of “Scrum – A Pocket Guide,” the acclaimed book by the trainer, Gunther Verheyen.

What to expect?

Our online classes are very much case-driven with plenty of room for interaction and conversation. We keep them as low-tech as possible:

  • We will connect on Zoom and use Zoom breakout rooms for discussions in smaller teams.
  • We will use Google Jamboard in a virtual team space on Google drive.
  • The trainer will occasionally use PowerPoint and a flip chart.
  • After the class the full slide deck and pictures from the flip charts will be shared via the Google Drive.