Author: Alex Brown

Definition of Done – Where to Start?

Definition of Done Collage

Often after exploring the definition of done in our training, and exploring its importance to promote transparency and is a commitment to the increment every Sprint. A common question we get asked is how do we get started with creating a Definition of Done?

It’s not surprising a common question. Often when working with Scrum teams, we’ll ask, “Where’s your current Definition of Done (DoD)?”. The general response is either one of the following:

  • We don’t have one
  • Go searching for a dusty Definition of Done – “its somewhere in confluence”
  • Definition of Done is a certificate – representing some activities they do in a Sprint and hasn’t changed since it was created

After demonstrating the importance of the Definition of Done and a Sprint Increment,  the customer should be close to obtain real feedback & validation. The same question gets typically asked.

For me, the place to start is to obtain transparency and visibility in 3 key areas

  1. Transparency on all the activities to create a valuable, usable increment to the customer
  2. Transparency on your current Definition of Done and the gap between a valuable, usable increment
  3. Transparency on the possible improvements towards bringing the Definition of Done closer to a valuable, usable increment

Once you obtained transparency of where you are and where your destination should be. The next step is gradually bringing some of those activities into a Sprint via inspection and adaptation. This could be the challenging part and something we’ll leave for another post.

Before we go into a bit more detail on the practical steps to achieve this transparency, let’s have a quick recap on the importance of the Definition of Done.

Importance of Definition of Done

In our previous blog, Product Owners want a perfect Definition of Done. Here’s why we discussed the importance of the Definition of Done in Scrum and why a strong Definition of Done has to include all the activities to be a valuable and useful increment for every Sprint. This enables transparency and supports both empiricism and predictability in our forecasting.

The sketch below nicely summarises the importance of a Definition of Done and why it needs to represent releasable. And what happens to predictability when we don’t and have the increased risk of undone work:-

Creating a Definition of Done

Step 1: Transparency on what’s needed to have a valuable useable Increment to your customer

The first step is to get transparency of all the activities needed to create a releasable, or valuable & useful product increment to your customer. There is a number of ways to do this.

One way is to get the team to capture a list of all activities that are needed to be done before a Product Backlog Item (PBI) is considered Done so that the increment can go Live! Sky’s the Limit! Don’t be constrained to thinking about what you are doing in a Sprint.

Create a sticky note or card for each activity.

This could be achieved by simply brainstorming with the team. Yet we found a useful facilitation approach to obtain is through the use of liberating structure 1-2-4-ALL. This allows a bottom-up intelligence approach and obtains everyone’s input. If you are interested in exploring and learning more about liberating structures through practice, then check out the PSM II course.

Another useful technique is to visualise your workflow through the use of Value Stream Mapping. A Value Stream Mapping is an activity where your Team visualises and socialises the areas of efficiency and inefficiency across the whole process.

Our preference is always to execute a Value Stream Mapping (VSM) session when starting with any Scrum Team to help explore their workflow & value stream together. Any visualisation technique can be very powerful to enable understanding & collaboration – this approach is no exception. It can really help teams get on the same page & identify where the focus of improvement perhaps should be.

Being a Technical agile coach, we’ve been brought in to help establish Technical Excellence practices in teams that enable business agility. Teams tend to already have a preconceived idea of what they want to improve, yet they have no evidence for this. Value Stream Mapping can help the whole team explore and understand the workflow and collectively understand what is stopping the workflow from getting that value to the customers earlier as possible.

Step 2: Benchmark. What is the current Definition of Done and what is currently not included?

Next is to use all the captured activities to achieve a releasable increment to see what’s in your current Definition of Done and what isn’t. This enables everyone, at this point, to have a clear understanding of what is meant by “Done” and how much outstanding work there is as well, which will affect our predictability.

This step may highlight to a Scrum team the challenges ahead and entailed to have the ability to create a done increment at the end of a Sprint. And with any activity that’s not in the Definition of Done, it needs to be added to the product backlog after each sprint to enable true transparency of all the work needed for the product.

They are different ways you could achieve this, but we will give you 2 possible approaches that we have picked up on our way while working with Scrum Teams. Each option is similar, with both making it clear what your current Definition of Done is and the additional activities needed to make the increment a releasable one.

Option 1

  • Draw 3 boxes, drawing one bigger than the next & around the previous box. It can be useful to draw these boxes in different colours. Name the first inner box as “NOW“, the second outer box as “NEXT“, and the third outer box as “FUTURE“.
  • Ask the team to go through the activities created in the first step and add all the activities they are, or should be doing, in a Sprint into the first box called “NOW“.
  • Then ask the team to go through the remaining activities not selected and add any activities that they think could be included in a Sprint with either little effort or permission to the outer box called “NEXT“.
  • Finally, whatever is left in the non-selected activities, place them in “FUTURE” outer box.

Option 2

  • Draw 3 lanes, labelled “Outside”, “Inside”, and “Definition of Done”.
  • Ask the team to go through the activities created in the first step and add all the activities they are, or should be doing, in a Sprint to the “Definition of Done” lane. As expected, this is their current Definition Of Done.
  • Next, with the remaining non-selected items, select the items inside your team’s control to move into a Sprint. Any items they can do with no or little permission. Place these items in the “Inside” lane.
  • Any activities not selected go in the “Outside” lane.

Step 3: Continuously Improve towards a Definition of Done that is closer to Releasable

Whichever approach you take in Step 2, you’ll have your current Definition of Done commitment to the Sprint Increment and the possible next steps to gradually improve this towards committing to a releasable Definition of Done.

  • Everything item outside the Definition lane, or box, clearly shows everyone all the activities required for the increment to be releasable, even when you say you are “DONE”. Clearly showing how weak or strong your Definition of Done is right now.
  • Your next steps and focus are to begin strengthening your Definition of Done, to be closer to be a releasable increment. This means looking at the “NEXT” or “Inside” items and moving them into the Definition of Done. Having these appear transparently may help raise any possible discussions or support needed by the team to bring them across and into Definition of Done.
  • Once all the “NEXT” or “Inside” items are moved to Definition of Done, then its time to move on to the “FUTURE” or “Outside” items. These will likely need some organisation changes or support. Making these activities and challenges transparent early on will also help with some early discussions that are likely needed with key members or leaders to bring these into Definition of Done.

What’s needed after you have this transparency of the missing gap (undone work) to have a valuable & useable Definition of Done is to inspect, adapt and move these not yet included activities into your Definition of Done.

Like further help?

We’ve created a mural template that puts this all altogether. You can download it from here – Create your Definition of Done. If you have any feedback on how to improve, then do let us know.

If you are using Scrum to deliver a Software Product, there will likely be some challenges for a new Scrum Team to create a potentially releasable increment every Sprint. If you, or your Scrum Team, are looking for help with these challenges, then the Applying Professional Scrum for Software Development (APS-SD) may offer some help. It is a 3-day hands-on course where you will experience how to deliver quality software using Scrum with Agile and DevOps practices.

We also offer technical excellence coaching, so if you want to reach out and discuss this further, please get in contact at

Thanks for reading and if you want to learn more about Scrum, scrum mastery and product development, why not check out our courses?

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 actually 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 is 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 in terms of traditionally testing. This can cause people to go down the wrong rabbit hole and begin 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 “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 the test first had a tremendously 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, besides 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 helping 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 requirements 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 the business domain, so that the business vocabulary permeates right into the codebase. Dan and his colleagues used a similar concept to come up with 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 based BDD framework of JBehave, the leading BDD framework is Cucumber and reads executable specifications written in plain text that follows some base rules called Gherkin. It is used by the 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 endpoints.

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 a detailed readable description of the system’s function through proper examples and other necessary information. And with a focus on an 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 as to why is it different from what we were doing. Perhaps this was because we already practicing Domain Driven Development, collaborating, and using a test framework with a Given-When-Then option. And the “Acceptance Tests” occurred at the end-to-end tests but also at the component, integration, and unit tests too.

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


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 developed using an outside-in workflow to build the product right that’s highly automated.

Understand each of the practice’s 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 a BDD tool so doing BDD.

Personally, I keep it simple and use the BDD term when the 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 designing 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.

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

Since writing this post, has renamed Professional Scrum Foundations (PSF) to Applying Professional Scrum (APS). Yet the information on this below still stands, as the name change is to better communicate the intention and positioning of the course. They are now better aligned.

Note also renamed the Professional Scrum Developer (PSD) course to Applying Professional Scrum For Software Development (APS-SD). The course content & learning remain unchanged. And the related assessment and certification are also unchanged for both courses. You still get 2 attempts at the PSM I assessment for the APS. 

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