Tag: Scrum Values

What is Scrum? Uncovering Its True Essence

When we ask people in our training sessions, ‘What is Scrum?‘, their explanations often focus on the mechanics of Scrum, outlining the elements of the Scrum Framework and its iterative approach. This is the same as asking about a specific power tool and then being told about its inner workings. However, what we are really interested in is the tool’s purpose, its usefulness, and how is it used properly.

Yet when people are asked about Scrum, they usually start describing the internal workings of Scrum.

In this blog, we aim to provide a high-level overview of ‘What is Scrum?’. We’ll touch on the mechanics of Scrum, but more importantly, we’ll delve into its essence. Understanding Scrum means grasping not only its rules (e.g. Scrum Framework) but also its purpose – how it serves as a valuable tool for product development, enables business agility, and helps us achieve Agile values and principles.

Let’s now dive into the key elements of Scrum, with a focus on the purpose behind these rules, fostering continuous improvement, self-management, and effective problem-solving in complex environments.

In future blogs, we’ll look to further explore the why and benefits of Scrum. Meanwhile, for further insights into common myths about Agile and Scrum, revisit our earlier discussion in ‘Agile and Scrum: Unravelling the Misconceptions‘.

What is Scrum in a Nutshell

Scrum is a lightweight framework designed to enable business agility, helping people, teams, and organisations create value through adaptive solutions for complex challenges. Comparable to a game’s basic rules, it offers a guiding framework without prescribing exact methods for mastery. While its structure is straightforward, its impact is substantial, grounded in experiential learning and decision-making based on tangible results.

At its core, Scrum is about simplicity and intentional incompleteness. When correctly applied, it maximises value and manages risks in product development.

When teams are genuinely practising Professional Scrum, we expect to see signs of

  • Continuous improvement
  • Self-management
  • Value Useable Increment Every Sprint
  • Value-driven & Product Focus
  • High engagement with stakeholders

These elements are indicative of true alignment with Scrum’s principles and values.

To deeply understand Scrum, the Scrum Guide is an essential resource. It defines Scrum as “a lightweight framework that helps people, teams, and organisations generate value through adaptive solutions for complex problems“.

The Core Elements of Scrum

Let’s have a quick recap of the mechanics of Scrum – the Scrum Framework as outlined in the Scrum Guide with these core elements

  • 3 Accountabilities: Product Owner, Scrum Master, and Developers.
  • 5 Events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.
  • 3 Artifacts: Product Backlog, Sprint Backlog, Increment.
  • 3 Commitments: Product Goal, Sprint Goal, Definition of Done.

Each element of the Framework is crucial in enabling empiricism and fostering self-management, both vital for the effectiveness of Scrum. For instance, Events in the Scrum Framework provide a formal opportunity for inspection and adaptation.

Common questions asked regarding the Scrum Framework are Event timeboxes and Product Backlog Refinement, so let’s clarify those quickly.

Events Are Timeboxed

In Scrum, all events are time-boxed. Timeboxing means that each event has a set duration with a clear endpoint, although participants may leave early if the objectives of the event are achieved. This ensures that events maintain focus, commitment, and effectiveness

For a one-month Sprint, the event timebox lengths are:

  • Sprint Planning: 8 hours.
  • Daily Scrum: 15 minutes.
  • Sprint Review: 4 hours.
  • Sprint Retrospective: 3 hours.

Note that for shorter Sprints, these timeboxes can be reduced accordingly, with the exception of the Daily Scrum.

Product Backlog Refinement is an Activity, Not an Event

Product Backlog Refinement is a continuous and crucial activity within the Scrum framework. Performed by the Scrum Team, this process is integral to ensuring that Product Backlog items are clearly understood, refined, and prepared for upcoming Sprints.

Items at the top of the Product Backlog are brought to a ‘Ready’ state, signifying the team’s clear understanding of their purpose and the feasibility of completing them within a Sprint.

This ongoing refinement process underpins Scrum’s focus on business agility, enabling teams to respond adaptively to complex challenges and continuously deliver value-driven, usable increments in alignment with stakeholder needs and expectations

Principles of Scrum: Empiricism

Scrum is grounded in empiricism, emphasising that knowledge comes from experience and that decision-making is based on observations. In Scrum, teams are engaged in a continuous cycle of learning and adapting, rooted in real-world feedback and experiences.

The three pillars of empiricism – Transparency, Inspection, and Adaptation – guide this process:

  • Transparency: We all know what is going on
  • Inspection: Continuously checking work as you do it.
  • Adaptation: OK to change tactical direction based on the insights gained from inspections

Empiricism in Scrum is a catalyst for ongoing improvement, allowing teams to quickly adapt based on customer feedback, evolve their methods, and effectively navigate risks. This process is pivotal for accelerating product development and delivery, enhancing value and predictability.

Scrum Values: The Lifeblood of the Framework

Central to Scrum are its values – Courage, Focus, Commitment, Respect, and Openness.

These are not mere words; they are the lifeblood of Scrum and enable its effectiveness. Without these values, Scrum becomes a mechanical process, devoid of its true spirit.

Scrum Values - The Lifeblood of the Framework

‘Done’ Increment: The Essence of Scrum

At the heart of Scrum lies the ‘Done’ Increment. This is a non-negotiable element and new teams might find this challenging. Achieving a ‘Done’ Increment every Sprint signifies adherence to Scrum’s principles and commitment to delivering value.

  • Empirical Process Control: The ‘Done’ Increment is crucial for reflecting true progress, much like a thermostat’s reading is essential for temperature regulation.
  • Focus on Quality and Value: Shifting towards delivering high-quality, valuable increments that align with the Definition of Done.
  • Enhancing Transparency and Trust: A consistent ‘Done’ Increment builds transparency and trust, showing real progress and aligning team and stakeholder expectations.

Failing to achieve this ‘Done’ Increment indicates that a team isn’t fully practising Scrum. It signals a need to reassess their approach to truly embrace the framework’s core principles.

To deepen your understanding of the ‘Done’ Increment and its role in enhancing product delivery and team performance, delve into our detailed discussion in ‘Why Product Owners Want a Perfect Definition of Done.’

For guidance on crafting a Definition of Done that aligns with value creation and usability, be sure to check out our blog post ‘Definition of Done: Where to Start?

Scrum: The Thermostat for Product Development

Scrum’s focus on delivering a ‘Done’ Increment is like a thermostat for product development:

  • Empirical Approach: Just like a thermostat uses temperature readings to adjust the environment, Scrum uses the ‘Done’ Increment to guide decision-making. This ensures decisions are based on actual product progress and value.
  • Value Gauge: The ‘Done’ Increment tells us more than just progress; it’s a measure of the product’s value to customers. It’s like checking the temperature to see if adjustments are needed.
  • Informed Decisions: This Increment isn’t just for tracking team progress; it’s crucial for big decisions. Should the team continue as is, change direction, or stop? It’s like using a thermostat’s reading to decide if you need more heating or cooling.

In short, in Scrum, the ‘Done’ Increment helps teams make informed, value-based decisions on what is observed, just as a thermostat helps regulate the room temperature based on the temperature it measures.

Scrum The Thermostat for Product Development

Embracing Self-Management and Continuous Improvement

When effectively implemented, Scrum fosters self-management and continuous improvement. These aspects are intricately woven into Scrum’s fabric, primarily through its framework elements – Events and Accountabilities.

  • Self-Management within Boundaries: The Scrum framework provides clear boundaries through its defined events and accountabilities elements. When these accountabilities are correctly understood and implemented, they create a space for teams to self-organize, make decisions autonomously, and take ownership of their work. Misinterpretation or misuse leads to a breakdown in self-management, undermining the essence of Scrum.
  • Continuous Improvement via Scrum Events: Each Scrum event is purposefully designed to foster an environment of continuous improvement. A specific opportunity for teams to inspect and adapt. If these events are misunderstood or misapplied, the potential for continuous improvement is significantly diminished.

The proper understanding and application of Scrum’s elements are crucial for fostering a true Professional Scrum environment where self-management and continuous improvement are not just ideals but practical realities.

A Mirror, Not a Magic Wand

Scrum isn’t a magic solution that fixes everything. Rather, it serves as a revealing mirror, reflecting the true state of an organisation and its teams. It clearly highlights both strengths and areas needing improvement. Embracing Scrum involves accepting its insights and challenges head-on, resisting the temptation to alter Scrum itself simply because it exposes uncomfortable truths or demands significant change.

  • A Catalyst for Business Agility: Scrum drives adaptability and responsiveness, essential for business agility.
  • Dependent on Organisational Commitment: Success with Scrum hinges on embracing change and learning from failures.
  • Focus on Sustainable Improvement: Scrum emphasizes long-term growth and adaptability for continuous improvement.

Conclusion: Scrum, More Than Just a Framework

To conclude on the question ‘What is Scrum?’, it’s essential to recognise that understanding Scrum can be likened to understanding the rules of a sport like football. While knowing the rules is relatively simple, true mastery is achieved through effectively applying these rules to build an effective and successful team.

In a similar vein, while Scrum may be straightforward in its structure, its real strength is unlocked through the application of its principles and values, along with an awareness of the many complementary practices that can be integrated with Scrum to maximise value delivery.

Merely implementing Scrum as a framework misses the larger point; when correctly executed, it becomes a powerful catalyst for business agility and quality excellence. It’s about employing and comprehending a series of guidelines that foster a more responsive, innovative, and effective way of working. This pursuit of enhancement is continuous and ever-evolving, much like the game of football, where strategies, skills, and teamwork keep evolving and improving.

To improve your proficiency in Scrum, b-agile provides a range of Scrum.org courses to help. These courses are designed to help and reap the benefits of proper application of Professional Scrum:

Other insightful blog posts you may find interesting as read this one:

Commitments and forecasts when using Scrum

Commitments and forecasts when using Scrum

A regular topic of conversation within my Scrum training courses revolves around commitments and forecasts when using the Scrum framework. Frequently we uncover significant and important misunderstandings about what Scrum Teams can commit to and what they cannot.

The most often talked about example refers to those Product Backlog Items which are taken into a sprint by the developers and which then seem to turn into a hard commitment such that if not all those Product Backlog Items are done then something is wrong and a possible belief that the Scrum Team has failed.

This article is an attempt to help debunk at least this one myth whilst using the Scrum framework to build complex products and an overall recap around commitments versus forecasts in general across some of the evolutions of the Scrum Guide over time.

Let’s be clear on what commitment actually means:

A quick online search gives these two definitions for ‘commitment’:

  • “The state or quality of being dedicated to a cause, activity”
  • “An engagement or obligation that restricts freedom of action”

These are actually quite different in meaning. The first relates to dedication. “I couldn’t fault the team for their commitment”. The second relates to a future state that we are promising to achieve, a guarantee, a promise.

Let’s now explore some of the key elements around commitments and forecasts from the Scrum Guide as it has evolved over time.

Scrum Guide 2010

  • The Team has committed to a Sprint Goal, and to these Product Backlog items

Within this first version of the Scrum Guide, there is a reference to the fact that there is a firm commitment that all items taken into a Sprint are to be done. If not all items selected are done by the end of the Sprint then maybe there has been some kind of issue worth exploring further. Have we therefore failed as a team since we did not achieve all that we promised?

A potentially interesting point around this is the fact that probably a lot of teams currently using Scrum today have never read this original 2010 version but yet still have a strong belief that all items selected must be done or else something has gone wrong. If this has not come about from reading this version then could it be due to the culture and behaviours already inherent within the wider organisation?


Scrum Guide 2011

Thankfully this use of commitment did not stay long and was updated in 2011.

  • …the Development Team forecasts the Product Backlog items it will deliver in the Sprint” 
  • …Development Team to forecast what it believes it can do in the upcoming Sprint” 
  • “…Commit is now forecast

Early on there was a realisation that when dealing with complexity and significant amounts of unknowns that it is simply not possible to perfectly plan all that is to be done even within the time-box of just one Sprint.
 

Scrum Guide 2016

The 2016 version introduced us to the Scrum Values and one of these is commitment.

In this regard, it means (but is not limited to) committing to being professional, committing to quality, committing to helping and supporting each other, committing to working on tough problems, and committing to our goals. This touches on both meanings around commitment. Both on the dedication and effort perspective whilst also hooked into the promise of focussing on delivering future goals.
 

Scrum Guide 2020

The 3 commitments were then added in 2020.

Each of the core 3 artefacts now has a corresponding commitment which all help bring transparency to the artefact they are a commitment for – so for the Increment we have the Definition of Done, for the Product Backlog we have the Product Goal and for the Sprint Backlog we have the Sprint Goal.

Developers adhere to the Definition of Done…..that’s completely non-negotiable. That’s a firm commitment. A promise.

The Product Goal and Sprint Goal help Scrum Teams focus on current progress towards a future state which serves empiricism. A Scrum Team is committed to working on one Product Goal at a single point in time and either achieving or abandoning that Product Goal before then moving to the next one.

The Sprint Goal is created by the whole Scrum Team during Sprint Planning (note – the whole Scrum Team and not just the Product Owner). The developers are then committing themselves to creating at least one usable increment by the end of each Sprint that achieves that single Sprint Goal. This is their commitment. They are not committing to completing all the Product Backlog Items taken into a Sprint. As the Sprint progresses and as more is learnt about this work then so the Sprint Backlog is emergent. There has to be a level of flexibility that the Sprint Goal provides. The Scrum Guide makes this super clear:

  • …the Sprint Goal is a commitment by the Developers, it provides flexibility in terms of the exact work needed to achieve it” 

The Sprint Goal is the outcome we are after achieving….the Product Backlog Items selected to achieve that Sprint Goal forms the output. Scrum Teams should always look to maximise outcomes and minimise output. The Sprint Goal is their commitment…..the selected items are their forecast.


In summary…

Be clear what you commit to and what instead must be a forecast due to the inherent nature around complex product delivery.

Commit to goals. Commit to doing the best you can at all times. Commit to helping those around you. Commit to building products of the highest quality. Commit to the Definition of Done.

Remember that Product Backlog Items taken into a Sprint are very much a forecast and not a commitment. Forecast longer term plans with the expectation that these will continue to change and evolve as more insights emerge over time.

Ultimately understand and be professional about what you can and cannot make commitments against.

Want to learn more and talk further about commitments and forecasts, professional Scrum or indeed any element of the Scrum Framework? Check out our upcoming courses on our course schedule with b-agile. We offer both public and private courses to fit your needs.