Author: bailectdadmin

Product Owners want a perfect Definition of Done. Here’s why.

Universe starts and galaxy

First it’s worth reading this section of the Scrum Guide to reacquaint yourself with the formal definition.

Below is an example list of activities that represents potentially releasable. If all activities were completed the product could be released to a customer.

Definition of Done

The Definition of Done is an agreed list of criteria that the product will meet for each Product Backlog Item. The Definition of Done applies to all Product Backlog items. If more than one Scrum Team work on the product they share the same Definition of Done

The initial Definition of Done must be created and agreed before the first sprint. Its forms an input into Sprint Planning to guide the Development Teams on what tasks they’ll need to perform to turn Product Backlog Items into a potentially releasable increment each sprint.

To do this define what activities are needed to release to end customers. We’ll call this list “Potentially Releasable”. With this list then define which activities can be done each sprint. This forms the “Definition of Done”. The different between the two lists is undone work. The undone work must be completed at some point before release. This is not partially completed work.

Weak Definition of Done

If the Definition of Done only contains the underlined items from the Potentially Releasable list then the following behaviours will be observed:

Iteratively and incrementally a product is built according to the weak Definition of Done. This leaves undone work to build up each sprint.

  • The impact of this on the Product Owner and organisation is that they cannot release the product until the undone work is done
  • The undone work builds exponentially making it harder and harder to forecast likely completion dates. Transparency and visibility is reduced as we don’t really know where we are in development.
  • If we defer releasing to customers to later sprints it increases the risk of building the wrong features.
  • If we cannot release it reduces the Product Owners ability to adapt to risks and opportunities as they are not able to change strategic direction. Release of value and validation is delayed. Value is diminished
  • If testing and validation is deferred to later sprints it increases the risk of poor design and technical debt leading to rework. Imagine if we defer Performance or Acceptance Testing for 4 sprints. We are not learning whether the product is sufficient to meet the service level agreements. The amount of rework could be extensive.

This leads to results very similar to waterfall

Work towards a perfect Definition of Done == Potentially Releasable

Scrum relies on transparency. Decisions to optimize value and control risk are made based on the perceived state of the artifacts. The closer we are to done each sprint the better decision we can make for the next.

This graphic represent a perfect Definition of Done.

  • At least once per sprint we have met the Definition of Done.
  • If the Product Owner wants to release to the customer they can.
  • No undone work remains at the end of sprint. All activities are done in the sprint
  • Transparency is high as we always know where we are up and are able to forecast our trajectory towards product goals. We can make decisions about what’s next and change strategic direction when needed without being dragged down by undone work.

Scrum will shine a light on organisational impediments in the way of agility. Defining Potentially Releasable will help identify people, technology, domain, internal and external dependencies that hold back agility. The Definition of Done is inspected and adapted sprint by sprint becoming closer to Potentially Releasable. This will involve breaking down organisational boundaries and removing dependencies which further increases the maturity of Scrum Teams increasing their cross-functionality, decreasing complexity of the organisation and its products over time.

Thanks for reading and if you want learn way more about product ownership, scrum mastery and product development check out our courses.

Component Teams vs. Feature Teams

Infographic showing the comparison of Component and feature teams

The Scrum framework doesn’t specify whether a Development Team is a feature or a component team. Only that we have a done integrated tested increment at least once per sprint. It’s important to understand the difference between these constructs and their advantages and disadvantages. There are a few disadvantages to Component Teams that can prevent organisations gaining greater agility. Let’s take a look.

Component Teams are:

  • Teams organized for technical layers or technical components.
  • Many teams needed to turn a customer-centric feature on Product Backlog into a releasable Increment
  • Horizontal slicing; work is divided by technical layer or technical components.
  • Teams are only together for the duration of the program-project lifecycle. May be involved in multiple projects.
  • Lots of coordination needed to integrate an potentially releasable increment.
  • Very difficult to understand where we are. Lack of transparency
  • Requires project management

Feature Teams are:

  • Long lived, work on many features together over time.
  • Cross-discipline, cross-component. Each feature team has all skills to turn Product Backlog into releasable Increments.
  • Vertical slicing; work is divided by end-user functionality.
  • Work is integrated continuously within each Sprint.
  • Transparency ensured; no unknown, undone work. Potentially releasable increment at least once per sprint

Some or all of the following behaviours will be observed with Component Teams

Although sometimes necessary make them the exception rather than the rule.

  • Leads towards or reinforces waterfall process and holds back breaking down of organisation silos like Business Change, Architecture, Development, Test, Ops
  • Leads to water-scrum-fall, scrumer-fall. Something that uses the language of Scrum but definitely isn’t Scrum
  • Release of value is delayed, validation delayed
  • Lack of end-to-end accountability for the customer leads to lack of creativity and self-organisation. Kills intrinsic motivation
  • Increased risk
  • Facilitates big up front design
  • Delays learning, delayed functional and non-functional testing
  • Increased hand off waste and delays
  • Project task switching impacts work and morale
  • High technical debt

Some or all of the following behaviours will be observed with Feature Teams

  • Leads to customer and business focused organisations
  • Leads to iterative and increment release of value and validation
  • Maximised value
  • End-to-end accountability
  • Facilitates emergent design
  • Encourages creativity, intrinsic motivation
  • Enables self organisation
  • Shared code ownership promotes good engineering practices clean code, CI, CD, refactoring, automation, testing. Higher quality = lower cost of ownership
  • Decreased risk. Deal with high risk items and deploy to production
  • Ensures transparency
  • Flexibility and Stability.
  • Can focus on the flow of value
  • Can learn from each other and cross skill

Test First approach sounds simple enough, right?

Test First approach sounds simple enough, right infopgraphic

As the name “Test First” suggests, you write a test first before the actual code and keep them running all the time. Well maybe not the second part explicitly. Yet what if I said to you that it actual means more than that?

Firstly it did originate from this simply meaning. When we hear the word “test”, a majority of us think in the traditional sense of checking (e.g validate the code). This can be the first confusion in its understanding and actual meaning today, for either technical or non-technical folk. If you’re not already aware, the way you think of testing within an agile approach is fundamentally different to the traditional one. But let us leave that for another day.

Then we have all these practices you hear about residing under this Test First banner – TDD, BDD, and ATDD. Are all these practices simply for writing tests first and automation? And what are the differences between all these practices, if any?

The name “Test First” has moved on from its original concept and has a broader meaning now. Over time it has evolved to incorporate the following

  • Test Driven Development (TDD)
  • Behavioural Driven Development (BDD)
  • Ubiquitous Language for acceptance scenarios & specifications e.g. Gherkin

It has moved to enable quality focus on both the product and design by enabling faster feedback loops on several different levels, than simply writing tests first before code.

This is likely the reason in 2011, Gojko Adzi introduce a different name to group all these practices – “Specification by Example“, with a redefined purpose statement “build the product right and building the right product”. And the primary output being “living documentation” and collaboration and with automated tests being specified as the secondary output.

With people’s first exposure to Test First and the TDD and BDD practices there is a tendency to think it terms of traditionally testing. This can cause people to go down the wrong rabbit hole and began automating their tests with an automation tool (e.g. Record and Play).

As with anything context is key, so I have found it useful to briefly explain the journey on how Test First and its associated practices have iteratively evolved to help people understand the meaning of Test First and understand each of the practices purpose, focus, differences, and benefits.

Test-First Programming (est 1999)

The term Test-First Programming (TP) was introduced by Kent Beck in 1999 with his book of “Extreme Programming (XP): Explained” and states to write unit tests before programming and keep all of the created tests running at all times. A year later, in 2000, Kent Beck published another book called “Test Driven Development by Exampleand explains Test Driven Development (TDD) is a software process and not about writing tests before the code with one more important aspect – refactoring. The following is the sequence given in his book: –

  1. Add a test
  2. Run all tests and see if the new test fails
  3. Write the code
  4. Run Tests
  5. Refactor Code
  6. Repeat

This cycle tends to be referred to as Red-Green-Refactor cycle. But Kent, and others, found that writing test first had a tremendous positive effect on the software architecture and design of software too:

  • Testable
  • Decoupled
  • Reusable
  • Independently Deployable
  • Independently Developable
  • Independently Reasonable

This influence on software design and architecture became so important, beside the other positive effects, that Beck found it worthwhile to rename it from Test-First Programming to Test-Driven Development.

Test-Driven Development 2.0 (est 2004)

Test Driven Development moved slightly further, from Kent Beck’s original Red-Green-Refactor cycle, with Robert C Martin (aka Uncle Bob) and The Three Laws of Test-Driven Development.

  1. You are not allowed to write any production code unless it is to make a failing unit test pass.
  2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
  3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

This is sometimes referred to as Test First with baby steps. Check out our Introduction to Test Driven Development video for more info and in action.

Robert C. Martin went even further and focused on a 3rd Law. He discovered an approach called Transformation Priority Premise in that a simple transformation should be preferred. The approach facilitates the programmer doing the simplest possible thing for the purposes of Test-Driven Development by favouring the simpler transformation (from the top of the list) over those further down in the list.

  1. ({}–>nil) no code at all->code that employs nil
  2. (nil->constant)
  3. (constant->constant+) a simple constant to a more complex constant
  4. (constant->scalar) replacing a constant with a variable or an argument
  5. (statement->statements) adding more unconditional statements.
  6. (unconditional->if) splitting the execution path
  7. (scalar->array)
  8. (array->container)
  9. (statement->recursion)
  10. (if->while)
  11. (expression->function) replacing an expression with a function or algorithm
  12. (variable->assignment) replacing the value of a variable.

He goes on to suggest that we should amend the Red-Green-Refactor cycle of TDD with the following provisions

  • When passing a test, prefer higher priority transformations.
  • When posing a test choose one that can be passed with higher priority transformations.
  • When an implementation seems to require a low priority transformation, backtrack to see if there is a simpler test to pass.

And states if you follow these rules correctly then you should find

As the test get more specific, the code gets more generic

Behaviour-Driven Development (est 2004)

Behaviour Driven Development was developed by Dan North in response to help his colleagues to learn TDD. He found: –

  • “Behaviour” is a more useful word than “test” – people’s misunderstanding about TDD always came back the word “test”
  • Test method names should be a sentence and the word “test” can be stripped out
  • A simple sentence template keeps test method focused. The class test method should do something & only that thing
  • An expressive test name is helpful when a test fails

In 2003, Dan North created the JBehave framework to replace Junit to remove any reference to testing and replace a testing vocabulary around a behave one.

In 2004, the next discovery for Dan was the concept of business value and why we write software. He found that you could use his framework to help the team focus on feature behaviour and that missing requirement are behaviour too. Around this time Eric Evans also published his bestselling book Domain-Driven Design where he describes the concept of modelling a system using a ubiquitous language based on business domain, so that the business vocabulary permeates right into the codebase. Dan and his colleagues used similar concept to come up defining a ubiquitous language for the analytics process itself, hence where the Given, When, Then for acceptance criteria came.

Since then many people have developed other BDD frameworks and then finally began framing BDD as a communication and collaboration framework for developers, QA and business in a software project. During the “Agile specification, BDD, and Testing eXchange” in November 2009 in London, Dan North gave the following description of BDD:

BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, high automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

During an interview with Dan North at GOTO Conference in 2013, Liz Keogh defines BDD as:

It’s using examples to talk through how an application behaves. And having conversations about those examples

Since Dan North’s first java base BDD framework of JBehave, the leading BDD framework is Cucumberand reads executable specifications written in plain text that follows some base rules called Gherkin. It used by majority of languages & you can test about anything with it and build out test frameworks for your systems and products. It also works well with other tools to enable testing of APIs, Browsers, and other system end points.

What about Acceptance Test Driven Development?

Acceptance Test Driven Development or ATDD is where the entire team collaborates to define the acceptance criteria before implementation. It drives acceptance testing rather than unit testing by facilitating detailed readable description of system’s function though proper examples and other necessary information. And with a focus on outside-in development approach. Sounds familiar?

Most of the time, BDD and ATDD are used interchangeably. The ATDD approach can be implemented using the Given-When-Then format and use BDD framework tools. But also we can use BDD frameworks for the TDD approach. Confused yet?

Personally we used ATDD for 2 years before becoming aware of the term BDD. When we first heard the term, it was confusing & why is it different to what we were doing. Perhaps because we already practicing Domain Driven Development, collaborating and using test framework with a Given-When-Then option. And the “Acceptance Tests” occurred at end to end tests but also at the component, integration and unit tests too.

Reading John Ferguson Smart’s book “BDD in Action“, would of cleared that confusion far quicker for us if it been around at the time. It would of helped us considerable especially the sections “Coding the BDD way” & “Taking BDD further”. Highly recommend reading.


In essence, the approach has evolved to be all about the conversation first between the business and development team to build the right product, and the developed using an outside-in workflow to build the product right that’s highly automated.

Understand each of the practices focus, outputs and benefits and use them when suits your needs. For example, because is an indicator to be an outside-in workflow, doesn’t mean you can’t go from inside-out. And don’t bias yourself to tools, I’m using BDD tool so doing BDD.

Personally I keep it simply and use the BDD term when approach is about the collaboration with all stakeholders (customer, developer, tester, etc) to build the right product and produce living documentation that’s readable by everyone to describe what the system can do. TDD is about design and building the product right.

Hope this helps.

If you’d like to know more or how we can help you or your teams incorporate these practices then check out our Technical Agility services or get in touch at

Introduction to Test Driven Development

Introduction to test driven development aka TDD

A simply introduction to Test Driven Development (TDD) using a real coding demonstration to show:

  • It’s more than a Test First approach, of writing a failing test and making it pass.
  • The Importance of BABY STEPS (aka The Three laws of TDD)
  • And mostly about Design & let the tests drive the creation of production code.

“As the tests get more specific, the code gets more generic.” Robert C Martin

TDD is one of the Value Added Practices, covered in the Applying Professional Scrum for Software Development course, to help development teams deliver a potentially releasable increment at the end of a Sprint.

If you’d like to know more or how we can help you or your teams incorporate these practices then check out our Technical Agility services.

How to Initiate Writing a Unit Test Faster & with Little Effort

How to initiate writing a unit test faster

In this video, we talk about more efficient ways to initiate your unit tests with little effort and few keystrokes by using a code templates to help. This could possible help you, or your teams, adhere to common test naming standard too. The approach demonstrated is in Visual Studio, and use of extension ReSharper, but it can work with other IDE’s, e.g. Intellij, that allow you to have code templates too.

Are your products destined for the scrap heap?

Infographic illustrating a loss

Ward Cunningham, one of the authors of the Agile Manifesto , once said that problems with code are like financial debt. It’s OK to borrow against the future, as long as you pay it off.

Since Ward first used this metaphor, which he called “Technical debt” has gained momentum. While people still disagree about the exact definition of technical debt, the core concept identifies a serious problem that many delivery teams are struggling to manage.

Technical Debt has a visible and an invisible element. Businesses are aware of the visible part and monitor bugs but it’s the invisible element that kills business agility.

Am I working with an unhealthy product with technical debt? How would I know?

Let’s have a look at a few behaviours you may recognize:

  • Weak definition of “done” where its not well defined and represents quality for the product
  • Slowing rate of productivity and increased cycles times to add similar sized new features
  • Stressful releases, as the development team goes into to crunch mode as they work through lengthily change windows, executing scripts, manually deploying and configuring components, investigating incidents, fixing defects
  • Applications we are scared to touch and have aging libraries and unnecessary dependencies
  • Increasing time to dealing with incident investigations and fixing defects
  • Low automated testing, or no extensive test suite where we are forced to test manually which can be repetitive, slow and error prone
  • Fragile and tightly coupled components due to violation of good design principles, duplicated code, tangled architecture & unnecessarily complex dependencies.
  • Lack of test, build, and deployment automation, plus anything else that could be automated that you do manually today
  • Long feedback loops from Continuous Integration. Build, Test, Deploy
  • Slow, ineffective tools
  • Long-lived branches causing merging hell and increased delivery risk through late integration
  • Important technical documentation that is missing or out-of-date
  • Unnecessary technical documentation that is being maintained
  • Missing or not enough test environments causing delays in delivery and/or reduction in quality

With technical debt, a cumulative flow diagram showing open and closed defects over time might look like this

Defects or bugs can tell you a lot about the state of your product’s quality. 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.

What are the impacts of Technical Debt?

Let us 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 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. Hence, we see that the red line loses the ability to change rapidly over time.

At the other end of the scale, we have perfect quality in purple. Using professional scrum the design emerges each sprint, the definition of done (releasable) is achieved at least once per sprint. The design is frequently refactored and improved and all sources of technical debt are kept to zero.

The blue line is what happens to quality when the sources of technical debt are not dealt with each and every sprint. With every sprint, poor design decisions impact future decisions and compound each other.

Unreasonable cost of ownership

It should come as no surprise that the blue line is the most common scenario we see today. 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.

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.

Who suffers in this vicious circle of deceit?

  • Customers face defects, missing features, crappy service resulting in lower customer satisfaction
  • 1st line support teams will create more incidents this will cascade and create increased demand on operational support teams. More incidents and defects means more development time spent investigating with quick fixes and release patching. This results in increasing operational and capital expenditure.
  • Products with poor design are more complex than needed, have more dependencies, require more infrastructure, more development time, more support time to run
  • The organisation, teams, and leadership get bad publicity due to defects, delays, security issues, or outages. Organisations suffer increase cost through eventually needing to rewrite products as they’re no longer fit for purpose.
  • Development teams must deal with the bad work of other developers which may cause attrition and loss of talent. Can cause “broken window” syndrome. It’s in a mess already so why fix it.
  • As it gets worse customers complain about slow delivery which in turn increases the pressure to take more shortcuts, which increases the technical debt. In essence its a rapidly spiralling eternal return.

Options for dealing with Technical debt

Unfortunately, by the time organisations are paying attention none of the options are good.

  • 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
  • Stop creating more technical debt and systematically invest in incremental improvement.


b-agile’s Professional Scrum courses Professional Scrum Master course discusses the concept of Done and Technical Debt to a level needed by Scrum Masters and Leadership teams to be able to educate the organisation in the impacts and how to manage it.


b-agile’s ApplyingProfessional Scrum for Software Development courses gives an experience of how to deliver quality software with Scrum and DevOps practices. Understand how modern Agile engineering practices and supportive DevOps tools improve a team’s capability to deliver working software. Gain knowledge of how to leverage modern software development tools and practices.



b-agile has Technical Coaches that have extensive experience in helping organisations reduce their technical debt and gain the mindset, culture, skills to enable business agility. If you’d like to know more or how we can help you or your teams build healthy products then check out our Technical Agility services. Or contact us to get in touch.

In our next post, we’ll look at a few ideas of how to turn the ship around

How to pass the Professional Scrum Master PSM I assessment

how to pass the Professional Scrum Master PSM I assessment

The Professional Scrum Master assessment consists of:

  • 80 questions
  • 60 minutes
  • Online Multiple Choice

Subject Areas

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


Read the scrum guide line by line and number of times. 5 would be good. This text has been refined over many years and every word has value. Understand each sentence in depth in terms of events, roles, artefacts and rules that bind them together. Understand inspection, adaptation and transparency and the Scrum values that create the foundation of Scrum.

The PSM 1 assessment will look at questions wider than the Scrum Guide. You will need to be familiar with topics such impact of technical debt, scaling Scrum, complimentary practices like velocity, user stories, burn charts and many others. Understand the difference between what is Scrum as define by the Scrum Guide and what is not Scrum but often associated with it.

Open Assessments have created open assessment practice tests for different subject areas. Our advice is to take them all to experience a wider selection of questions to enrich your overall understanding of Scrum. When you get a question wrong, note the correct answer and assess why you answered it differently.

Our advice is to be passing the Scrum Open at 100% repetitively before taking the PSM I.

You will need to create an account with before you can take the free open assessment for practice

Take the free open assessments:

More information available at Scrum Master Learning Path and Professional Scrum Competencies

Possible Reading List

  • Scrum – A Pocket Guide’ by Gunther Verheyen
  • Scrum Mastery’ by Geoff Watts
  • Servant Leadership’ by Robert K. Greenleaf
  • Coaching Agile Teams by Lyssa Adkins
  • Software in 30 Days by Ken Schwaber and Jeff Sutherland

Further reading:

  • Lean Change Management’ by Jason Little
  • Reinventing Organizations’ by Frederic Laloux & Ken Wilber
  • The Nexus Framework for Scaling Scrum’ by Kurt Bittner, Patricia Kong & Dave West
  • The Surprising Power of Liberating Structures’ by Henri Leipmanowicz & Keith McCandless
  • The DevOps Handbook’ by Gene Kim, Jez Humble, Patrick Debois & John Willis
  • The Professional Product Owner’ by Don McGreal and Ralph Jocham
  • Product Mastery by Geoff Watts
  • The Product Samurai by Chris Lukassen
  • Reinventing Organizations by Frederic Laloux & Ken Wilber

Couple of useful blogs

Are you ready

If you already have some experience in Scrum you may feel comfortable to take this challenging and rewarding certification. If you don’t feel quite ready and feel you want to learn in a team based, collaborative, and transformational learning environment then see our class listings here

We’ve a very high success rate record in our course attendees leaving either our PSM or PSF courses with a deep understanding and knowledge of Scrum, and we also offer free after course support, to enable them to pass the PSM I assessment.

Taking the test

  • Have a good stable internet connection
  • A place where you won’t be disturbed for 90 minutes
  • Recommend completing an Scrum Open Assessment before taking to help get focused
  • Take at a more energetic time of day
  • Recommend not taking late at night, or after a busy day or after a glass of wine!
  • If you get stuck on a question give it your best guess, bookmark it and move on. You can go back to the bookmarked questions later.

Hope this post aids you in your preparation for the PSM I assessment. Good luck from the BAgile team.

Why should you go on a Professional Scrum Foundation course? Professional Scrum Foundation logos

Some may confuse the word “Foundation” in the name of the Professional Scrum Foundation course to mean simple or basic. But in truth, this means it is a course for everybody to build a solid base of knowledge, understanding and practical application of Professional Scrum.

Everyone in your Scrum team and the managers/leaders who are interacting with your team should be able to answer

  • What is complexity? How does Scrum framework help us develop and sustainable deliver complex products?
  • What is empiricism? How do the Scrum Roles, Events, Artifacts enable and ensure this empirical process works?
  • What is self-organisation? How does the Scrum framework help an organisation and its reams become self-organising?

Who should attend?

  • Are you curious about what Scrum can bring to your products and organisation?
  • Are you supporting Scrum Teams in a leadership role, stakeholder, or other capacity and want to understand how Scrum works and how to collaborate together?
  • Are you interested in a career change and have no experience in Scrum?
  • Are you doing Scrum in name only and nothing has changed? No mindset, culture, or increased agility change?
  • Are you NOT delivering a “Done” Releasable Increment at least once per sprint, therefore enabling transparency, trust, and greater business agility?
  • Are you NOT gaining better customer outcomes and business benefits?
  • Is Scrum NOT helping you manage risk and complexity?

The Professional Scrum Foundations course is the perfect introduction, reboot or refresher to Scrum. This course is for organisations, teams or anyone wanting to experience the Scrum way of working. PSF provides the base knowledge needed for anyone interested in taking role-focused training’s.


Over the 2 days, students experience Professional Scrum with the practical application of Scrum. Students work together as a team in a series of Sprints to build a product, thereby facing real-life problems. The rules, roles, and principles of Scrum are leveraged during the exercises. From its emphasis on the practical application of Scrum, the course exposes common missteps and misunderstandings so students grow a higher awareness of the associated symptoms. The course provides prescriptive guidance to avoid going off track and keep Scrum healthy.

What previous students have said?

We ran a small experiment with students who attended a PSM course and had little or no knowledge or experience of Scrum beforehand. We offer them to attend a PSF the following week, if they could gives us feedback on – “Which would you recommend to someone, PSF or PSM, who has the current experience & knowledge you had before taking either course?

“I enjoyed both courses honestly but if I had the opportunity to choose which to take first I would take the PSF first. My reason is that the PSF is broad and covers all areas of scrum, and obviously has a lot of fun exercises. It’s fun to work as a Scrum Team in Sprints to deliver a product & the exercises to learn Scrum. The PSF is also more laid back on the second day which relaxes everyone. The PSM on the other hand is more specific and detailed compared to the PSF. It would greatly benefit someone who has some knowledge on what scrum is.  My recommendation is the PSF first.”

Fortunate Ngwang – Changing career

“As with the PSM course, the PSF was fantastic! I will be suggesting that people take this one before they decide to take on either PSM or PSPO. Despite being a virtual class, the level of interaction was amazing and your teaching style speaks volumes in terms of the number of people, including myself, who crack the not-so-easy assessments with flying colours. Thank you! “

Abhijeet Basu – Project Manager

What you get for taking the course

  • Facilitation and coaching from highly experienced Professional Scrum Trainers
  • Debunk myths, dispel misconceptions, and gain a true understanding of Scrum
  • Gives students the knowledge and direction to start using Scrum and cutting practices immediately after the class
  • Create a transformation plan for the adoption of Scrum within your organization/team in the class with the support of the trainers’ transformation experience
  • 2 attempts at the Professional Scrum Master I certification and a 40% discount from Professional Scrum Master II certification

If your ready to take the next step you can find BAgile’s Professional Scrum Foundation course schedule at