Community Blog

Done is a fundamental part of bringing transparency. How does this relate to Sprint Review? Check it out! Back to the foundations of the Scrum framework (69)

Done is a fundamental part of bringing transparency. How does this relate to the Daily Scrum? Check it out! Back to the foundations of the Scrum framework (68)

Done is a fundamental part of bringing transparency. How does this relate to Sprint Planning? Check it out! Back to the foundations of the Scrum framework (67)

In this video, Mark how healthy rework can maximize learning and, ultimately, effective value for your customers. We'll explore two principles of healthy rework and two principles of unhealthy rework you can use to lean into learning!

There is often confusion in what happens in a Sprint with regards to the Increment and releasing. Short summary of this article: during a Sprint, one or more increments are produced. This happens when a Product Backlog Item meets the definition of "Done". At least once every Sprint, but it can happen more often. When a Product Backlog Item meets the definition of "Done" (and therefor becomes an increment), it can be released. Releasing can be done at any moment in time! 

Automation is a vital practice for Scrum Teams. The best Scrum Teams I have been part of automated early and often.

A common question we get asked is how do we get started with creating a Definition of Done? Let's explore how we can obtain transparency of where you are, your destination should be, and what your possible first steps are to get there!

In the heat of "the battle" teams tend to forget why they use the Scrum framework after all and what the foundations are of it. Why do we have Sprint Planning sessions every other week, why does our Product Owner has these or those accountabilities, why did we started using a team board after all, why did... 

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.

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 Developers need to be accountable for the quality of the product and how it's made. And ultimately each role in Scrum has accountabilities that effect risk. But ... 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.

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.