What to do about unachievable criteria in the Definition of Done?

Question

I'm a first-time Scrum Master. I'm not even certified in anything PM-related; I'm just a seasoned Python/Django developer. However, I have read the latest official Scrum Guide cover-to-cover. I have also read a lot of articles and blog posts on the internet about Scrum, most of them critiques that seem to be from the short era where "Scrum" was a project management buzzword and lots of people were applying it incorrectly. Hopefully I am better prepared against common pitfalls when applying Scrum.

Anyway, I joined a new company last week and yesterday I conducted the first Definition of Done (DoD) exercise with my team. We are dealing with extending and evolving an existing software product into its next version. And due to the scrappiness of previous project management, the youth of the team, and the time and resource constraints, it appears that quite a few of the criteria we came up with for our DoD cannot be achieved in the imminent future. E.g. automated, repeatable functional tests and integration tests (with good coverage) are desirable, but our existing frontend has no automated test at all; somebody would need to learn stuff like Selenium and set it all up, and that takes time. An adequate level of documentation in terms of architecture, design, deployment, and usage are also desirable, but that's also currently lacking.

What do I do about such criteria?

It is obviously impractical that I say "halt everything and fix these", as we still have other things that need to be developed and delivered.

Do I keep those criteria on the DoD and mark them as "currently lacking/unachievable", and just progressively work towards being able satisfy those criteria as well, iteration by iteration?

Do I just try to satisfy more of these criteria for new development?

I mean, that's in alignment with the spirit of Kaizen, right?

What do I do about the old stuff that has already been deployed, delivered, and "done"?

Answer 1

In Scrum, the Definition of Done exists on two primary levels - the Product Backlog Item and the Increment. If you cannot satisfy the Definition of Done for a given Product Backlog Item or Increment, then the criteria should not yet be in the Definition of Done.

My suggestion is to allocate time to set up the foundations that you need to be able to get to the Definition of Done that you want. Once you have the foundations in place, you can update the criteria and apply it to work moving forward, along with backfilling when there's sufficient time. Depending on your organization, it may be beneficial to organize the backfill work into discrete, deliverable units of work and track it in the Product Backlog so it can get prioritized with new development.

Answer 2

It is obviously impractical that I say "halt everything and fix these", as we still have other things that need to be developed and delivered.

It is not unusual for teams that are new to Scrum and that are correctly applying the principles to get little or nothing 'done' in the first few sprints. This does not mean that the team achieved nothing, just that they are realising how difficult it is to make genuine, sustainable progress.

Things like automation and repeatable tests are investments. You don't get the benefits in the short-term, instead they start to pay off in the medium to long-term.

This is why it is important when a team first starts out with Scrum to openly discuss the implications to productivity. The management team needs to realise that they are making a significant change and they need to decide just how much disruption they are willing to accept. If they want to limit disruption then they will have to take the transition to Scrum slowly. If they are willing to accept a short-term productivity hit in exchange for medium to long-term gains then the transition can happen quickly.

You are doing the right things as a Scrum Master, but now you need to ensure that everyone is clear on the implications of using the Scrum framework.

Answer 3

The Definition of Done is not something that you write once and then it is set in stone. Rather it should be a living document that you and the team review once in a while to see it it needs an update.

As a DoD should be used as a checklist, it is important that it doesn't have too many items that can't be checked off, because people will likely stop paying attention to the other items as well. For that reason, your current DoD should only contain realistic items.

As for what to do with the unrealistic items?

• If it takes an investment (in time) to make them realistic, put them up somewhere as "long term goals" and try to get time/budget to do improvement actions to get closer to those goals. And once it you are close enough to one of the goals that it becomes actionable for future stories, you can start thinking about adding it to the DoD.

  The improvement actions can best be handled through the product backlog, so that they can be properly planned alongside the project work.

• If an item is completely unrealistic, then you might just as well forget about it. But first try to see if there is a sub-set that might be a long term goal.

Answer 4

In order for something to be deployed in production and actually be used, it has to be "Done". If you wrote the code but nobody bothered to test it, then it's probably not "Done". If you wrote the code and tested it, but didn't bother to see how it integrates in the whole application, then it's probably not "Done". If an inexperienced programmer wrote the code, tested it, and did the integration, but no senior developer looked over the code to see if it doesn't introduce some issues, then it's probably not "Done".

How do you determine when something is "Done"? You define some criteria that the stories must adhere to. This is your "Definition of Done". It might look like:

• code completed
• code reviewed
• code tested and all bugs fixed
• code on master branch
• functionality deployed in UAT environment
• product owner reviewed the functionality and accepts it
• etc.

This definition will probably evolve over time and you might add, change or remove criteria.

And the way in which you implement this will also change. You mention automated, repeatable functional tests and integration tests (with good coverage) are desirable. Maybe you won't have these at the beginning. Just like when you have a large story that you can't deliver in one Sprint and need to break it down in multiple smaller stories and deliver the functionality little by little over time, so you can do with the way you test. Maybe you start with manual testing first. Someone tests the feature itself then checks to see how it integrates. This meets your "code tested and all bugs fixed" criterion. Maybe next Sprint you can work to automate some of this. You respect the Definition of Done each iteration, you just respect it in a different - better way - as you go. This is what you mentioned as progressively working towards being able to satisfy these.

You can of course also halt everything and work on these items before doing anything else. But how do you know all you will need from the beginning? As you work on the software you will get new insight, learn new things, etc, so the way you do things to build the software will also evolve as you build the actual software. So, in my opinion it's better to work on both at once. Work on features and on everything else you need to build quality software at the same time. You will have slower delivery at first, but as more things are set in place this will change. Either way, it's better than not delivering anything the first Sprints while you work just on scaffolding.

And the same applies to old stuff that has been deployed, delivered, and "Done". You can add stuff as you go (regression tests, increase test coverage, refactoring, etc).

You can include this work in the stories themselves, or you can have them as separate stories in the backlog, it really depends on how mature your team is to accept how you do the work (as there is potential to affect estimations, velocity, or prioritization, etc). This is a serious discussion to have with your team and your management about which approach to choose and why this work is needed. Have the discussion, decide how you will do it, then start doing it.