Online PSPO class (Professional Scrum Product Owner) on 24-25 September 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: 24-25 September 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.
Posted on Leave a comment

Scrum Glossary (International Versions, April 2018)

By the end of 2017 I updated the Scrum Glossary of my book “Scrum – A Pocket Guide” (2013). A group of Scrum enthusiasts subsequently translated that updated version to different languages. A first release of those international versions was done in March 2018.

The new, April 2018, release of the international versions is now available, as a free download (PDF): Scrum Glossary (International versions) -April 2018

  • Four new languages were added: Filipino-Tagalog, French, Indian-Hindi, Turkish.
  • The definition for “Definition of Done” was rephrased.
  • A definition for “Product” was added.

Share my gratitude that following people spent quite some of their valuable time on this initiative to make these translations available for you:

  • Chinese (simp/trad): Lana Sun, Wei Lun Teh, Chee-Hong Hsia
  • Danish: Rasmus Kaae
  • Filipino: Shirley Santiago, Warren Yu
  • French: Fabio Panzavolta, Mohamed Gargouri
  • German: Uwe Schirmer, Peter Götz, Dominik Maximini
  • Hindi: Punit Doshi, Hiren Doshi
  • Italian: Michael F. Forni
  • Polish: Paweł Feliński
  • Portuguese: Leonardo Bittencourt
  • Russian: Konstantin Razumovsky
  • Spanish: Alex Ballarin
  • Turkish: Ilkay Polat, Lemi Orhan Ergin

In the document you will also find my Dutch translation. I maintain the base English version on the Scrum Glossary section of my website.

All feedback is welcome. Sharing of the PDF is equally encouraged.

Warm regards
Gunther

Posted on 3 Comments

Branching Done

I was recently contacted by a senior executive of a mid-sized company that is evolving their product development to Scrum. He explained a situation he had been in and wanted my opinion. He accepted me to share his story here (with some abstractions, and calling him Jim) in an open-ended way, inviting the reader -much like he did- to reflect on the purpose and accountability of the Scrum Master and how that role is needed for… well, many reasons still.

Jim’s company started out doing Scrum on some smaller, carefully contained projects with individual Scrum Teams developing clearly separated products and product areas. Through these projects they discovered how iterative-incremental product development increased transparency, and how disciplined engineering practices allowed them to excel. Where Scrum in the beginning was much seen as mainly for IT people, they soon found out the need for a mandated Product Owner representing the internal business and the user base to the teams. They felt that hiring a Scrum Master with three years of experience had been really helpful.

One of these early projects was recently expanded to two teams. Both teams work on the same product and draw work from one and the same Product Backlog. The Product Owner and the Scrum Master perform their roles for both teams.

Jim contacted me after he was invited to and attended the second Sprint Review after the expansion to two teams.

At this Sprint Review the two teams took 60 minutes each to walk everyone through the software functionality they had created. Each team showed the work from their separated code branch. By the end of the Sprint Review, Jim inquired about releasing the software, but got an unclear answer. In the end it boiled down to the teams promising they would have a look at it, and discuss it with the release department who hadn’t been involved so far.

Jim felt like not straining the teams more but an uneasy feeling had crept in. After all, one of the reasons why they started adopting Scrum were their long release cycles, and unclear release dates. It had led to many customer complaints and even losing a couple of important customers.

When he asked for my advice I told him only I was very interested to hear about the conversation I suggested he set up with the Scrum Master. He seemed a bit surprised when I started talking about the role of the Scrum Master.

How about you? If any, where would you situate the accountability of the Scrum Master in this?

Posted on 1 Comment

Can you say ‘yes’? (10 questions about your Scrum)

I call myself a  Scrum Caretaker. I aspire inspiring people using Scrum. I prefer showing that I care by sharing positive experiences and cases that demonstrate how amazing working with Scrum can be, what problems can be tackled and how to, the level of excellence we can build into our products, how Scrum can engage people. Ultimately I hope to help people employ Scrum to re-humanize their workplace.

But then it regularly dawns on us — the many, many misconceptions that exist over Scrum. We feel provoked to try to correct the recurring and worrying interpretations of Scrum that are out there. Sometimes that is fun. Often it is not. It can be energizing. In general it drains us. A few lifetimes can be spent fighting that battle. We limit the energy spent fighting to make room for constructing. 

A good place to start is reminding people of what ought to be in place according to Scrum. It provides clarity over what is mandatory in Scrum (and therefore, what is not).

Unlocking the benefits of Scrum requires however a lot more than just knowing what Scrum consists of. Scrum is the foundation to a complex adaptive system (‘CAS’) producing results that cannot be attributed to its individual components separately. Unlocking the benefits of Scrum depends more on the way the whole of Scrum is being used, through the rules that bind its constituent parts together. Unlocking the benefits of Scrum depends even more on what the people practicing Scrum do, more than what they know or say in the name of theory. It depends on how people interact within the framework, the conversations they have.

Here are 10 questions to help you assess what you do with the 11 elements of Scrum. Can you say ‘yes’?

  1. The accountabilities of Product Owner, Development Team(s) and Scrum Master are identified and enacted?
  2. Work is organized in consecutive Sprints of 4 weeks or less?
  3. There is an ordered Product Backlog?
  4. There is a Sprint Backlog with a visualization of remaining work for the Sprint?
  5. At Sprint Planning a forecast, Sprint Backlog and a Sprint Goal are created?
  6. The result of the Daily Scrum is work being re-planned for the next day?
  7. No later than by the end of the Sprint a Done Increment is created?
  8. Stakeholders offer feedback as a result from inspecting the Increment at the Sprint Review?
  9. Product Backlog is updated as a result of Sprint Review?
  10. Product Owner, Development Team(s) and Scrum Master align on the work process for their next Sprint at the Sprint Retrospective?

Minimally, make sure that you remain aligned (6) and that you regularly check what else might be needed (10). Upon that foundation, grow towards saying ‘yes’ to all questions, meanwhile collaboratively exploring different  If you don’t overthink your way of working along that road of evolution, you might find Scrum to be of a bare essence actually.

Minimally, make sure that you remain aligned (6) and that you regularly check what else might be needed (10). Upon that foundation, grow towards saying ‘yes’ to all questions.

If you don’t overthink your way of working along that road of expansion and evolution, you might find Scrum to be of a bare essence actually. Do know that understanding that Scrum requires 11 elements to be in place is only the beginning. My 10 questions might help you better understand how they relate to each other. Find yourself at the beginning still. Understand how all of them serve empiricism, the act of regular inspection and adaptation, and how inspection without adaptation makes no sense in a world of Scrum. Separate rules from tactics to play the game. Use empiricism also to explore different tactics

My Scrum Gameboard not only represents the 11 mandatory elements, but also 3 principles underlying Scrum. Understand how the Scrum Values drive behavior.

Keep learning.
Keep improving.
Keep… Scrumming.

Warm regards
Gunther
independent Scrum Caretaker

Posted on 9 Comments

Done is a crucial part of Scrum, actually

If Scrum was to be reduced to one purpose, and one purpose only, that is the creation of a Done Increment in a Sprint. The typical term in Scrum to describe the state of software being releasable is “Done”. All that this state of releasability encompasses is captured in the “definition of Done”.

Done Increments are THE way to achieve agility through the empiricism of Scrum. 

Empiricism

The empiricism of Scrum, the process of regular inspection and adaptation, only functions well upon transparency. Transparency is having insights into reality but is is additionally upheld through standards and agreements, against which inspection and adaptation happens. The definition of Done is such a standard. The definition of Done is part of professional Scrum development. Other standards, like development and engineering standards, might even be derived from the definition of Done.

The frequency of the inspection and adaptation should be high enough to be able to act in the moment yet not too high to preserve the ability to get considerable amounts of work done.

The definition of Done serves empiricism

The definition of Done should be shared, explicit, clear and concise.

A Development Team will use the definition of Done to consider the amount of work to be pulled into a Sprint during Sprint Planning.

The evolution of an Increment is managed via collaborative inspection and adaption of the actual development work against the forecasted Product Backlog and the Sprint Goal; at least on a daily base, possibly sooner. A Daily Scrum assures that the people accountable for the actual development optimize their work plan against new insights and achievements. The definition of Done supports identification of work remaining to get the software to “Done”.

No later than at the Sprint Review, the Increment is collaboratively inspected and adapted with the stakeholders. This inspection opens up the opportunity of incorporating feedback from these stakeholders to identify what is most important to do next. Purpose is the open identification of what is important to do next, not hindered by unknown, unpalatable, unestimatable remaining work.

Releasing the software closes the feedback loop to the market and the users of the software. Releasing sooner is better in order to remain in line with external expectations and experiences. It is the only way to ultimately validate all assumptions (of functionality, and others) built into the product. Not being able to release an Increment at the end of a Sprint, or sooner, impedes agility. The decision of releasing an Increment by the end of a Sprint is a Product Owner decision, as the sole representative of users and stakeholders on the Scrum Team. The Product Owner’s shipping decision should not be constrained by ‘development’ work.

Undone software is best not released. There might be situations in which undone software is consciously released. An extreme crisis maybe? The least to do is make the undone work transparent via Product Backlog, knowing and understanding that any estimate of such corrective work is probably totally off and the nature of the work unplannable. This ‘registration’ does not render an undone release any more professional, and probably the crisis you are hoping to solve with the unrelease, will re-appear because an unrelease will not fundamentally solve it. Unreleases backfire. Probably better to Scrumble.

At the Sprint Retrospective, the Development Team might inspect and revise its definition of Done; incorporating new insights, new expectations, higher standards. Ownership over the Definition of Done lies with the Development Team. It is their accountability to develop software that lives up to the definition of Done. In many organizations the definition of Done is likely to be derived from organizational standards for development quality. A Development Team will enact them, expand them. If “done” for an increment is not a convention of the development organization, the Development Team will create their definition of Done, appropriate for the product.

Regardless, the definition of Done provides transparency over the state of an Increment at the Sprint Review, where this state optimally reflects ‘releasable’.

Done is a crucial part of Scrum, actually

Although no official artifact, the definition of Done is a crucial part of Scrum in upholding transparency over the state of releasability of the software created. No transparency means no meaningful inspections, and no meaningful adaptations of Product Backlog through stakeholder feedback upon review or through user feedback upon release.

In the last updates to the Scrum Guide (most recent: July 2013) the definition of Done was given considerably more attention. Rightfully, as “Done” is absolutely crucial in Scrum.

Here’s how I stressed the importance of Done in my book, “Scrum – A Pocket Guide“:

The empiricism of Scrum only functions well with transparency. Transparency requires common standards to work against and to inspect upon. The definition of done sets the standard for releasable.

 and

The definition of done is essential to fully understand the work needed to create a releasable Increment and for the inspection of that Increment at the Sprint Review. The definition of done serves the transparency required in Scrum in terms of the work to be done and the work actually done.

Posted on 2 Comments

A Professional Organization Defines Quality

An often observed problem of Scrum adoptions is the isolated way that Scrum Teams operate, being or acting as if detached from the wider organization. There are several possible causes, one of them being the disconnect between people creating standards and people implementing upon those standards.

An organization that thrives and depends on software products and services can be expected to have a definition of product qualities in place, and to express such through standards, guidelines, rules, service levels and other expectations. Scrum Development Teams, consisting of professional product developers, are an integral part of an organization, rather than being isolated gangs of thug coders within the organization. Such Development Teams can be expected to adhere to overarching product standards.

It explains why, on the topic of the creation of a definition of Done, the Scrum Guide says (see http://www.scrumguides.org/scrum-guide.html#artifact-transparency-done):

If the definition of “done” for an increment is part of the conventions, standards or guidelines of the development organization, all Scrum Teams must follow it as a minimum. If “done” for an increment is not a convention of the development organization, the Development Team of the Scrum Team must define a definition of “done” appropriate for the product.

If, as can be expected, the minimal definition of Done is provided by the organization, a Development Team can still complement it with context-specific elements; the product, a release or technology.

If organizational guidelines are not provided, a Development Team should, as professionals, create an appropriate definition of Done for their development. How else does a team know what work to do, what tasks to undertake, if it doesn’t know, and have a shared understanding of, the characteristics of the Done or end product? How else can Product Owners and stakeholders know what quality they will be receiving? Quality should not be their concern, or their primary focus. Market reception, business opportunities, offered functionality should be.

The lack of such standards or provision of them is therefore also best raised within the organization to serve wider organizational improvement. Remember that such improvement will also benefit others within the organization.

Scrum can be a lever for organisational improvement. Scrum Master is a servant-leader role for the organization too.

Often organizations provide a list of guidelines that is presented as ‘minimal’, yet proves to be unrealistically long and heavy. This again is a great area for conversation, improvement and removal of organizational waste. The organization might have not adapted their standards and expectations to the reality of iterative-incremental development, or their standards might for a long time have not been matched against actual implementation of them. ’Standards’ might be in place that were created as part of long, sequential processes where quality problems typically accumulated heavily before they were detected. As the people maintaining standards typically do not engage in creating quality upon those standards they start adding demands to the expectations that prescribe the delivery of proof that ‘quality’ is created. They started confusing defining quality (‘what’) with evidence of quality ‘(how’).

Avoiding the conversation is not helpful. Self-organization is not an excuse to do so. A Development Team might push back toward a realistic definition of Done with arguments on how they will actually build in quality, Sprint after Sprint after Sprint. A feedback loop from practice to theory is best established. It is important, and often surprisingly revealing, for the people creating standards to experience what practical application of these standards entails, or what waste is in them when iterative-incrementally delivering versions of releasable product.

Quality, in the end, is in the product, not in paper documentation. Paper documentation allows lies and illusions of quality, working software doesn’t.

Posted on 2 Comments

The deliberate evolution of “Scrum – A Pocket Guide”

In 2013 I accidentally created a book, “Scrum – A Pocket Guide”. In 2018 I deliberately evolved my Scrum travel companion into a second edition.

I am humbled over the many unanticipated consequences of the accidental creation of my pocket guide to Scrum. I equally enjoyed updating my book to a second edition 5 years later. This time around it was a deliberate evolution rather than an accidental creation. The first batch will be available 16 January 2019 and soon after in all major formats (hard copy, Kindle, PDF, eBook, ePub) via all main channels worldwide.

Who would have figured that there was room for a second edition of my pocket guide to Scrum? Certainly as my book remained in the best-seller list of my publisher all the time?

For this deliberate endeavor, I considered how I described the Scrum Values in the first edition. In July 2016 they were added to the Scrum Guide. How I described the traditional 3 questions as a good, but optional tactic for the Daily Scrum. That too is now in the Scrum Guide, since November 2017.

Obviously and fortunately, that does not mean there are no further evolutions to mind.

Not only have I found new ways to express Scrum, while working with teams and executives, facilitating various classes, and connecting with practitioners at events. We also adopted terminology that better expresses the intentions of Scrum.

Beyond these intrinsic drivers for change, I observe how the balance of society keeps rapidly shifting from industrial (often physical) labor to digital (often virtual) work. In many domains of society, the unpredictability of work increases, drastically and continually. The need for the Agile paradigm is bigger than ever, and thus the value of the tangible framework of Scrum to help people and organizations increase their agility while addressing complex challenges in complex circumstances.

More and different people look for guidance and insights on their journey of Scrum, increasingly in domains beyond software development. Organizations look for clear insights in the simple rules of Scrum as their current ways of working fail them in the Complex Novelty space.

As the third Scrum wave is rising, the second edition of “Scrum – A Pocket Guide” remains the simple and straightforward compass for those that want to surf that wave. This second edition more than ever offers the foundational insights into Scrum for Complex Novelty players and their organizations to properly shape their Scrum.

Some of the updates in the second edition that stand out (a bit more than the other changes) within the preserved overall structure (of chapters and modules):

  • The definition of Agile is condensed to three key characteristics.
  • Observations are added on the post-chasm years of Agile.
  • The Scrum Game Board is slightly tweaked.
  • The forward-looking design of the Scrum events is expressed more clearly.
  • A Release Burn-down chart as a forecasting tactic is added.
  • The pictures, naming and descriptions of the included scaling tactics are improved.
  • The Scrum Glossary was updated.

I thank Blake McMillan (Soulofscrum.com) and Dominik Maximini for their much-appreciated review of this second edition. I thank all translators for their past and on-going efforts to spread my words in different languages. Stay tuned for more news about translations.

If I have done a proper job of re-imagining my book, the second edition won’t feel like a new book. A word-by-word comparison would prove otherwise.

Enjoy reading!

Gunther
independent Scrum Caretaker

(Thank you, Higher View, for your professional expertise in video creations)

Posted on Leave a comment

The “ScrumAnd” Stance (requiring thought and discipline)

Try organizing a party in a “Yes, but…” atmosphere. The result is probably a zillion obstacles identified, but no party.
Try moving through a door with your eyes stubbornly fixated on the door frame. People seemingly can become deeply obsessed with frames-as-obstacles.

Try benefiting from Scrum in a “Yes, but…” environment, where the primary response is to raise concerns and hindrances, where the conversation is all about obstacles, and that what cannot be done.

“Yes, but” comes in many guises.

“Yes, but” is a tempting stance, offering the illusion of safety. Shifting to “Yes, and” requires thought and discipline. It requires thought and discipline to consciously look for possibilities and opportunities first, no matter how small. This does not preclude awareness of problems and obstacles, but the focal point shifts radically. Check if the door is actually open. Look at the doorway. Trust the door frame for holding the wall from collapsing if you pass the door. If the door is closed, the frame is probably not where the solution is. 

Imagine adopting Scrum from a “Yes, and” stance.

Over the past decade Scrum did more than just gain a critical mass to build on. Since Scrum’s inception in 1995 and the definition of ‘Agile’ as a set of values and principles in 2001, Scrum gradually became the most preferred way for people, teams and organizations worldwide to become more Agile. Agile crossed the chasm (2005-2006) and by now the 3rd Scrum Wave has risen.

Zeitgeist. Inclusive language and an inclusive stance are more helpful today. “ScrumAnd” is today’s way forward to help people increase the benefits realized through their manifestation of Scrum. 

“ScrumAnd” starts with Scrum. Scrum is a simple, yet cohesive framework. In a nutshell:

A Scrum Master fosters an environment where:

  1. A Product Owner assures there is a Product Backlog, an ordered list of work deemed necessary to optimize the value a product delivers.
  2. In consultation with the Product Owner, Development Team(s) pull the work from Product Backlog deemed feasible to get done in a time-boxed Sprint against an overarching Sprint Goal.
  3. On a daily basis the Development Team(s) synchronize their progress and upcoming work toward delivering a releasable version of product, available no later than by the end the Sprint.
  4. All players involved figure out what to work on next and how to best organize as from the next Sprint.
  5. Repeat.

Although crucial to optimize the benefits realized, observation shows how difficult it is to keep Scrum cohesive. There are no practices that can be left out or cut out without harmfully breaking the cohesion (covering up dysfunctions or other ways of undermining important benefits). There is no such thing as individual Scrum practices.

Observation shows how difficult it is to keep Scrum lightweight and nimble. There is no need to aggravate Scrum. The “And” in “ScrumAnd” is not the next excuse to stack practices, rules or roles on top of Scrum. Instead, Scrum can wrap many practices, as tactics to apply the overarching rules, principles and values. Such are inclusive practices. Inclusive practices are needed and even make out a specific manifestation of Scrum. When inclusive practices are applied well, cohesion is preserved in the resultant system that is still recognizably… Scrum. “ScrumAnd” is more about the overarching rules, principles and values of Scrum, than it is about inclusive practices.

“ScrumAnd” starts, and ends, with Scrum. Many roles and domains exist that may not be covered by Scrum, for which Scrum has no rules, events and artefacts in place. Practices in such domains can help an organization get more out of Scrum. They are complementary practices. Complementary practices don’t change your manifestation of Scrum. The “And” in “ScrumAnd” is not about complementary practices.

“ScrumAnd” supports thinking about how to get more out of Scrum, how to be more effective in employing Scrum, and gain agility.

The syntax of “ScrumAnd” -if any- might look like:

Illustrations of “ScrumAnd”:

  • “YES, we have a Product Owner,
    AND a dedicated, full-time Product Owner, acting from a business perspective, with a mandate, and clear decision authority increases our agility in terms of customer proximity.”
  • “YES, we have a Product Backlog,
    AND going from using it merely as an inventory of exhaustive specifications to experiencing it as a collaborative instrument that helps us focus on what is really important and valuable increases our agility in terms of our ability to deal with unpredictability.”
  • “YES, we have a definition of Done,
    AND expanding it beyond producing only coded, tested or even integrated work to creating releasable and valuable Increments increases our agility in terms of our ability to deliver actual value (and close the feedback loop with the customer base).”

The illustrations of “ScrumAnd” are just that, illustrations, representations of what might work, like some earlier illustrations. There are no universal definitions, labels or boundaries, not within an individual “ScrumAnd”, nor across several of them.

And then complexity comes into play.

“ScrumAnd” illustrations can be created for all elements of the Scrum framework. The implied “ScrumAnd” stance shifts the mind to the exploration of options and possibilities, patterns of improvements, away from the frame (Scrum) or obstacles only.

And then complexity comes into play. There is a “ScrumAnd” in understanding and employing “ScrumAnd”. “ScrumAnd” is not for judging or assessing, it is more than a simplistic model of linear progression, more than phases, maturity or other levels. Inspection without adaptation is pointless anyhow, to start with. Despite the possible creation of individual “ScrumAnd” representations, the topics they target are necessarily connected, matched, intertwined. They reinforce or diminish each other without clear cause-effect relationships.

Complexity kicks in even more. One “ScrumAnd” may not result in improved agility through Scrum. Improvement requires concurrency and comes in Increments too. Reversely, increased agility through Scrum cannot be attributed to one “ScrumAnd” alone. “ScrumAnd” abides by the sfumato principle, the reality that reality has layers and shades of gradual progression, shadows rather than cold delineations, monochromatic color areas and binary separations.

  • A PDF of this text is available for download
  • The “ScrumAnd” poster (PNG) is available for download

Scrum Glossary

Burn-down Chart: A chart showing the decrease of remaining work against time.

Burn-up Chart: A chart showing the increase of a parameter, e.g. value, against time.

A Complex System: A system composed of many interacting parts (‘agents’) displaying collective, emergent behaviors that cannot be modeled or understood by a reductionist understanding of its constituent parts. It is a ‘Complex Adaptive System’ when one emergent phenomenon is the optimization of system features.

Daily Scrum: A daily event, time-boxed to 15 minutes or less, to re-plan the development work during a Sprint. The event serves for the Development Team to share the daily progress, plan the work for the next 24 hours and update Sprint Backlog accordingly.

Definition of Done: The set of expectations on quality that a product Increment must exhibit to make it releasable, i.e. fit for a release to the product’s users.

Development standards: The set of standards and practices that a Development Team identifies as needed to create releasable Increments of product no later than by the end of a Sprint.

Development Team (also: Scrum Team): The group of people accountable for all evolutionary development work needed to create a releasable Increment no later than by the end of a Sprint.

Emergence: The process of the coming into existence or prominence of unforeseen facts or knowledge of a fact, a previously unknown fact, or knowledge of a fact becoming visible unexpectedly.

Empiricism: The process control type in which decisions are based on observed results, experience and experimentation. Empiricism implements regular inspections and adaptations requiring and creating transparency. Also referred to as ’empirical process control’.

Forecast: The anticipation of a future trend based on observations of the past, like the selection of Product Backlog deemed deliverable in the current Sprint or in future Sprints for future Product Backlog.

Impediment: Any hindrance or obstacle that is blocking or slowing down the Development Team and cannot be solved through the self-organization of the Development Team itself. Raised no later than at the Daily Scrum, the Scrum Master is accountable for its removal.

Increment: A body of releasable work that adds to and changes previously created Increments, and–as a whole–forms a product.

Product (n): A tangible or non-tangible good or service providing immediate value to specific consumers (1); the outcome of specific actions or some defined process (2). Defines the span of: Product Owner, Product Backlog and Increment.

Product Backlog: An ordered, evolving list of all work deemed necessary by the Product Owner to create, deliver, maintain and sustain a product.

Product Backlog refinement: The recurring activity in a Sprint through which the Product Owner and the Development Team add granularity to future Product Backlog.

Product Owner: The person accountable for optimizing the value a product delivers, primarily by managing and expressing product functions and solutions in a Product Backlog. The single representative of all stakeholders and consumers.

Scrum: A simple framework that enables people to derive value from complex challenges.

Scrum Master: The person accountable for fostering an environment of Scrum by guiding, coaching, teaching and facilitating one or more Scrum Teams and their environment in understanding and employing Scrum.

Scrum Values: A set of 5 fundamental values and qualities underpinning the Scrum framework; commitment, focus, openness, respect and courage.

Self-organization: The process of people forming organized groups around problems or challenges without external work plans or instructions being imposed on them.

Sprint: An event that serves as a container for the other Scrum events, time-boxed to 4 weeks or less. The event serves getting a sufficient amount of work done, while ensuring timely inspection, reflection and adaptation at a product and strategic level. The other Scrum events are Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective.

Sprint Backlog: An evolving plan of all work deemed necessary by the Development Team to realize a Sprint’s goal.

Sprint Goal: A concise statement expressing the overarching purpose of a Sprint.

Sprint Length: The time-box of a Sprint, which is 4 weeks or less.

Sprint Planning: An event marking the start of a Sprint, time-boxed to 8 hours or less. The event serves for the Scrum Team to inspect the Product Backlog considered most valuable at that time and design that forecast into an initial Sprint backlog against the Sprint Goal.

Sprint Retrospective: An event marking the closing of a Sprint, time-boxed to 3 hours or less. The event serves for the Scrum Team to inspect the Sprint that is ending and establish the way of working for the next Sprint.

Sprint Review: An event marking the closing of the development of a Sprint, time-boxed to 4 hours or less. The event serves for the Scrum Team and the stakeholders to inspect the Increment, the overall progress and strategic changes in order to allow the Product Owner to update the Product Backlog.

Stakeholder: A person external to the Scrum Team with a specific interest in or knowledge of a product that is required for the further evolution of the product.

Time-box: A container in time of a maximum duration, potentially a fixed duration. In Scrum all events have a maximum duration only, except for the Sprint itself which has a fixed duration.

Velocity: Popular indication of the average amount of Product Backlog turned into an Increment of releasable product during a Sprint by a specific (composition of) a team.

Notes

The Scrum Glossary has been translated in 20+ languages. The combined international translations of the Scrum Glossary below are available as a free download (PDF): Scrum Glossary (International versions) -Oct 2019.

Previous versions of the document can be found at:

Posted on 3 Comments

Scrum Vocabulary (updated)

Driven by the prospect of an Italian translation of my book “Scrum – A Pocket Guide” I decided to revise it slightly; minor tweaks of words and terms, although a lot of them.

As part of my revision, I also updated the Scrum Vocabulary of my book:

  • Burn-down Chart: a chart showing the decrease of remaining work against time.
  • Burn-up Chart: a chart showing the increase of a parameter, e.g. value, against time.
  • Daily Scrum: a daily event, time-boxed to 15 minutes or less, to re-plan the development work during a Sprint. The event serves for the Development Team to share the daily progress, plan the work for the next 24 hours and update Sprint Backlog accordingly.
  • Definition of Done: a set of expectations and qualities that a product must exhibit to make it fit for a release in production.
  • Development standards: the set of standards and practices that a Development Team identifies as needed to create releasable Increments of product no later than by the end of a Sprint.
  • Development Team: the group of people accountable for all incremental development work needed to create a releasable Increment no later than by the end of a Sprint.
  • Emergence: the process of the coming into existence or prominence of unforeseen facts or knowledge of a fact, a previously unknown fact, or knowledge of a fact becoming visible unexpectedly.
  • Empiricism: the process control type in which decisions are based on observed results, experience and experimentation. Empiricism implements regular inspections and adaptations requiring and creating transparency. Also referred to as ’empirical process control’.
  • Forecast: the anticipation of a future trend based on observations of the past, like the selection of Product Backlog people believe they can deliver in a Sprint or in future Sprints for future Product Backlog.
  • Increment: a candidate of releasable work that adds to previously created Increments, and – as a whole – forms a product.
  • Product Backlog: an ordered, evolving list of all work deemed necessary by the Product Owner to create, maintain and sustain a product.
  • Product Backlog refinement: the activity in a Sprint through which the Product Owner and the Development Team add granularity to future Product Backlog.
  • Product Owner: the person accountable for optimising the value a product delivers by incrementally managing and expressing all product expectations and ideas in a Product Backlog; the single representative of all stakeholders.
  • Scrum (n): a simple framework for complex product delivery (1); a simple framework for complex problem management (2).
  • Scrum Master: the person accountable for fostering an environment of Scrum by guiding, coaching, teaching and facilitating one or more Scrum Teams and their environment in understanding and employing Scrum.
  • Scrum Team: the combined roles of Product Owner, Development Team and Scrum Master.
  • Scrum Values: a set of 5 fundamental values and qualities underpinning the Scrum framework; commitment, focus, openness, respect and courage.
  • Sprint: an event that serves as a container for the other Scrum events, time-boxed to 4 weeks or less. The event serves getting a sufficient amount of work done, while ensuring timely inspection, reflection and adaptation at a product and strategic level. The other Scrum events are Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective.
  • Sprint Backlog: an evolving overview of the development deemed necessary to realize a Sprint’s goal.
  • Sprint Goal: a concise statement expressing the overarching purpose of a Sprint.
  • Sprint Planning: an event marking the start of a Sprint, time-boxed to 8 hours or less. The event serves for the Scrum Team to inspect the Product Backlog considered most valuable and design that forecast into an initial Sprint backlog against an overarching Sprint Goal.
  • Sprint Retrospective: an event marking the closing of a Sprint, time-boxed to 3 hours or less. The event serves for the Scrum Team to inspect the past Sprint and establish the way of working for the next Sprint.
  • Sprint Review: an event marking the closing of the development of a Sprint, time-boxed to 4 hours or less. The event serves for the Scrum Team and the stakeholders to inspect the Increment, the overall progress and strategic changes in order to allow the Product Owner to update the Product Backlog.
  • Stakeholder: a person external to the Scrum Team with a specific interest in or knowledge of a product that is required for the further incremental evolution of the product.
  • Time-box: a container in time of a maximum duration, potentially a fixed duration. In Scrum all events have a maximum duration only, except for the Sprint itself which has a fixed duration.
  • Velocity: popular indication of the average amount of Product Backlog turned into an Increment of releasable product during a Sprint by a specific (composition of a) Scrum Team. Serves as an aid for the Development Team of the Scrum Team to forecast future Sprints.

I look forward to the Italian version seeing the light of day in 2018. I translated my book (2013) to Dutch in 2016 as “Scrum Wegwijzer“. It was published in German as “Scrum Taschenbuch” (translated by Peter Goetz and Uwe Schirmer) in 2017.

You can still find the Scrum Glossary of those editions on my blog.