Tag: Scrum

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:

Should I Become a Scrum Master? 10 Questions to Guide Your Decision

Should I Become a Scrum Master? 10 Questions to Guide your Decision

A common question we are often asked is, “Should I become a Scrum Master?”, in particular by individuals transitioning from traditional project management roles or those who are contemplating a shift in their career. Of course, this question hinges on multiple factors. But building on our previous blogs, What is a Scrum Master and Giving Back: considerations for a new Scrum Master, let’s delve into some questions that may aid your decision-making process.

10 Guiding Questions To Help Your Decision

Embarking on the Scrum Master journey entails nurturing a passion for people, advocating for agility, and assisting organisations in adopting an outcome-focused approach. It’s about wholeheartedly embracing continuous improvement and proactively facilitating change. As you contemplate this meaningful transition, here are ten reflective questions designed to echo the core attributes and skills integral to a successful Scrum Master.

1. Are You Prepared to Lead by Example?

A Scrum Master embodies the principles of Scrum, setting a high standard for values like commitment, courage, focus, openness, and respect. Leading by example fosters a positive team culture, promoting trust and collaboration, which are essential for building healthy team relationships. This trait moulds a collaborative and accountable team culture.

2. Can You Foster a Safe and Open Environment?

Creating an atmosphere where team members feel safe to express their opinions and ideas is crucial for innovation and problem-solving. Encouraging open discussions and employing coaching techniques are key to creating a psychologically safe environment, pivotal for both team performance and satisfaction.

3. How Effective Are You at Facilitating Discussions?

Clarity in discussions is crucial for maintaining a smooth flow of work and ensuring the team is aligned on their goals. As a Scrum Master, facilitating discussions to reach a consensus is part of your realm. If you’re keen on mastering the art of facilitation, the Professional Scrum Facilitation Skills (PSFS) course could be your stepping stone. It’s crafted to provide you with valuable insights and techniques, empowering you to steer your team towards consensus with ease.

4. Can You Intuitively ‘Read the Room’?

Being able to gauge team dynamics and respond accordingly is essential for maintaining a harmonious team environment. This ability is key to preempting issues, tuning into team morale, and steering interactions that nurture a positive team culture.

5. Are You Comfortable Allowing Teams to Self-Manage?

It’s essential for Scrum Masters to trust their teams to self-manage while providing the necessary support for success. This fosters a sense of ownership and empowerment among team members, which is crucial for achieving Agile principles of self-management and continuous improvement.

6. How Do You Approach Conflict and Resolution?

Conflict is inevitable, but a constructive approach towards resolution fosters a culture of growth and learning. Good conflict resolution skills are central to maintaining a positive team environment and ensuring that disagreements pave the way for better solutions, not discord.

7. Can You Embrace Failure as a Step Towards Growth?

Being comfortable with failure and viewing it as a learning opportunity is crucial for both personal and team growth. This mindset nurtures a culture of experimentation and learning, crucial for fueling continuous improvement and innovation in Agile setups.

8. Are You Committed to Genuine Care for Your Team?

Empathy and understanding are at the heart of a Scrum Master’s role, facilitating the building of trust and supporting team members in their Agile journey. Such genuine care cultivates a supportive environment where team members feel valued and are motivated to give their best.

9. Will You Stand Against Organisational Impediments?

Advocating for your team and ensuring organisational impediments are addressed is a key responsibility of a Scrum Master. Taking a proactive stance in tackling these impediments clears the way for the team, smoothing the path towards goal achievement.

10. Are You Prepared to Help Move the Shift to a New Way of Working?

Shifting to a new way of working is at the heart of a Scrum Mastery, especially in complex domains. It’s a journey from traditional control-centric approaches to an outcome-driven mindset. Here’s a snapshot of what this shift entails:

  • Letting Go of Control: Foster a culture where the focus shifts from micromanagement to trusting the team’s collective intelligence and guiding them towards common goals.
  • Educating Others: Part of the shift involves educating and aligning stakeholders, teams, and other organisational members on the new approach and its value in delivering meaningful outcomes.
  • Measuring the Right Things: It’s not just about on-time delivery anymore. Encourage a focus on delivering value, achieving goals, and promoting continuous learning and improvement.
  • Promoting an Experimentation Mindset: Encourage a mindset of exploration and adaptation in complex domains. This approach fosters a culture of experimentation, learning from failures, and tweaking strategies to meet objectives better.

By embracing these aspects, you’re not just navigating through complexity, but championing a shift towards a more effective, outcome-driven way of working.

The Value of Proper Training Aspiring Scrum Masters

It’s disheartening but true – the field is crowded with individuals claiming the title of Scrum Master without having the necessary training or even a basic understanding of the role or accountability. This has led to many organisations undervaluing the impact a Scrum Master can have.

Standing apart in such a scenario requires more than just a title. A solid grounding in Scrum principles, coupled with reputable training, can set you apart from the crowd and showcase the true value of a Scrum Master.

So, as you contemplate the question, “Should I Become a Scrum Master?”, consider how being well-prepared can not only elevate your role but also significantly contribute to your organisation’s Agile journey.

Scrum Master Salaries: A Motivating Factor?

Considering a career shift towards becoming a Scrum Master also brings the question of remuneration. The average salaries for Scrum Masters in primary markets of Europe vary based on the country.

Here’s a breakdown of the average 2023 salaries in the UK, Germany, the Netherlands, and France:

  • UK:
    • Average Salary Range: £45,000 to £70,000
    • Glassdoor Average: £48,003
    • Payscale Average: £61,000
    • Talent.com Average: Up to £74,000
  • Germany:
    • Average Salary: €59,554​1​.
  • Netherlands:
    • According to one source, the average salary for a Scrum Master in the Netherlands is €58,000​2​.
    • Another source states that the average salary is around €60,000 to €70,000​3​.
  • France:
    • Glassdoor indicates an average base pay of €57,468 per year in Paris​4​.
    • SalaryExpert reports an average base salary of €64,958 per year​5​.

This data suggests that Scrum Masters can expect a competitive salary in these primary European markets, with variations depending on the specific country and city.

Are You Ready to Be a Scrum Master?

A Scrum Master wears many hats – they are facilitators, coaches, problem-solvers, and advocates for their teams. The essence of a Scrum Master lies in their dedication to fostering an environment where teams can thrive, innovate, and delight their customers.

With a profound understanding of Scrum, a Scrum Master guides their team and organisation towards continuous improvement, steering the way towards delivering value seamlessly.

The demand for proficient Scrum Masters continues to soar. Are you geared up to step into this pivotal role? Your journey towards becoming a Scrum Master could begin with gaining a deeper understanding of Scrum and honing your Scrum Master skills through the Professional Scrum Master course.

Take the Leap:

Poised to transition into a role that’s rewarding both personally and professionally? Our Scrum Mastery training is your springboard to a fulfilling Scrum Master career. Embark on this enriching pathway today!

What is a Scrum Master? The True Role Revealed

What is a Scrum Master

Inspired by the disconcerting misconceptions we’ve seen recently and from Eminem’s iconic line, ‘Will the real Slim Shady please stand up?’ – we felt compelled to write this blog “What is a Scrum Master?” and ask:

May I have your attention, please?
Will the real Scrum Master please stand up?
I repeat,
Will the real Scrum Master please stand up?
We’re gonna have a problem here

We’ll be addressing a troubling trend that has caught our attention: the persistent misunderstandings about what a Scrum Master truly is and does. Despite Scrum being around for over 25 years, it’s disheartening to see that many still haven’t fully grasped its core purpose. Instead, they continue to perpetuate outdated notions, treating the Scrum Master as nothing more than a rebranded Project Manager.

Recently, we’ve encountered a slew of misleading LinkedIn posts that inaccurately portray Scrum as merely another Project Management framework. What’s more alarmingly, these posts were also promoting Scrum courses. One post brazenly asserted, ‘Discover how Scrum can empower you to become a master of project management.’ This not only perpetuates the ‘Feature Factory’ (mini-waterfall) mindset but severely undermines the fundamental purpose, values and principles of Scrum.

In this blog, we’ll look to shed light on the true essence of a Scrum Master and help clear up this misconception.

Contrary to popular belief, a Scrum Master is an accountability, not a role, within the Scrum Team. They serve as a ‘guiding mirror,’ reflecting not what the team wants to see, but what it needs to confront: its untapped potential for business agility, self-organization, and empirical decision-making.

If you’ve ever felt that your organization isn’t genuinely practising Scrum or that your Scrum Master isn’t fulfilling their true accountability, you’re not alone. Let’s clear the air and help the real Scrum Master—please, stand up!

Scrum Master

Understanding Scrum Master Accountability

Before we look at answering the question”What is a Scrum Master?” let’s quick recap on what Scrum is first. Scrum is a lightweight framework that consists of 3 accountabilities, 5 events, and 3 artefacts. One of these key accountabilities is the Scrum Master!

Prior to the 2020 update of the Scrum Guide, these were referred to as “roles.” The terminology was updated to “accountabilities” to help eliminate misunderstandings that one person could not hold more than one accountability. So does that mean we can play more than one accountability? More on this later.

Referring back to the Scrum Guide about Scrum Master accountability, it clearly defines it as the following:

The Scrum Master is accountable for establishing Scrum as defined in the Scrum Guide. They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization.”

The Scrum Master is accountable for the Scrum Team’s effectiveness. They do this by enabling the Scrum Team to improve its practices within the Scrum framework.”

In this way, the Scrum Master acts as the catalyst propelling the team toward excellence, fueled by Scrum’s essence of embracing change, fostering learning, and nurturing continuous growth.

Scrum Master is not a Project Manager

One of the most pervasive misunderstandings about the Scrum Master’s accountability lies in the mistaken belief that they are simply Project Managers by another name. This misconception is not only misleading but also undermines the essence of Scrum and the unique value that a Scrum Master brings to the table.

The Scrum Master is not a Project Manager in agile clothing. They don’t manage budgets, schedules, or resources. Their primary focus is not on delivering the project on time and within scope but on fostering an environment where the Scrum Team can thrive and deliver value iteratively and incrementally.

Scrum Master vs Project Manager

AspectScrum MasterProject Manager
AccountabilityFosters Scrum adoption, team understanding, and continuous improvement within the Scrum frameworkManages the project’s scope, schedules, and budgets to meet project objectives.
Decision MakingEmpowers the team to be self-managed and encourages data-driven decisionsMakes decisions, delegates tasks, and oversees project execution.
ApproachGuides the team to embrace empiricism, value-driven outcomes, and cultivating a culture of continuous improvement.Takes a directing role, manages resources, and applies established project management methodologies.
Leadership StyleServant LeadershipCommand and Control Leadership
Change ManagementEmbraces change and uncertainty.Has a defined scope and minimizes deviations from the plan.
Adaptive ApproachEmphasizes adaptability and a flexible approach to achieve desired outcomes.Follows predefined project plan to meet predetermined success criteria.

In line with the Scrum Guide’s emphasis, the Scrum Master’s accountability extends to helping everyone—both within the Scrum Team and the broader organization—understand the theory and practice of Scrum. They do this by:

  • Educating and Coaching: The Scrum Master takes on the role of an educator and coach, helping team members and stakeholders understand the principles and values that underpin Scrum. This goes beyond mere rule-following and dives deep into the philosophy of agile methodologies.
  • Facilitating Scrum Events, If Needed: Contrary to another common misconception, the Scrum Master facilitates Scrum events like Sprint Planning, Daily Scrum, or Sprint Retrospectives only if needed. Their role is to ensure that these events are effective and true to the spirit of Scrum, thereby enabling the team to inspect and adapt.
  • Removing Impediments: Unlike a Project Manager, who may try to control external variables to stick to a plan, the Scrum Master focuses on removing obstacles that hinder the team’s ability to deliver value.
  • Promoting Self-Organization: The Scrum Master empowers the team to take ownership of their work, encouraging self-organization rather than dictating how things should be done.

By focusing on these aspects, the Scrum Master not only upholds the integrity of the Scrum framework but also facilitates the team’s journey toward continuous improvement and high performance. They are not there to serve the project; they are there to serve the team and, by extension, the organization in its pursuit of agility and excellence.

Can You Play More Than One Accountability?

The short answer is yes, but it’s not without its challenges and is highly dependent on context. To illustrate this, let’s consider the analogy of a Viking boat navigating through treacherous waters.

Impact if Playing Different Scrum Accountabilities
  • Product Owner (PO): Positioned at the front, the PO focuses on maximizing value and strategizing for the journey ahead.
  • Developers: In the middle, they are the heart of delivering value through completed work.
  • Scrum Master (SM): At the back, the SM supports the Developers, the PO, and the broader organization.

The Navigational Dilemma (PO and SM)

If leaning towards the PO accountability, who supports the Developers and drives organizational change? Conversely, if leaning towards the SM, who’s at the front guiding the ship to maximize value?

A Different Set of Challenges (SM and Developer)

The SM, being part of the Scrum Team, can monitor both the PO and the Developers. However, if engrossed in development, who focuses on broader organizational aspects? The effectiveness of this combination often depends on the team’s maturity and the nature of the work.

In essence, taking on multiple accountabilities is a balancing act that can dilute the effectiveness of each. For you and your team to gain a deeper understanding of accountabilities in Scrum, you may find our resource ‘Know your Scrum Accountabilities?‘ helpful.

The True Essence of a Scrum Master

Let’s delve into the core attributes, tools, and philosophies that define a Scrum Master. By understanding these elements, we can appreciate the Scrum Master’s unique position as a catalyst for change, a servant leader, and a champion and guardian of Scrum values and principles.

Characteristics of an Effective Scrum Master

These simple mantras help them avoid prescribing solutions and instead shine a light for the team to inspect and adapt.

While truly great Scrum Mastery is situational, some traits are commonly found:

  • Servant leadership
  • Influence without authority
  • Coaching mindset
  • Courage to challenge the status quo

By putting the team’s needs first and helping unlock their potential, Scrum Masters can facilitate amazing outcomes.

Embracing Servant Leadership

The Scrum Master embodies the principles of servant leadership. They focus on the growth and well-being of their team members, rather than wielding power for its own sake. For a Scrum Master to be a leader, they move away from coordinating individuals and towards coaching people in Scrum and positive team behaviour. They enable self-management within Scrum Teams.

Move Away FromMove Toward
Coordinating individualsCoaching people in Scrum
Providing answersEnabling self-management
Investing in outcomesHelping manage Product Backlogs
DeadlinesFocusing on flow and value
Prescribing solutionsImproving the Definition of Done
Fixing problemsGuiding Teams to discover what works

The 6 Stances of a Scrum Master

Scrum Masters don’t adhere to a one-size-fits-all methodology. Instead, they have a variety of intervention choices and behavioral stances, each tailored to specific situations. These 6 stances act as a heuristic guide for the Scrum Master’s decision-making process. There’s no universally ‘right’ choice—only what the Scrum Master deems most effective in the given context.

StanceDescription
The FacilitatorHelps the team reach consensus during discussions.
The CoachHelps the team improve its practices and behaviors.
The Servant LeaderServes the team by removing impediments.
The MentorProvides guidance based on experience.
The TeacherEducates the team on Scrum principles.
The Change AgentDrives change within the organization.

For those keen on exploring further into the intricacies of these stances and their practical applications, Barry’s blog post, ‘The 6 Stances Of A Scrum Master,’ is an essential read. Additionally, our Professional Scrum Master and Professional Scrum Master II courses provide thorough insights and hands-on experience.

An illustration of these varied stances in action can be found in our Where to Start with Scrum. Is Value Stream Mapping Your Answer? blog and the real-world scenario used there.

Living the Scrum Values

The Scrum values of Courage, Focus, Commitment, Respect, and Openness are the lifeblood of the Scrum framework. These values are something the Scrum Master can fall back on to help their team. For instance, if a team is missing a Sprint Goal or Product Goal, it could be a sign that they are lacking in Focus and Commitment. The Scrum Master can then use these values as a guide to help the team realign.

Essential Scrum Master Mottos

Scrum Masters have mottos and heuristics they live by, such as:

  • Let the team decide
  • Reveal, don’t resolve
  • Ask don’t tell
  • Pull, not push
  • Art of the possible
  • Curiosity with positive intent

Scrum Master’s Essential Toolkit

The Scrum Master’s toolkit is grounded on two core tools:

  • Empiricism: Used often to bring issues to light and guide the team in problem-solving. For instance, any development bottlenecks are made visible so the team can inspect and adapt.
  • Self-Management: Empowers the team to own their tasks and overcome challenges. When an obstacle arises, the Scrum Master facilitates a discussion for the team to find their own solutions, fostering self-management.

To see an example of the use of empiricism to help teams, read our post on the Definition of Done, Where to Start?

Complementary Practices:

Besides core tools like empiricism and self-management, Scrum Masters often add additional complementary practices to their toolbox. While not part of Scrum, they may be useful in helping the team’s effectiveness and maximise the benefits of Scrum.

  • Product Owner Practices: Assist the Product Owner in maximizing value through effective goal-setting, vision alignment, and backlog management.
  • Facilitation Techniques: Essential for running effective Scrum events and resolving conflicts.
  • Technical Practices: Help Developers meet the Definition of Done and ensure high-quality deliverables.
  • Flow Practices: Optimize the flow of work, enhancing transparency and facilitating better conversations about progress.
  • And Many More: The toolkit is ever-expanding to include various practices that help maximize the benefits of Scrum.

As the saying goes: “The Scrum Master reveals, but doesn’t resolve.” Their ultimate goal is to enable collective learning and improvement, thereby unlocking the team’s full potential.

Final Thought on What Is a Scrum Master

In the spirit of Eminem’s famous lyric “Will the Real Scrum Master please stand up?” – it’s time to dispel the myths and embrace the true accountability of a Scrum Master. They are not traditional managers, project administrators, or Jira experts. They are catalysts for change, guiding mirrors that illuminate the path to business agility, self-organization, and value-driven outcomes.

A Scrum Master does this by embracing the Scrum framework and its pillars of empiricism. They engage with the tools of self-organization, Scrum values, stances, and mottos to help the team inspect, adapt, and improve. Their core duty lies in facilitating adherence to the Scrum framework, promoting continuous improvement, and empowering the team to unlock their boundless potential.

If you’re inspired to elevate your understanding of Scrum to a professional level, don’t miss our certified Scrum.org Professional Scrum Master training.

If you found this article valuable in understanding the Scrum Master Accountability, please consider sharing it. Your share could be the catalyst for someone’s agile transformation and help clear up persistent misconceptions. Thank you for reading

Technical Debt: Understanding & Overcoming the Silent Threat

Technical Debt: Understanding and Overcoming the Silent Threat

Technical debt, a term coined by Ward Cunningham, one of the authors of the Agile Manifesto, likens problems with code to financial debt. It’s OK to borrow against the future, as long as you pay it off. Technical debt has both visible and invisible elements. While businesses often monitor bugs, the invisible element can have a significant impact, potentially leading to products destined for the scrap heap.

Understanding and effectively managing technical debt is crucial for maintaining business agility, and ensuring product quality, performance, and the long-term viability of your offerings. Join us as we delve into the intricacies of technical debt and discover strategies to mitigate its adverse effects, securing a promising future for your products.

Technical Debt

What is Technical Debt?

Technical debt refers to the compromises made in software development that may expedite delivery in the short term but create additional work and complexity in the future. It’s akin to financial debt, where borrowing now requires interest payments later.

What Causes Technical Debt?

The causes of technical debt are multifaceted and often stem from various factors in the development process. Some common causes include:

  • Rushed Development: When teams are under pressure to meet tight deadlines, they may take shortcuts, leading to suboptimal code quality.
  • Lack of Collaboration: Inadequate communication between developers, testers, and other stakeholders can lead to misunderstandings and poor design decisions.
  • Inconsistent Coding Standards: Without clear and consistent coding standards, the codebase can become messy and difficult to maintain.
  • Obsolete Technologies: Using outdated technologies or libraries can make the codebase rigid and challenging to update.
  • Insufficient Testing: Lack of thorough testing can leave hidden defects that turn into technical debt over time.
  • Ignoring Refactoring: Failing to refactor or improve the code regularly can lead to a buildup of inefficient and tangled code.
  • Business Priorities: Sometimes, business needs may prioritize new features over code quality, leading to compromises that result in technical debt.
  • Inadequate Skillset: If the development team lacks the necessary skills or expertise, they may produce code that is not up to the standard, contributing to technical debt.
  • Ignoring Feedback: Not taking into account feedback from code reviews or ignoring

Types of Technical Debt

Understanding the different types of technical debt can help in identifying and addressing the specific challenges your organization may be facing. Here are some common types:

  • Deliberate Technical Debt: This is incurred intentionally, often to meet a deadline or specific business need. It’s like taking a calculated risk, with the understanding that it will be paid back later.
  • Accidental Technical Debt: This occurs unintentionally due to a lack of knowledge, oversight, or unforeseen complexities. It might include coding errors, suboptimal design choices, or outdated documentation.
  • Outdated Technical Debt: As technology evolves, certain parts of the codebase may become obsolete or incompatible with newer technologies. This type of debt requires updates to stay current and maintainable.
  • Testing Debt: Skipping or skimping on testing can lead to hidden defects and vulnerabilities. This debt can be costly to fix later, especially if it leads to customer-facing issues.
  • Design Debt: This involves compromises in the system’s architecture or design, leading to a lack of scalability, maintainability, or performance. It often requires significant refactoring to resolve.
  • Documentation Debt: Incomplete or outdated documentation can hinder future development efforts, making it difficult for new team members to understand the codebase and contribute effectively.
  • Tooling Debt: Using outdated or inefficient tools can slow down development, testing, and deployment processes. Investing in modern tooling can pay off by increasing efficiency and quality.

By recognizing and categorizing technical debt, teams can prioritize their efforts and apply targeted strategies to reduce and manage it effectively.

What are the Impacts of Technical Debt?

Let’s first have a look at the cost of change from a technical perspective. The assumption here is that the red waterfall curve is using BDUF (Big Design Up Front) where the design is perfected before construction. This is highly unrealistic in the high novelty complex adaptive domain of software delivery. In software, delivery design is only validated through working (releasable) software.

Impacts of Technical Debt?

Technical debt can have profound effects on the development process, product quality, and overall business success. Let’s explore some of the key impacts:

Unreasonable Cost of Ownership

It should come as no surprise that the most common scenario we see today is a growing cost of ownership. At first, the impact is low but soon starts to build momentum. The ability to maintain, support, and add new features to the product becomes more complex and more expensive over time. This leads to a higher cumulative cost of ownership.

Unreasonable Cost of Ownership

For example, if we built feature A in month 1 and the same feature A in month 18 with a good level of quality where the development teams are maintaining a sustainable pace, then the cost of developing that feature would be comparable.

With high technical debt where the development teams are fighting against the design, the costs will grow rapidly over time. This means:

  • The cost (or difficulty) of change increases, eventually to the point of unmaintainability.
  • The ability to respond to the needs of customers decreases, making them extremely unhappy.
  • The predictability of results decreases. Estimating effort and complexity becomes more difficult. This decreases transparency and can impact trust.

Signs of Unhealthy Products with Technical Debt

Recognizing the signs of technical debt is the first step in addressing the problem. Let’s have a look at a few behaviours you may recognize:

  • Weak Definition of “Done”: Where it’s not well-defined and represents quality for the product. Understanding what constitutes a “done” state is crucial for maintaining quality and avoiding technical debt. Learn more about why Product Owners want a perfect Definition of Done.
  • Slowing Rate of Productivity: Increased cycle times to add similar-sized new features.
  • Stressful Releases: Development teams go into crunch mode, working through lengthy change windows, executing scripts, manually deploying and configuring components, investigating incidents, and fixing defects.
  • Untouchable Applications: Aging libraries and unnecessary dependencies make applications we are scared to touch.
  • Increasing Time for Incident Investigations: More time spent dealing with incident investigations and fixing defects.
  • Low Automated Testing: Lack of an extensive test suite forces repetitive, slow, and error-prone manual testing.
  • Fragile and Tightly Coupled Components: Violation of good design principles, duplicated code, tangled architecture, and unnecessarily complex dependencies.
  • Lack of Automation: Missing test, build, and deployment automation, plus anything else that could be automated but is done manually today.
  • Long Feedback Loops from Continuous Integration: Build, Test, Deploy.
  • Slow, Ineffective Tools: Tools that hinder rather than help the development process.
  • Long-Lived Branches: Causing merging hell and increased delivery risk through late integration.
  • Missing or Outdated Technical Documentation: Important documentation that is either missing or out-of-date.
  • Unnecessary Technical Documentation: Maintaining documentation that is no longer needed.
  • Insufficient Test Environments: Missing or not enough test environments causing delays in delivery and/or reduction in quality.
  • Defects or Bugs Trending Up: Great scrum teams fix bugs as they are found and don’t let them accumulate. If the number of open or escaped defects is trending up over time, it’s an indicator of lower quality and technical debt. In the cumulative flow diagram, we can see over time that the average number of open defects (vertical) is growing over time and the average time to fix (horizontal) is increasing.
Defects or Bugs Trending Up

Who Suffers in this Vicious Circle of Deceit?

The consequences of technical debt are far-reaching and affect various stakeholders in the organization. The impact includes:

  • Customers face defects, missing features, and poor service resulting in lower satisfaction.
  • 1st line support teams create more incidents, increasing demand on operational support teams.
  • Products with poor design are more complex than needed, have more dependencies, and require more infrastructure, more development time, and more support time to run.
  • The organization, teams, and leadership get bad publicity due to defects, delays, security issues, or outages.
  • Development teams must deal with the bad work of other developers, causing attrition and loss of talent.
  • As it gets worse, customers complain about slow delivery, increasing pressure to take more shortcuts, which increases technical debt.

Options for Dealing with Technical Debt

Unfortunately, by the time organizations are paying attention, none of the options are good. However, recognizing the problem and making it transparent can lead to improvement:

  • Do Nothing: And it gets worse.
  • Re-Place/Re-Write the Software: Expensive, high risk, doesn’t address the root cause problem. Rinse and repeat in around 2 years’ time. Some organizations have successfully replaced legacy systems by adopting Agile methodologies and focusing on continuous improvement.
  • Stop Creating More Technical Debt: Systematically invest in incremental improvement. This approach requires a commitment to quality and may involve investing in training, tools, and processes that support best practices.
  • Make Technical Debt Transparent: Utilize tools like SonarQube, Test Coverage, Dependency Graph & Analysis Tools, Static Analysis Tools, etc., to make the debt visible and manageable. (More on this in an upcoming blog)

For a comprehensive approach to managing technical debt and improving efficiency, our blog on Value Stream Mapping: Your Answer offers valuable insights.

Empower Your Teams to Stop Your Product Hitting the Scrap Heap

Technical debt can be a significant barrier to delivering value and achieving business agility. Empowering your teams with the right knowledge, tools, and support is crucial to overcoming this challenge. Here are some options on how you can equip your teams to tackle technical debt effectively:

Knowledge through Training

  • Professional Scrum Master (PSM): Educate Scrum Masters and Leadership teams on the impacts of Technical Debt and how to manage it. Learn more
  • Applying Professional Scrum for Software Development (APS-SD): Experience delivering quality software with Scrum and DevOps practices, enhancing collaboration and continuous improvement. Learn more
  • Professional Agile Leadership-Evidence-Based Management Training (PAL-EBM): Teaches how to use empiricism to set and achieve strategic goals, manage unknowns and complexity through experimentation, and focus on customer-centricity. EBM emphasizes the importance of evidence-based decision-making and focuses on outcomes rather than outputs. By measuring Key Value Metrics (KVM) in Key Value Areas (KVA) of organisation capability, like Time to Market (T2M) and Ability to Innovate (A2I), leadership can align efforts with business goals. Learn more
  • Professional Scrum Product Owner (PSPO): Help product owners understand the importance of technical debt and its impact on delivering value, and maximizing product success. Learn more

Support through Coaching, Mentoring and Internal Practices

  • Internal Support Actions: Foster a culture of continuous improvement through practices like Community of Practice, coding dojos, pair programming, and mob programming. These practices encourage collaboration, knowledge sharing, and skill development, essential for managing and reducing technical debt.
  • External Support: We understand that reducing technical debt requires more than just training. Our specialized coaching services at b-agile, including workshops, pairing, coding dojos, and mentoring, are designed to help teams learn and incorporate technical practices into their daily work. We draw from extensive experience to provide a hands-on, customizable program tailored to your team’s needs. This approach fosters a culture of quality and innovation, making technical debt transparent, manageable, and continuously reduced. Learn more here about how we can help or contact us for more information.

By investing in both education and support, you can create an environment where technical debt is transparent, manageable, and continuously reduced, ensuring the long-term success of your products.

Conclusion

Technical debt is a complex and multifaceted challenge that can have far-reaching impacts on product development, quality, and long-term success. It’s not just a development issue; it affects customers, support teams, the organization, and even the reputation of the product.

From understanding the causes and types of technical debt to recognizing the signs and dealing with it effectively, this blog has explored various dimensions of this critical subject. Here are some key takeaways:

  • Recognize the Signs Early: Awareness of the symptoms of technical debt allows for timely intervention and prevention of further accumulation.
  • Understand the Impact: Technical debt can slow down development, increase costs, and jeopardize product quality. It’s not just a code issue; it affects the entire business agility.
  • Strategize and Act: Options for dealing with technical debt range from doing nothing (and watching it get worse) to systematic investment in improvement. Making technical debt transparent and using tools like SonarQube, test coverage, and dependency complexity analysis can be part of a comprehensive strategy.
  • Invest in Continuous Improvement: Regular refactoring, adherence to coding standards, collaboration, and the use of modern tools can keep technical debt in check.
  • Leverage Professional Support: Technical Agile coaches, like those at b-agile, can provide the expertise and support needed to reduce technical debt and enable business agility.

Technical debt is not necessarily evil; sometimes, it’s a strategic choice. But like financial debt, it must be managed wisely. Ignoring or mishandling technical debt can lead to a product destined for the scrap heap. On the other hand, understanding, transparency, and proactive management can turn it into an opportunity for continuous growth and improvement.

For a deeper dive into dealing with technical debt in organizations, stay tuned for our upcoming blog on making technical debt transparent and how to approach improvement. To ensure you don’t miss out on this valuable content and more, sign up for our newsletter below.

Escaping the Product Owner’s Trap: A Path to Unleashing True Value

Escaping the Product Owner's Trap

In assisting several Product Owners in a number of larger organizations, we’ve noticed a recurring challenge that we’ve called ‘Escaping the Product Owner’s Trap’!

Many Product Owners find themselves operating more as component owners than embracing the ownership of a Product. They commence their journey with clear intentions, understanding their role as value maximizers, focusing on delivering value, and diligently setting up their Product Backlog, goals, and stakeholder interactions.

Yet, vital first questions often elude Product Owners: ‘Am I truly an owner of a product that can deliver value?’, ‘How are we going to really validate our assumptions?’ These questions probe beyond the mere mechanics of Scrum; they touch upon the ownership of an entity that realizes value when a customer engages with it. In the pursuit of perfecting individual parts, the whole is sometimes overlooked. Instead of cultivating value, Product Owners may find themselves entangled in managing dependencies, losing sight of the broader objectives

Understanding the 3 V’s – Vision, Value, and Validation

The challenge often starts when Product Owners grapple with the 3 V’s concept. Understanding these principles can guide the Product Owner in shifting their mindset and aligning with a product and value-driven approach, thereby avoiding the trap of focusing merely on components.

  • Vision: The overarching goal of the product.
  • Value: A focus on what delivers the most value to stakeholders.
  • Validation: Regular assessment with stakeholders to ensure alignment.

This understanding of the 3 V’s is a critical stepping stone in the Product Owner’s journey, bridging the gap between merely delivering features and truly maximizing value.

Product Management Onion
Diagram from Scrum.org PSPO course

Visualizing the Dilemma: A Product Owner’s Scenario

Consider a bank scenario – A customer applies for a mortgage, and the bank provides various services like KYC verification, Credit Assessment, Loan Underwriters, etc. Each service is a product with its own backlog and owner.

However, the bank primarily focuses on organizational initiatives to improve its market position. For simplicity, let’s say the bank has three core initiatives they’re prioritizing – refining their mobile banking app (Red), broadening their customer service reach (Green), and instituting a more secure identity verification process (Blue).

Visualizing the Dilemma: A Product Owner's Scenario

Picture this scenario – Colin, a Product Owner, approaches me for help. The conversation unfolds like this:

  • Colin: “Alex, I appreciate your coaching. I’m starting to understand Scrum and my role as Product Owner much better – be a value maximizer. But there’s an issue… I believe in the value of the Red initiative for my product, but I need Sue, Paul, and Jane’s help to deliver it.”
  • Me: “Is there anything else?”
  • Colin: “Yes, Sue is adamant about prioritizing the Blue initiative and is persisting these items are urgently needed from me and my team.”
  • We bring Jane into the discussion:
  • Jane: “We understand where Colin is coming from, but our focus is on the Green initiative. Additionally, we need work from Colin’s team, as well as Sue and Paul.”

And the conversation continues bringing in Sue and Paul. Let’s visualise what we have…

Visualizing the Dilemma: Coloured

Let’s take a step back and run a path through the red initiative only, that Colin brought to us at the start.

Visualizing the Dilemma:  Value Stream

You can see this runs through all the current product backlogs. This line represents your real value stream, encapsulating your customer’s journey, and illuminates what you should genuinely be concerned about as a Product Owner.

Does this situation echo the reality in your organization? This prompts the big question – Are you genuinely a Product Owner, or have you found yourself as a Component Owner, focusing primarily on output rather than end-to-end value?

Interestingly, this dilemma seems to have a softer impact on smaller companies. Perhaps the closer proximity to the customer allows for a more streamlined, value-driven approach, where the focus naturally aligns with genuine Product Ownership.

What is a Product?

So, let’s establish a shared understanding. When we refer to a product, there are several key points to consider:

  • Producer and Consumer: A product involves both a producer, the entity or individual creating the item, and a consumer, the person or group who uses or purchases it.
  • Value Creation: The primary purpose of a product is to solve a problem for the consumer, providing value and meeting their needs effectively.
  • Physical or Non-Physical: A product can take the form of a tangible, physical item, or it can be intangible, represented by a service.
  • Benefit for the Producer: Developing a product should generate core benefits for the producer, such as increased revenue, cost savings, or societal advantages.

However, defining your product accurately isn’t always easy. It’s crucial to define it at the right level – not too broad that it becomes vague, and not too narrow that it loses its overarching value.

To illustrate this, consider the example of buying a car. Do you buy an airbag? A steering wheel? Or a car? While the airbag and steering wheel are perfectly valid products in their own right, they’re components of the broader product – the car. The car is what provides value to the consumer by solving their problem of transportation.

But how frequently do we find ourselves operating at a component level, failing to envisage the broader picture? Let’s delve into this common pitfall with an example and illustration.

The Component Trap: Root Cause and Path Forward

Many Product Owners find themselves trapped as component owners. The reason for this is often rooted in old ways of working and the organizational communication structure, rather than focusing on delivering value and products for the customer. This situation may be summed up by Conway’s Law.

Some key reasons contribute to this dilemma:

  1. Work is brought to the team, and the old project mindset persists. Even with the adoption of new methods, the communication processes remain unchanged. There is an ongoing need to shift towards a product mindset that emphasizes the holistic view of the product.
  2. A focus remains on output measurements (e.g. number of features) rather than outcomes. This output-oriented approach overlooks the true goal of delivering tangible value to customers and the organization, reducing the impact of the work.
  3. The critical question, “What is our product? Am I delivering something that makes an organizational or customer impact?” is often overlooked. This neglect of fundamental questions can lead to a misalignment between efforts and true product value, hindering the ability to realize the full potential of product ownership.

A common motto that can guide this mindset shift is: “Ignore your current setup, and focus on bringing the teams to the work, not the work to the teams.” This approach encourages us to build teams centered around delivering value rather than keeping the same workflow of (component) teams. It’s a shift that could spark self-organization within the teams, encouraging them to discuss the optimal formation to deliver value.

The resulting collaboration might not change the team structure at all, but it fosters communication and unifies focus, possibly leading several teams to operate as one cohesive unit. It’s a change that starts with a conversation and leads to realignment around the core goal of delivering value.

Aligning the ‘Why’: The Collaborative Role of the Product Owner

In the dynamic landscape of product development, the Product Owner’s role is about more than just overseeing components; it’s about aligning with the ‘Why’, and the Vision, and fostering a collaborative environment.

Key Points:

  • Understanding the ‘Why’: The Product Owner connects stakeholders and delivery teams with the purpose and goals, ensuring alignment towards meaningful outcomes.
  • Fostering Collaboration with Stakeholders and Delivery Teams: By creating a cooperative environment that encourages everyone involved, Product Owners enable stakeholders and delivery teams to work together seamlessly. This collaboration is focused on delivering genuine value.
  • Leveraging Tools and Techniques as Enablers: Utilizing practices such as Impact Mapping, User Story Mapping, Specification Example, User Stories, and more. These tools drive collaboration and transparency, enabling effective communication and alignment between stakeholders and delivery teams.
  • Guiding Towards Value: Steering away from mere component thinking and orienting towards comprehensive value delivery and customer satisfaction.
What is a Product?

Help to Shift towards a Product and Value-Driven Mindset

We recognize the intricate challenges of aligning focus and nurturing collaboration in today’s ever-changing product development landscape. That’s why we’re proud to be able to offer the Scrum.org Professional Scrum Product Owner course to help. This specially crafted course guides individuals toward embracing a product mindset, putting a spotlight on value-driven strategies that resonate with the modern marketplace. Its key objectives include:

  • Understanding and Applying the 3 V’s: Defining and communicating product vision, measuring and maximizing value, and continually validating progress, including understanding Scrum Principles and Empiricism.
  • Emphasizing Value over Components: Recognizing the value of a product over a project mindset, and learning techniques for Product Backlog Management, Release Management, and Forecasting.
  • Aligning with Organizational Objectives: Aligning product goals with business objectives and strategies, including alignment with business strategy, product vision, Product Goal, and Sprint Goal.
  • Enhancing Collaboration and Communication: Fostering effective collaboration with stakeholders, customers, and development teams, including ways to effectively communicate the business strategy, product vision, and Product Goal.
  • Providing Practical Tools and Techniques: Including practical exercises, tools, and techniques to drive alignment and collaboration, adapt to market changes, and identify metrics for tracking value creation and successful product delivery.

With an understanding of Professional Scrum and complementary practices, the PSPO course equips Product Owners with essential tools and insights. This alignment with the 3 V’s concept helps shift towards a product and value-driven mindset, supporting a more entrepreneurial role in product management.

Diagram from Scrum.org PSPO course

End Note

Being a Product Owner comes with its challenges, but focusing on core principles can make a significant difference. Here are some key points to consider:

  • Define the ‘Product’: Understand your product’s true value.
  • Align with the ‘Why’: Keep stakeholders connected to the overarching vision.
  • Foster Collaboration: Facilitate engagement across all parties.
  • Guide Towards Value: Prioritize delivering genuine value over managing components.

Reflect: Take time to consider your role as a Product Owner and how you can embody these principles to excel in product development.

If you’re looking to explore these topics further or need additional guidance, it would be awesome to see you in one of our Scrum.org Professional Scrum Product Owner (PSPO) courses.

Author:

Alex is an experienced Developer, Scrum Master, and Agile Coach. With extensive firsthand experience, he firmly believes in the significance of learning from practitioners who have put the theory into practice, enabling them to incorporate valuable insights from both their failures and successes in their application.

10 Powerful Tips to Pass the PSPO I Assessment

10 Powerful Tips to Pass PSPO Assessment

Welcome to “10 Powerful Tips to Pass the PSPO I Assessment”! Whether you’re new to Product Ownership or looking to enhance your expertise, these tips will provide valuable guidance to excel in the assessment and become a proficient Scrum Product Owner.

As you prepare for the assessment and aim to achieve Scrum Product Owner certification, remember that it’s not just about passing the assessment. It can be an excellent feedback & learning opportunity on your Scrum and Product Owner journey. Let’s explore these tips to help you succeed and continue growing as a proficient Scrum Product Owner.

Before diving into the tips, if you haven’t yet taken the PSM I assessment, we highly recommend checking out our blog on “10 Powerful Tips to Pass the PSM I Assessment” to solidify your Scrum fundamentals. It’s the perfect foundation for your journey toward becoming a Scrum Product Owner.

Now, let’s proceed with our expert tips to conquer the PSPO I assessment and elevate your skills as a Scrum Product Owner.

Format:

The PSPO I assessment follows the following format:

  • Number of questions: 80
  • Time limit: 60 minutes
  • Assessment format: Online Multiple Choice
  • Pass rate: 85%

Subject Areas:

The assessment covers the following subject areas:

  • Understanding and Applying the Scrum Framework: Empiricism, Scrum Team, Events, Artifacts, Done.
  • Developing People and Teams: Self-Managing Teams.
  • Managing Products with Agility: Forecasting & Release Planning, Product Vision, Product Value, Product Backlog Management, Business Strategy, Stakeholders & Customers.

Tips to Prepare

Read the Scrum Guide:

Building a solid foundation of Scrum knowledge is essential for the PSPO I assessment. Thoroughly read the Scrum Guide multiple times to understand its fundamental principles, accountabilities, events, and artifacts. Refer back to the Scrum Guide whenever you encounter challenging questions during the exam.

Read the Evidence-Based Management (EBM) Guide:

Understand the Evidence-Based Management (EBM) Guide, which shifts the focus to better metrics that measure value in any product development. EBM introduces the concept of Key-Value Areas (KVA), empowering you as a Product Owner to make data-driven decisions and maximize the value of your product. Familiarize yourself with EBM principles to align with the product’s vision and strategic goals effectively. Explore our Scrum.org EBM course if want to deepen your knowledge and gain valuable insights for data-driven decision-making as a Product Owner

Attend a PSPO Course:

Participating in a Professional Scrum Product Owner (PSPO) course provides a game-changing learning experience. Gain insights from experienced Agile practitioners and deepen your understanding of Product Ownership. While not mandatory, attending the course significantly enhances your preparation.

Complete the Product Owner Open Assessment:

The Product Owner Open assessment is a useful resource to gauge your understanding of Scrum and Product Ownership. Aim to achieve a score of 100% repeatedly by completing the assessment multiple times (at least 5 times in a row). The benefit of the Open assessment is that it not only provides your results but also explains the correct answers and why they are correct. Additionally, consider exploring other Open assessments to expose yourself to different perspectives on Scrum and Scrum Master-related questions. You can access the Scrum Open assessments on the Scrum.org website.

Do Further Reading:

To enhance your preparation for the Professional Scrum Product Owner assessment, it is advisable to explore further reading materials. Scrum.org provides a list of suggested reading materials for Professional Product Owner, which can be found on their Suggested Reading for Professional Scrum Product Owner page. These resources offer valuable insights and in-depth knowledge to supplement your understanding of Scrum concepts.

Many previous PSPO students have emphasized the importance of thorough study and preparation, even after attending the course. Prior to taking the assessment, it is highly recommended to review the Product Owner’s learning path and delve into the suggested reading materials for PSPO I. This extra effort will help you approach the assessment with confidence.

Useful Blogs:

Tips to Help Pass the PSPO I Assessment

Embrace Being Value-Driven:

Focus on delivering maximum value to stakeholders and end-users. Continuously assess and prioritize the Product Backlog based on the value it brings to the product and the organization. Align your product development efforts with the organization’s goals to optimize the return on investment and create a successful product.

Grasp the Importance of Empiricism and the Definition of Done (DoD):

Emphasize the significance of basing decisions on observed experience and real-world data. The Definition of Done sets clear criteria for completed work, ensuring transparency and shared understanding within the Scrum Team. It enables you to make informed decisions and plan for future releases based on predictable increments of consistent quality.

Understand the 3 Vs – Vision, Value, and Validation:

Maintain a compelling product vision that aligns with the organization’s goals. Focus on delivering continuous value by understanding customer needs and validating product success through feedback and data-driven insights. The 3 Vs – Vision, Value, and Validation – serve as guiding principles to steer your product toward success.

Grasp Effective Product Backlog Management:

Maintain an organized and transparent Product Backlog. Prioritize backlog items based on value and regularly refine them to ensure clarity and actionability. A well-managed Product Backlog is a valuable tool for effective collaboration within the Scrum Team and with stakeholders.

Embrace Product Development as a Strategic and Tactical Team Sport:

Recognize that product development in Scrum is a collaborative effort involving the entire Scrum Team, including you as the Product Owner. Work closely with the Development Team, Scrum Master, and stakeholders to ensure a shared understanding of the product’s vision and goals.

Pass the PSPO I Assessment

Expand your Product Ownership knowledge and enhance your preparation by exploring the following books:

Final Remarks

When taking any of the Scrum.org assessments, remember the following key tips:

  • Read questions carefully: Pay attention to negatives (NOT) in the questions.
  • Select the correct number of answers: Ensure you choose the right amount of responses when multiple answers are required (square-shaped boxes, show more than one option is needed).
  • Manage time wisely: Avoid searching online; time is limited. Use bookmarks for uncertain answers.
  • Remain composed: If you encounter a challenging question, stay calm and focused. Bookmark it for later review if needed, but trust in your preparation.

Use these 10 powerful tips to prepare effectively and increase your chances of passing the PSPO I assessment successfully. Remember to focus on product ownership, understand the product backlog, practice time management, read the questions carefully, and take mock assessments. Good luck!

10 Powerful Tips to Pass the PSM I Assessment

10-Powerful Tips to Pass-PSM-I-Assessment

Welcome to “10 Powerful Tips to Pass the PSM I Assessment”! As you prepare for the assessment and aim to achieve Scrum Master certification, remember that it’s not just about passing the test. It’s also an excellent feedback opportunity on your Scrum journey. Let’s explore these tips to help you succeed and continue growing as a proficient Scrum practitioner. Let’s get started!

Format

The Scrum.org PSM I assessment follows the following format:

  • Number of questions: 80
  • Time limit: 60 minutes
  • Assessment format: Online Multiple Choice
  • Pass rate: 85%

Subject Areas

The assessment covers the following subject areas:

  • Scrum Theory and Principles
  • Scrum Framework
  • Coaching & Facilitation
  • Cross-functional self-organizing teams

Tips to Prepare

1. Read the Scrum Guide Several Times:

To build a solid foundation of Scrum knowledge, thoroughly read the Scrum Guide multiple times. Although it is a concise document spanning only 13 pages, each page holds valuable insights. The guide outlines fundamental principles, accountabilities (previously known as roles), events, and artifacts of Scrum. Whenever you encounter challenging questions during the exam, refer back to the Scrum Guide for clarity.

2. Attend a Professional Scrum Master (PSM) Course:

Attending a Scrum.org Professional Scrum Master (PSM) course can be a game-changer, providing you with the opportunity to learn directly from experienced Scrum practitioners. By participating in the course, you can gain valuable insights, practical examples, and a deeper understanding of the Scrum framework. While attending the course is not mandatory for passing the assessment, it can significantly enhance your preparation and overall knowledge of Scrum.

Additionally, the PSM course offers the benefit of two complimentary attempts at the globally recognized Professional Scrum Master I (PSM I) assessment. This ensures that you have a second opportunity in case of an unsuccessful first attempt. Maximize your chances of success and gain a comprehensive understanding of Scrum by taking advantage of this valuable opportunity.

3. Complete the Scrum Open Assessment:

The Scrum Open assessment is a useful resource to gauge your understanding of Scrum. Aim to achieve a score of 100% repeatedly by completing the assessment multiple times (at least 5 times in a row). The benefit of the Open assessment is that it not only provides your results but also explains the correct answers and why they are correct. Additionally, consider exploring other Open assessments to expose yourself to different perspectives on Scrum and Scrum Master-related questions. You can access the Scrum Open assessments on the Scrum.org website.

4. Learn Scrum Guide Terminology:

Read the Scrum glossary to familiarize yourself with the terminology used in the Scrum Guide. This step is essential to ensure you understand all the terms you may encounter during the assessment. It becomes particularly useful if you haven’t attended a Scrum course, as it helps bridge the knowledge gap and ensures you are well-prepared for the exam.

Remember, a solid grasp of Scrum terminology enhances your overall understanding of the framework and improves your chances of success in the PSM I assessment. Take the time to study and internalize the key terms to confidently tackle the exam.

5. Do Further Reading:

To enhance your preparation for the Professional Scrum Master assessment, it is advisable to explore further reading materials. Scrum.org provides a list of suggested reading materials for Professional Scrum Master, which can be found on their Suggested Reading for Professional Scrum Master page. These resources offer valuable insights and in-depth knowledge to supplement your understanding of Scrum concepts.

Many previous PSM students have emphasized the importance of thorough study and preparation, even after attending the course. Prior to taking the assessment, it is highly recommended to review the Scrum Master learning path and delve into the suggested reading materials for PSM I. This extra effort will help you approach the assessment with confidence.

Useful Blogs:

Tips to Help Pass the PSM I Assessment

6. Read the Questions Carefully:

When tackling the assessment questions, it is crucial to pay close attention to the wording and ensure a thorough understanding of what is being asked. It is especially important to read each question carefully, taking particular note of any negatives (such as “NOT”). Look for bold keywords in the question, as they may provide a hint about the specific focus or what the question is looking for. By carefully analyzing these keywords, you can answer accurately and significantly improve your chances of success.

7. Think About What the Scrum Guide Says:

During the assessment, keep in mind the guidance provided by the Scrum Guide. Rather than relying solely on your personal experiences in the workplace, align your answers with the principles and guidelines outlined in the Scrum Guide. Regularly refer back to the Scrum Guide when faced with challenging questions to ensure accurate responses.

8. Embrace the Scrum Master as a Servant Leader:

A crucial aspect of the Scrum Master role is being a servant leader. Embrace the various stances and mottos associated with the Scrum Master, such as “Let the team decide,” “It Depends,” and “Take it to the team.” Understand that the Scrum Master facilitates and empowers teams to embrace empiricism and self-organization. Demonstrating a comprehensive understanding of the Scrum Master’s servant leadership role is essential for passing the PSM I assessment.

9. Understand Empiricism and the Three Pillars:

Scrum is built upon the foundation of empiricism, which emphasizes decision-making based on observed experience. The three pillars of empiricism in Scrum are transparency, inspection, and adaptation. Familiarize yourself with how Scrum events embrace these pillars to effectively answer questions related to empiricism during the PSM I assessment.

10. Grasp the Importance of a Valuable, Usable, and Done Increment:

In Scrum, delivering a valuable, usable, and done increment is vital for providing value to stakeholders. The increment should undergo thorough verification to ensure its functionality and alignment with the Definition of Done. Recognizing the significance of a done increment and its contribution to transparency is crucial for success in the PSM I assessment.

Tips to Pass the PSM I Assessment

Expand your Scrum knowledge and enhance your preparation by exploring the following books:

Final Remarks

When taking any of the Scrum.org assessments, remember the following key tips:

  • Read questions carefully: Pay attention to negatives (NOT) in the questions.
  • Select the correct number of answers: Ensure you choose the right amount of responses when multiple answers are required (square-shaped boxes, show more than one option is needed).
  • Manage time wisely: Avoid searching online; time is limited. Use bookmarks for uncertain answers.
  • Remain composed: If you encounter a challenging question, stay calm and focused. Bookmark it for later review if needed, but trust in your preparation.

By following these preparation tips, understanding the exam format, and considering the essential concepts highlighted, you will be well-equipped to pass the Professional Scrum Master I (PSM I) assessment and deepen your understanding of Scrum.

Remember, the assessments are opportunities to showcase your understanding of Professional Scrum and your journey toward Scrum mastery. Your continuous growth and expertise as a Scrum practitioner are far more significant than the assessment itself.

Good luck with your PSM I assessment, and may your journey as a Scrum Master be filled with growth and success!

Agile and Scrum: Unravelling the Misconceptions

Agile and Scrum

As a Scrum.org trainer, we often come across common misconceptions about Agile and Scrum. The red flags we hear of misalignment and misconceptions when exploring folk’s current understanding and definition of Agile and Scrum.  Here are a few but certainly not an exhaustive list:

Agile:

  • Agile is a methodology.
  • A focus on agile tools and practices, yet no understanding of the why, the mindset, and achieving business agility.
  • Neglect on customer collaboration and feedback.
  • Neglect on self-organisation and enabling cross-functional teams.
  • Agile eliminates the need for planning or documentation.
  • Resistance to change and sticking to current/traditional processes.

Scrum:

  • Scrum is a methodology.
  • Scrum is an agile project management delivery system 
  • Scrum is breaking work down into small tasks to be delivered faster.
  • A focus on features being delivered rather than the value being delivered (e.g. Feature Factory)
  • No Valuable Usable (Done) increment at the end of each Sprint.
  • No validation happens once an increment (product) is released to the market.
  • Unaware of the true purpose of the Sprint Review and Sprint Retrospective.
  • Scrum is applicable for software development only.

These misconceptions underscore the importance of developing a comprehensive understanding of Agile and Scrum beyond superficial practices. It’s essential to recognize that Agile is all about fostering business agility. In other words, to adapt and respond to change to deliver value in a fast-moving customer-centric market. Without a solid grasp of this crucial concept, the true essence of Agile and Scrum might remain elusive.

In this blog, we look to explore and clear up some common misunderstandings about Agile and Scrum, which we hear in our Scum training. We’ll review some key concepts to help to dispel any confusion. And give you enough to have a far better understanding of the core concepts and help smash those misconceptions into touch.

In our experience, we have found these misconceptions about Agile and Scrum can really hinder the benefits they can bring. So, if you have any of these misconceptions, then this going to help.

Let’s dive in and start with Understanding Agile first.

What is Agile?

Agile refers to a mindset, not a set of procedures or tools. In 2001 the Agile Manifesto for Software Development was introduced to encapsulate a new way of thinking with 4 values and 12 principles on how to deliver software products better. Although it had its roots in software development, its values and principles have since expanded to cover various areas beyond just software development.


At the heart of Agile lies a value-driven approach, putting customer satisfaction front and centre. Its main goal is to deliver high-quality products, or services, effectively and efficiently to the market so we can get feedback (validation) from customers. Agile deeply understands the significance of creating real value for customers and strives to align all efforts with their needs.

The Agile Onion

To help understand Agile better and its real purpose, we find it useful to explore the Agile Onion. This helps give us a visual representation that really encapsulates the essence of Agile. It highlights that Agile is not merely about tools or practices, but involves a deep-rooted shift in thinking and behaviour.

Agile Onion

The Agile Onion comprises of five interconnected layers:

  • Tools and Processes: The most visible, yet least influential aspects of Agile when applied in isolation. Examples are Jira, Azure, Whiteboards & Sticky Notes, etc.
  • Practices: Specific practices used in an Agile environment. These become effective when they align with Agile principles and values. Examples are Scrum, Kanban, XP, Story Mapping, etc
  • Principles: The guiding rules derived from the Agile Manifesto which prioritize aspects like valuing individuals and interactions, and embracing change. For example, committing to finishing work before starting, release early and often, etc.
  • Values: The foundational beliefs that build an Agile culture, include trust, respect, courage, and equal voice.
  • Mindset: The innermost layer of the onion is the Agile mindset. It’s about fostering a collaborative and transparent environment and promoting adaptability.


Understanding the Agile Onion helps us surpass the allure of cool tools and practices. While they can be important enablers, the essence of Agile lies in its outer rings—the principles and values that drive mindset and behaviour. Embracing these principles and values is key to unlocking the full potential of Agile in your organization and teams. In other words, start with the “Mindset” and work inward.

Agile Misconceptions

One of the major misconceptions we hear too often is that Agile is a methodology or a project management approach. However, Agile is neither. It is a mindset underlined by the values and principles that shape the way we work and interact, with a product-oriented and outcome-driven approach over a project-oriented and output-driven one.

The agile mindset is to focus on delivering value to customers, collaborating with stakeholders, and embracing change. It encourages iterative and incremental development, continuous improvement, and cross-functional teamwork.

We’ll dig deeper later into the relationship between Agile and Scrum. But what we can say, is that Scrum is one approach (practice) that can help teams implement those Agile values and principles effectively.

Agile vs Waterfall

Agile and Waterfall represent two different approaches. Waterfall follows a linear and sequential design process where progress is seen as flowing steadily downwards, like a waterfall. In contrast, Agile promotes iterative and incremental development, where requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams. This iterative approach allows for small experiments and frequent feedback loops, enabling teams to continuously learn, adapt, and deliver value.

The Agile approach is like a speed boat, agile and swift, able to change direction quickly and seize new opportunities. On the other hand, Waterfall is like an oil tanker – once the course is set, it’s hard to change direction swiftly.

Need further help in understanding Agile and exploring how it can benefit your organization and teams?

The Professional Agile Leadership Essentials course could help provide a deeper insight into agile and how agile leadership can support agile (scrum) teams to help enable the shift for organisations, and teams, towards an agile mindset.  Understand what you measure matters! This is what can really drive culture change in your organisation.

What is Scrum?

“Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.”

Scrum Guide 2020

The Scrum framework is a lightweight framework that consists of 11 essential elements, the artefact commitments, and the rules that bind them as per the Scrum Guide.

The elements of the Scrum Framework are grouped by accountabilities, artefacts, and events:

Accountabilities: Product Owner, Scrum Master, Developers

Artifacts: Product Backlog, Sprint Backlog, Increment

Events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective

In addition, Scrum identifies specific commitments to ensure focus, transparency, and alignment, which are the Product Goal, Sprint Goal, and Definition of Done.

The Scrum values of Commitment, Focus, Openness, Respect, and Courage underpin the Scrum framework. They shape the behaviour and mindset of the Scrum Team, promoting collaboration, transparency, and adaptability.

Scrum does not prescribe specific complementary practices, allowing teams to incorporate other techniques and methods as necessary. This provides flexibility for teams to select practices that best suit their context and work environment.

Think of Scrum as the rules of the game, like football. Every football team plays the game of football differently. Yet all the teams have to play to the rules of the game.

In football, if you picked the ball up and you started running with it and the team allowed you to score, then great. But it is no longer football. Same as if you started changing the rules of Scrum (e.g. drop a Scrum Event or accountability), then fine but stop calling it Scrum. It is no longer Scrum.

Scrum provides the rules of the game via a lightweight framework. Implement the framework as outlined in the Scrum Guide, but what you do in the middle (e.g., the complementary practices you choose to use or not) is entirely up to you. Scrum essentially gives you a foundation to handle complexity, embrace continuous improvement (empiricism), and achieve valuable outcomes. It is purposefully incomplete to allow for flexibility and creativity in how you play the game.

Yet Scrum is more than just its mechanics; it’s a path to realising Agile values and driving business agility. Ever wondered about the deeper purpose of Scrum’s rules and how they foster continuous improvement and valuable outcomes? Dive into these insights and more in our latest blog, ‘What is Scrum: Uncovering Its True Essence‘. It’s a compact guide to understanding the true purpose and transformative potential of Scrum.

Scrum Misconceptions

Despite its popularity, several misconceptions about Scrum persist. One common misconception is that Scrum is a methodology or a process for product management. As mentioned above its none of these.  It’s a light framework to help you embrace empiricism and self-organisation!

Scrum isn’t about promising a faster product development cycle as its main goal. Instead, it’s all about empowering teams with empirical process control, continuous improvement, and the ability to adapt effectively to change. But the real magic happens when teams fully embrace the Scrum values of Commitment, Focus, Openness, Respect, and Courage. These values create an incredible environment of collaboration, transparency, and adaptability, forming the bedrock of successful teamwork that feels truly rewarding and effective.

To obtain a great understanding of Scrum, then recommend reading the Scrum Guide. Read it several times and analyse each section. It’s an invaluable resource that will give you profound insights into how Professional Scrum should function.

Challenges of Implementing Scrum

Implementing Scrum and consistently delivering a “Done” increment every Sprint can be the biggest challenge for teams yet the most important, especially in the context of software product development. While the Scrum Guide emphasizes the importance of empiricism and the Definition of Done, it does not provide specific instructions on how to achieve a “Done” increment.  If you asked me to sum up Scrum as one thing, then it would be to have a Done (Valuable and Usable) Increment every Sprint. Yet so many so-called Scrum teams don’t have this?

To address this challenge, teams often need additional support and complementary practices that align with Scrum principles. These practices may include continuous integration, test automation, code reviews, pair programming, and other engineering practices that promote quality and enable frequent delivery of potentially shippable increments.

Our Scrum.org certified course, Applying Professional Scrum for Software Development, is designed to support teams in gaining the knowledge and skills to address this challenge. At a hands-on course where teams learn and experience industry practices and techniques that can enhance their ability to deliver a quality “Done” increment at the end of every Sprint.

How Scrum Incorporates Agile Principles and Values

Scrum is a light framework that enables teams to embrace Agile principles and values. Its events and accountabilities are specifically designed to uphold and enforce these principles and values. By embracing Scrum, teams can foster a culture of collaboration and self-organisation, transparency, and continuous improvement.

Scrum is a light framework that enables teams to embrace Agile principles and values. Its events and accountabilities are specifically designed to uphold and enforce these principles and values. By embracing Scrum, teams can foster a culture of collaboration and self-organisation, transparency, and continuous improvement.

One of the key principles of Agile is continuous improvement, and Scrum provides a dedicated event to support this principle.  One example is the Sprint Retrospective event. During this event, the Scrum Team reflects on its process, practices, Tools, Definition of Done etc to identify areas for improvement, and commits to making adjustments in the next Sprint. This event promotes a culture of learning, adaptation, and relentless improvement.

By teams embracing Professional Scrum and leveraging events and Scrum accountabilities, teams can start to harness the power of Agile principles and values to deliver value more effectively, adapt to changing requirements, and continuously improve their processes and outcomes.

Agile and Scrum

Understanding the Relationship

Agile is a way of working with a set of underlying values and principles that promotes an iterative and incremental approach to product development. It promotes flexibility, collaboration, and customer satisfaction through the continuous delivery of valuable solutions.

Scrum, on the other hand, is a lightweight framework for teams to implement. Scrum incorporates the 3 pillars of empiricism (transparency, inspection and, adaption), Scrum Values, and self-organization to enable teams to respond effectively to deliver high-quality products continuously in a fast-changing market.

Scrum is based on empirical process control, where decisions are made based on observation and feedback, enabling teams to continuously improve their work. Scrum aligns with Agile principles by promoting iterative development, frequent inspections, and continuous adaptation. It provides a framework that empowers teams to embrace Agile values and deliver value incrementally.

Scrum is a widely adopted framework, but it is not the only way to practice Agile. There are other agile approaches such as Kanban, Lean, and Extreme Programming (XP). Each with its own set of principles and practices but they’re all aligned with helping to achieve the agile principles & mindset.

Understanding the relationship between Agile and Scrum helps teams choose the right approach for them for their context and needs. The key is to embrace the Agile principles and values.

Which Came First: Scrum or Agile?

A trivial question I know, but it can help appreciate the connection. Many say Agile came first but Scrum, developed in 1995, predates the formation of the Agile Manifesto in 2001. Interestingly, the creators of Scrum, Ken Schwaber and Jeff Sutherland, were among the founding signatories of the Agile Manifesto.

Summary

Embracing the Agile mindset, values, and principles is key to unlocking the full potential of Scrum and driving successful Agile transformations

Navigating the world of Agile and Scrum can be challenging, but by dispelling misconceptions and gaining valuable insights, we can embrace the fundamental concepts. Agile is a mindset that shapes how we work. Understanding the relationship between Agile and Scrum helps us choose the right approach, fostering collaboration, flexibility, and customer-centricity in product development.

To move towards an agile mindset, we should focus on:

  1. Focusing on the Agile Values & Principles: Understanding the Agile values and principles as per outlined in the Agile Manifesto. These are the foundation for adopting an agile mindset.
  2. Defining clear goals: Clearly defining goals and aligning them with the values and principles of agility helps teams stay focused and motivated.
  3. Embracing change and learning cycles: Agile teams embrace change as an opportunity for growth and learning. They adopt iterative and incremental approaches to development, allowing for feedback and adaptation.
  4. Promoting collaboration and teamwork: Agile teams prioritize collaboration and effective teamwork. They encourage cross-functional collaboration, knowledge sharing, and collective ownership of deliverables.
  5. Fostering an open and learning-oriented culture: Agile teams create an environment that encourages learning, experimentation, and continuous improvement. They value feedback, encourage learning from failures, and celebrate successes.

Scrum may help you achieve some of these.

If you are looking for further help with your understanding of Scrum and Agile, there are a range of certified courses and coaching services we can offer to help:

  1. Certified Courses: Explore our full list of certified courses. Yet the key ones that could help are:
    • Our Agile Leadership course empowers leaders and managers with the knowledge and skills to drive organizational agility, foster a culture of innovation, and enhance customer satisfaction. 
    • Our Professional Scrum Master course provides a deep understanding of Scrum and Scrum Mastery to support teams and organizations in applying Scrum.
  2. Agile Coaching Services: We provide Agile coaching services to help organizations embrace a new way of working and cultivate business agility. Our experienced Agile coaches offer personalized guidance and support to teams in their Agile journey and help them achieve their Agile transformation goals. With a focus on collaboration, adaptability, and continuous improvement, our coaching empowers teams to navigate the complexities of Agile and drive successful outcomes.

We hope you enjoyed the read and help provide some clarity and guidance.

If you have any questions or would like us to explore any concepts further, then please let us know in the comments.

Author:

Alex is an experienced Developer, Scrum Master, and Technical Agile Coach trainer at b-agile. With extensive firsthand experience, he firmly believes in the significance of learning from practitioners who have put the theory into practice, enabling them to incorporate valuable insights from both their failures and successes in their application.

DIY – When will it be Done?

DIY – When will it be Done?

With Chris Bexon – Agile Coach and Trainer at B-Agile. Chris coaches people, agile teams, and organisations to achieve true agility. Chris is passionate about providing free neurodiversity coaching to professionals on the spectrum.

In this blog, we will look at how to use Throughput data to answer those “When will it be Done?” questions – DIY style.

Using probability for forecasting can help us raise transparency over the Product Goal and Product Strategy. More transparency can move us away from deadlines and commitments towards collaborative product management with agile teams and stakeholders. This further enhances our ability for strategic planning and adapting to risk

These flow metrics can be used in any iterative and incremental or flow processes

By the end of the blog, you will be able to measure Throughput and forecast When and How Much using Monte Carlo simulations in Excel

Let’s start by reviewing some basic concepts

The image below shows a simple workflow We have work items in a Ready queue state waiting on the left and a Done queue state on the right. To get the work items from left to right requires some activities to be completed. In this example some build and test activities.

You’ve probably seen many boards either physically or digitally that resemble this. You’ll see that there’s lots of work in the Build and Test activities and nothing much being completed. I.e. the Done queue state is empty. The total amount of work in Build and Test is referred to as Work In Progress or WIP and is defined as the number of work items started but not finished.

There’s nothing in the workflow to limit new work being started and encourage work to be completed. This type of workflow is referred to as a push system.

In order to use Flow Metrics for forecasting we need to encourage valuable work items to be completed before starting new work to create a flow of value. Otherwise, our customers might be waiting a long time and they cannot give us feedback!

Work In Progress Limits Applied

We have now limited parallel Work In Progress or the total amount of work items in the workflow to 5. As new work cannot enter the workflow, the team now has to complete the highest-value work items on the right-hand side first to create a flow of value. There may be other ways of controlling WIP but in this example we are going to use limits to keep it simple. Other considerations around the batch size and uncertainty may also be considered.

Scrum itself is a pull system and is Work In Progress limited by default in various ways. We focus on a single Product Goal to guide the valuable future state of the product and focus on a single Sprint Goal, Each Sprint results in a useful valuable increment. We can enhance Scrum further by optimising the flow of value in a Sprint by understanding the Workflow and controlling WIP. Kanban systems are designed to control Work In Progress from the ground up through the ongoing process of creating the definition of workflow.

By controlling WIP we can avoid work items piling up in any part of the workflow, ensure work items are moving and not aging unnecessarily and unblocking work items to keep them moving

For more information check here as a starting point https://kanbanguides.org/wp-content/uploads/2021/01/Kanban-Guide-2020-12.pdf or the https://www.scrum.org/resources/kanban-guide-scrum-teams

There are four primary flow metrics Throughput, Cycle Time, WIP, and Age We will focus on Throughput in this blog.

Flow Metric: Throughput

The number of work items finished per unit of time. So Throughput is the exact count of work items per period of time

We are going to need to record some basic data for each work item. For this example, we are going to record the number of work items moving into the Done queue state each day. All we need to record is the date this happened.

Done Count of Work Items

22/06/2023 1

23/06/2023 0

24/06/2023 1

25/06/2023 2

Let’s Walk Through How We Use The Data

Now that we have established the foundational concepts, let’s explore how we can effectively leverage the data. Join us for a short video explanation.

The data below shows throughput (in our case, count of work items per day) for 3 agile teams. The spreadsheet contains around three months of data. You can see from the data that there is a spread of values. Some days have zero work items and some days have more. Some work item counts will be more common than others.

When will it be Done? - Raw Data

The same data is represented on a scatterplot when we can see the variance in the range of values

When will it be Done? - Daily Throughput

The distribution of probability can be shown on a histogram. The histogram places a range of occurrences in a bucket. You can see here that the highest probability in in the range 0 – 5.4 work items per day

When will it be Done? - Histogram

The Normal distribution is used to analyse data when there is an equally likely chance of being above or below the mean for continuous data whose histogram fits a bell curve.

From the data, we calculate:

The Mean is 2.838384. The mean of all values in the set of data

The Standard Deviation is 3.492292. How dispersed the data is in relation to the mean. You can use the STDDEV.P function to calculate this value. Alternatively, we can calculate – see spreadsheet

If we use the Excel function for Normal Distribution. Norm.Dist we calculate the probability of occurrence. The plot below shows the curve

Probability Density of Throughput data

Now the data has lots of gaps and missing values. The data is obviously skewed as we are not going to have negative numbers. So it may be difficult to use this data for forecasting. An advantage of Monte Carlo forecasting is that you obtain a complete distribution for future events, not just a point estimate and standard error like above

To run a Monte Carlo simulation use the NORM.INV in Excel. Provide it with a random probability between 0 and 1, the mean, and standard variation. In the spreadsheet, we ran the simulation 10000 times

NORM.INV(RAND(), Mean, Standard Variation)

This resulted in the following PDF. A normal distribution will produce equal results on either side of the Mean. We are not interested in values less than zero so will ignore these.

Different distribution curves may be a better fit. For the blog, I’m simulating the functionality of existing commercial products.

Probability Density of Monte Carlo

Forecast: Estimated Completion Dates

When will it be done?

All you need up to this point is the Mean and SD

Let’s say a stakeholder is interested when we will likely solve the Assess Image Curvature idea. There are roughly 100 work items of value in the queue before it.

So when will we get the next 100 work items?

Mean work items per day 2.838384

Standard Deviation 3.492292

Calculate 100 / Mean gives 35.23132 days as the 50th centile

Scaling the Standard Deviation we get 43.34792

Now plugging these numbers back into a Monte Carlo simulation 10000 times

When will it be Done?

If we query the data using the Excel Percentile function we can then start to answer forecasting questions.

Let’s say the current date is the 11-Apr-2023

50th centile 35.37035 Days 50% chance 100 work items completed by 16-May-23

85th centile 79.86692 Days 85% chance 100 work items completed by 29-Jun-23

95th centile 106.7747 Days 95% chance 100 work items completed by 26-Jul-23

Warning – common commercial tools on the market use a standard deviation of 1. This means they may be more ambitious than the PDF. Using a different distribution model like a Gamma or Log may be more appropriate as there’s limited downside to zero work items but unlimited upside

How Many Items By A Given Date?

Mean 2.838384

Standard Deviation 3.492292

45 Days Between 01/Jul/2023 and 15/Aug/2023

Mean * 45 = 127.7273

Now plugging these numbers back into a Monte Carlo simulation 10000 times

When will it be Done?

Querying the data with the Percentile function we can forecast:

95th centile 52 work items completed by 15-Aug-23

75th centile 97 work items completed by 15-Aug-23

50th centile 127 work items completed by 15-Aug-23

Using probability to forecast when can change the narrative away from commitments and milestones to a collaborative conversation about how to maximise the value of our work.

To learn more about Agility, Scrum, Kanban, Agile Coaching, and Facilitation please check out courses with me, Chris Bexon. Check out our courses at www.bagile.co.uk