Community Blog

The key point of Scrum (and Agile for that matter) is getting something valuable into the hands of our customers more frequently. However, this concept, closely linked to the Definition of Done, is often misunderstood and misinterpreted.

Das kontinuierliche Liefern von nutzbaren Done Inkrementen ist das zentrale Element von Scrum. Will man Scrum auf ein Element reduzieren, dann wäre das genau das.

In my last post about Professional software teams creating working software David Corbin made a good point. How do you determining what “Free from fault or defect” means? Since that is different for each Product and may change over time you need to focus on Quality and reflecting that quality in a Definition of Done (DoD).

At a recent class, a new Scrum Master asked me for a simple example of a Definition of Done. This post captures my answer to them and I hope it will help simplify this concept for you.

The following are the changes that struck me the most in the 2020 Scrum Guide...

In the 2020 Version of the Scrum Guide, the commitments were introduced for each artifact. These then became an element of Scrum; in that they need to be used to gain the maximum value that the Scrum Framework offers. They were always part of a Professional Scrum approach, now there is a clear connection of these commitments to the artifacts. They increase transparency, and the focussed delivery of Value. Each of the commitments now clearly support and sustain an artifact.

This blog post talks about the addition of Commitments to each Artifact in the updated Scrum Guide.

One of the (main) reasons why organizations choose for an Agile approach is to become faster. Some big companies I’ve helped in the last years know they have to adapt faster, but are reluctant because of their risk aversion.

In every Professional Scrum class, we talk about Done as an important concept in Scrum.

How to make sure that the definition of Done is used properly at a sprint planning session? Continue reading ...

In this post I want to explore whether the Increment, a core concept to Scrum, needs to be changed for Scrum in a non-IT context. In future posts, I will do the same for the Definition of Done, or other concepts that may provide a better understanding of Scrum when applied to non-IT context.

Professional Scrum Trainer Sahin Guvenilir wrote "Why having a Definition of Done is not optional and how it helps you protect your customer, money, reputation and morale".

I believe there are three things you need to do regardless of the framework, methodology or program you are embracing with your organization.

When working with a flow-based Kanban system there are a few statements that I would suggest most teams should bear in mind.

Unclear language leads to incomplete transparency and ambiguity. The careful use of words like ‘bug’ will improve decision-making in your organization.

A few days ago, I was observing a Sprint Retrospective. The Scrum Team decided to work on the Definition of Done (DoD), identified as the most important topic to adapt for the next Sprint. The discussions were open and animated, when an unexpected discussion emerged during the session.

The purpose of Scrum is to create a potentially releasable Done Product Increment, in order to realize business value. Many teams struggle in improving their Definition of Done. The technique described here allows for greater transparency on what the Definition of Done is, and what the next steps are.

In Scrum, “Done” doesn’t support adjectives like “nearly”, “pretty much” or “almost”. Work is “Done” or it isn’t . And there is a very powerful, compelling reason behind this: the Scrum Framework only helps to reduce the risk of wasting money and effort when you deliver “Done” software every Sprint; a new version of your product that is, or with the proverbial press of a button can be, released to users. In this post I underscore how essential this rule is to Scrum.

Often I hear people say that Scrum does not take care of risk: there is no risk log, risk is not on the agenda of the Sprint Review or Retrospective as a standard agenda-item. The Development Teams need to be accountable for the quality of the product and how it's made. That's a risk right there! If there is not one person accountable for quality, being on time, within budget, building the right thing... How is risk managed in Scrum?

The purpose of Scrum is to deliver Increments of releasable functionality. So at each Sprint Review, a “Done” Increment is required to make transparent the progress made by the team.

Everyone building software products today aspire to be able to seamlessly update the production software in a continuous manner. To be able to deploy code without the ‘normal’ friction of process controls, reviews, test departments and committee meetings.

The PSD training teaches the whole Scrum Team on how to do real Scrum. They work in Sprints, create Done software and use the appropriate tools and practices for it. It is a unique experience on how really good Scrum feels like.

El Daily Scrum es una reunión clave para la adopción del empirismo, es una oportunidad de inspección y adaptación para generar transparencia hacia el objetivo del Sprint.

One of the arguments used against Scrum and a common misconception at the same time is the idea that quality is traded for speed in Scrum. As a PST with years of experience in Quality Assurance I decided to challenge this myth.

What Is Self-Organization? “Knowledge workers have to manage themselves. They have to have autonomy,” says Peter Drucker.

On July 7th the Scrum community gathered in Amsterdam (The Netherlands) for the 5th edition of Scrum Day Europe. This year's theme was 'the next iteration'.

Throughout the Agile Alliance 2016 conference, I was struck by a recurring feeling that many people don’t understand what the Sprint Review is.

Over the past 10 years I have worked with many organisations and helped them to use Scrum to create innovative and sometimes market leading Products. I have seen a lot of Scrum during this time, much of it done well, but some of it done badly.

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.

Scrum brings agility to and creates Agile organizations through the implementation of empirical process control, the process of frequent inspection and adaptation.

I always spend time during training classes thoroughly covering the concept of Definition of Done, sometimes abbreviated “DoD.” As a concept it’s fairly eas

You need quality enablement to achieve predictable delivery for your organisation which takes effort to achieve.