Scrum Journey

Because Scrum is easy to understand yet difficult to master, rooms for improvement are still possible to increase your team productivity and creativity. 

With this page, I’m aiming to first remind the underlying principles of Scrum, and then invite you for a reflection with open questions.

Why Scrum?

Scrum is lightweight with only 11 elements:

  • 3 artefacts: Product Backlog, Sprint Backlog and Product Increment,
  • 3 roles: Product Owner, Development Team and Scrum Master,
  • 5 events: Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective.

Scrum, actually, gives you a minimal structure and boundaries to self-organize and add complementary practices adapted to your context.

Scrum is not restrictive or perspective.

Scrum is a way to implement agility by increasing your ability to adapt to new changes. This adaptation ability is made possible by the frequent “Inspection & Adaptation” opportunities provided by the Scrum events.

Missing one of the Scrum events is a lost opportunity to adaptation. 

An effective “Inspection & Adaptation” is only made possible with available transparent information. Imagine how a thermostat is able to inspect & adapt the room temperature having a wet washcloth over it! Transparency in Scrum is provided by the 3 artifacts.

Inspection & Adaptation without Transparency is useless.

The Inspection & Adaptation are made by the 3 roles. The Scrum Team members are the inspectors.

Frequent repetition of “Transparency + Inspection + Adaptation” process, made by diligent inspectors, is an effective way to deal with complexity. Software development is a complex domain (more unknown than known).

Behaviors over processes

Good behavior makes possible a process success. Good behavior makes possible to keep the team spirit alive. Good behavior avoids practicing mechanical Scrum (Zombie Scrum) and simply go through the motions.

The 5 Scrum Values (Courage, Commitment, Focus, Openness and Respect) help shaping the needed behavior for a team success: to continuously improve and maximize value.

The 5 Scrum values will help to build trust so that “Inspection & Adaptation with adequate Transparency” process come to life.

Good behavior is the lifeblood of a Scrum Team.

Good behavior is what makes us professionals.  

Invite for reflection to make our use of Scrum more effective

Doing Scrum is not the goal. Doing Scrum is a path made by continuous Inspection & Adaptation.

Doing Scrum is not the point. Maximizing value and enable business agility are the point.

  • Is it okay to not always have a “Done” Increment?
  • If we are trying, is that good enough? What does ‘trying’ mean? Are we challenging ourselves to go beyond our comfort zone, to try new things, to learn new things?
  • Are some defects okay? What are we doing to improve quality? Are we having discussions about expanding/ clarifying DoD? Are we having discussions about different ways of working to always get to “Done?”
  • Are our business stakeholders truly engaged? Are they providing meaningful feedback and what are we doing to solicit meaningful feedback? Do we have the right stakeholders involved?
  • How do we know users are satisfied? What empirical evidence are we gathering? Do we have a variety of metrics and understand trends? Are we adapting the Product Backlog based on the evidence?
  • Where may the Scrum Values be showing up?
  • What Scrum Values may not be fully honored?


A team success is made possible by its team members cohesion. Think about the PSG football club case that is made with “stars”. Because of their football players stars are acting more individually than collectively, PSG is struggling with winning European trophies.

A cohesive team embodying the 5 Scrum Values looking for continuous excellence and acting with professionalism to deliver the highest quality products.

Keep doing, keep improving, and have fun.


The Sprint Goal lifecycle

In this blog post I explain why the Sprint Goal is key for an effective implementation of Scrum and how it is widely present in the Scrum framework by exploring its “lifecycle”. 

The Sprint Goal lifecycle

Scrum is defined as a framework to address complex problems while delivering products of the highest possible value. A good Sprint Goal is, then, the one focusing to validate value assumptions to help achieving what Scrum is meant for (maximizing the value of the product iteratively and incrementally).

When we talk about value we look at the Product Owner as a value maximizer and the way he is managing the Product Backlog.

A (business) value starts with a clear product vision. The Product Owner narrates the product vision throughout the Product Backlog. He orders the Product Backlog Items (PBIs) to best achieve goals.

A complementary practice to do so, is to combine “impact mapping” and “story mapping” so that business objectives are related to their coherent PBIs. Business objectives are steps toward maximizing the product value.

Those business objectives are actually Sprint Goals candidates. During the Sprint Planning, the Product Owner discusses the (business) objective that the Sprint should achieve and the related PBIs. The Dev Team decides on the number of items to be selected from the Product Backlog to forecast the functionality it could achieve during the next Sprint. The Scrum Team then crafts the Sprint Goal as an objective that will be met within the Sprint through the implementation of the Product Backlog. The Sprint Goal arising from a business objective is a way to validate value assumptions.

During the Sprint, the Dev Team keeps in mind the Sprint Goal. No changes are made that would endanger the Sprint Goal. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog. The Dev Team focuses on delivering a Done Increment, no later then by the end of the Sprint, that achieves the Sprint Goal. 

The Dev Team uses the Daily Scrum to inspect the progress toward the Sprint Goal. They update their Sprint Backlog as more is learned on how to best achieve the Sprint Goal. It actually gives them flexibility and foster self-organization on how to create the Increment with the expected quality goal. The Sprint Backlog becomes, then, a flexible plan to deliver a Done Product Increment that best achieves the Sprint Goal. The Product Increment is actually a tangible implementation of the Sprint Goal, a tangible way to validate the value assumption.

The Sprint Goal, when it becomes obsolete, would cause the cancellation of the Sprint. The value creation is no longer relevant. The Scrum Team has the courage to not waste efforts and the ethic to not deliver useless features to end users. 

At the Sprint Review, the Scrum Team and the stakeholders inspect progress toward the Sprint Goal by inspecting the Product Increment. The Product Increment must be in a usable state so that the Product Owner can validate the value assumption by releasing it to the market and exposing it to real users to gather feedback. An Increment that achieves the Sprint Goal is a step toward a goal. 

A Done (transparent) Increment supports empiricism. It enables predictability by validating (inspect & adapt) the value assumption expressed via the Sprint Goal. This is the core of Scrum!

The Sprint Goal helps the stakeholders understand what would be valuable for the product. The Scrum Team and the stakeholders collaborate on the next valuable items to optimize the value of the product. They actually collaborate on the subsequent business objective to be validated during the next Sprint. They are shaping the next Sprint Goal candidate.

At the Sprint Retrospective, the Scrum Team inspects how they collaborated during the previous Sprint to achieve the Sprint Goal and adapts their Definition of Done to increase the quality of the product. Adding stringent criteria to their DoD will result in a higher quality implementation of the Sprint Goal into a Done Product Increment, during the upcoming Sprints.

As a closing to this blog post, let’s recap the Sprint Goal “lifecycle” to explore how it is widely present in the Scrum framework:

– emerging from the Product Backlog as a business objective expressed by the Product Owner as a value assumption,

– created at the Sprint Planning by the collaborative work of the Scrum Team,

– going through the Sprint to be implemented into a Done Product Increment by the Development Team as a tangible way to validate the value assumption,

– Helping the stakeholders in knowing what value will be delivered and having an interest in attending the Sprint Review,

– inspected, ultimately, during the Sprint Review, by the Scrum Team and stakeholders, to validate the value assumption,

– during the Sprint Retrospective, improving ways to better implementing it into a Done Increment with higher quality in future Sprints,

– going back to the Product Backlog as a subsequent business objective (Sprint Goal candidate) resulting from the inspection & adaptation done by the Scrum Team and stakeholders.