Definition of Done vs. Acceptance Criteria

Let's clear up a very common confusion: What's the difference between "Acceptance Criteria" and the Definition of Done, and which is which?

Sometimes, people ask "what is the Definition of Done for this User Story?"
And then, they proceed to document a feature's Acceptance Criteria like this:

1. Feature works
2. All tests passed
3. Documentation written

To make it short: in this example, AC's and DoD are backwards. Now, let's clarify.

Acceptance Criteria

A backlog item's Acceptance Criteria are stated from the perspective of the item's consumer: what defines, for them, that the item is successful?

I hesitate to say, "user acceptance", because sometimes, backlog items are not intended for the end user. If we ignore that case, though, the Acceptance Criteria could be written like simplified User Acceptance Tests: verifiable statements that can be answered with "yes" or "no", and tested by examining the product itself.

Good Acceptance Criteria would be, for example:

• I get informed about my current balance
• I get a warning when my balance is negative
• I get a notification when my balance has changed

As you see, Acceptance Criteria are things that the product does when the item is completed. They are not things that the development team does to the product.

Definition of Done

The Definition of Done is, as the term says, a definition, of what everyone in the development organization, the Product Owner, as well as stakeholders, should understand, when someone uses the term, "Done." 

The Definition of Done is a set of mandatory activities that apply to every single backlog item. It's a checklist-style itemization of things that the team does to the product in order to call a single backlog item "Done."

An example of a Definition of Done is,

• Code written
• All tests Passed
• Successful deployment to Test environment
• Mandatory documentation completed

When you have such a definition, it does not make sense to add these points again to every single backlog item.

But ... the DoD doesn't apply to this item!

Well, it's entirely feasible that the amount of effort to complete a specific DoD activity on an item is Zero. That means it's by default "Done", because all the work required is completed with zero work.

Another thing is when you specifically want to make an exception from your DoD for a specific item. Well, as long as it's an exception, you understand and accept the consequences, and everyone including the customers agrees to take this route, that's okay, because transparency is there.

Although I would caution that if it happens too often, you may want to check whether your DoD makes sense.

But ... it's a specific task for this item!

That's okay. Then add it that task to the item. It's still not an Acceptance Criterion, and it doesn't affect the applicability of the overall Definition of Done.

Discerning: AC or DoD?

	Acceptance Criteria	Definition of Done
Describes ...	What the product does	What the team does
Quality of ...	Product from user perspective	Work from process perspective
Applies to ...	Specifically this backlog item	Generally all backlog items
Met when ...	Verified by a test	Agreed inside team

Remote Agile Coaching

Probably the biggest challenge Agile Coaches and Scrum Masters face during the Corona Crisis: "How do I effectively coach - remotely, especially when people are distributed?" If you've never done this before, you might be stumped.
Fortunately, this has been my business model for a few years already, so I might have some pointers that could help you get going.

Your most precious asset  - the coaching journal.

First things first: Remote Agile Coaching is much more difficult than on-site coaching, and can throw you into an existential crisis. I have spoken to many Scrum Masters who felt this was "just not for them", and I won't claim that it's the same thing. It's oftentimes less effective, more frustrating and less gratifying than working with a team face to face. Yet, when it's the only option - you've got to make the most of it!

Remote Development is still fairly easy compared to Remote Coaching: while a Developer has a clearly defined code objective and the work they do happens entirely within their IDE, the CD pipeline and on servers - whereas the coach relies on human interactions and thinking processes. These are often entirely invisible in distributed teams.


There are a number of key elements to your success in Remote Coaching. To keep this article at least somewhat concise, I will focus on only two aspects:

• Coaching Agenda
• Execution Signals

Disclaimer: This article is not an introduction to Agile Coaching. It's mostly concerned with the key factors of successful Remote Coaching. Therefore, important aspects of Agile Coaching may not be covered.

Coaching Agenda

It's quite easy for colocated coaches and/or Scrum Masters to work successfully in a sense-and-respond mode, i.e. simply be there for your coachees, observe their actions and use spontaneous communication to trigger reflection and change.
The same is not true for Remote Coaches, who are limited both in senses and responses - the value proposition is more in the line of triggering "the big hitting changes". And since you can't push change, you need to figure out what people need. This can't be done ad hoc, so you need an agenda.

To begin with the Obvious, it's not sufficient to facilitate the Agile Events (Planning, Daily, Review, Retrospective, I+A, PIP) - you'll be entirely ineffective if this is the only thing you do! You need many other things, and you need them without infringing on the work of your team(s). And that's the challenge: You must enhance the team's ability without infringing on their capacity.

Providing methods

As an agile coach, part of your competency is providing effective methods. And since you don't have full real-time interaction, you need both a plan and the means to roll methods out.
So, here are some things you need:

• Start with a delta assessment on what's missing and create an overview of the required methods that would be needed by the client.
• Arrange the necessary items in a method introduction backlog. Put it into a digital backlog tool and let your client prioritize it (not just once, but all the time!)
• Ensure you have the right technological means to make the methods available. If you need, for example, an Online Retro tool, you'll have to at least come up with a first option, because when the client doesn't know the method you're talking about, they are not yet in a position to make a choice which tool to use!
• Some tools do not support the method you're using, so you either need to adapt your method to the tool or find a better tool. Still, avoid introducing a zoo of "Agile tools" - you'll never find your information afterwards! (Therefore, it pays to know what's still in the backlog so that you're not reverting last week's choice every week!)
• Keep privacy and security constraints in mind. You can't use just any Cloud Platform and put confidential information there!
• Remember organizational standards: While team autonomy is a great thing, it's terrible for the company if 12 different teams use 15 different delivery platforms: You may need to align certain tools with other parts of the organization.

Speed of Change

Probably the biggest mistake I have made in the past: since you're sitting remotely, you may not understand how time-consuming other activities in the organization are. This can lead to not respecting your coachees' ability to process change. What may feel terribly slow for you as a coach may be all they can stomach, and what's the right speed for you as a coach may overburden them, because their daily business is so time-consuming. As a coach, it's important that you set back your own feelings in this regard.

So, here are some specific tips:

• Figure out what the "right" rate of change for your client is. 
• If that means you'll only have one change-related coaching session per month, don't push for more.
• Instead, if your time on that topic is so limited, spend more time preparing to maximize the value of the session.
• Create a timeline of what changes will happen when, and align with the client.
• It's significantly better to do one high-impact change than ten low-impact changes, because that puts less stress on the client's organization.

Meta-methods

Not all coaching methods that you'd use face to face are effective in a remote setting, and your have a less effective feedback loop. The time between applying a method and discovering the outcome increases, as does the risk of misinterpretation.
Some methods tend to be much more effective in remote coaching than others, though, and here are my favorites that you should definitely at least try:

• Journaling. Keep a journal, and reflect on it at frequent intervals.
• Canvases. To structure communication, experiment with canvases both during sessions and as prep work.
• Screenwriting. It can have a massive impact on your coachee's reflection if you do nothing other than write on the screen the (key) words they're speaking. The upgrade is screen sketchnoting, but that's ... advanced.

Homework

In remote coaching, you have to work a lot with "homework" - both prepping and follow-up. This is equally true for both you and your coachee. Make sure that right from the beginning, you have a Coaching agreements that ensure the coachees will be diligent on their homework, so that you get maximum value out of each session.
One such coaching agreement could include, for example, that it's no problem to cancel or postpone a session if homework wasn't done.

Typical homework assignments for the coachee can include:

• Trying out something discussed during coaching
• Reflecting on certain outcomes
• Gathering certain information to make a more informed decision next time
• Filling a canvas (see above)

This is where the meta-methods come into play again: as a coach, you'll need to remember what homework was agreed during the coaching session. You should have another agreement that it's not yours, but the coachee's responsibility, to track and follow up on this homework. Still, you need to keep track if the coachee does this to remind the coachee if an important point slipped their mind.

Execution Signals

 A remote coach is both limited in observation and interaction, it's much harder. You're losing out on a lot of the subtle nuances of (especially non-verbal) communication going on.

Since people are busy with other things, and you don't want to interrupt your coachees at inconvenient times or with distracting questions,you need to collect your information:

Pull coaching

A big issue I had in the past is that nobody pulled coaching, despite a Working Agreement that people would contact me if they felt the need. This rendered me ineffective and worthless to the client! It happens, for example, when people are unaware of what the coach can do for them, or feel they're inconveniencing the coach.

• Make sure people send you frequent signals, or ask why this is not happening.
• People have understand where they can pull in coaching - discuss the intent and purpose of coaching.
• When people are overburdened, coaching is the first thing they drop. Have that conversation when  it happens!

Exceptions

How do you know that something is going well or requires attention?

The general idea is that you can trust the team that things are going well until they inform you otherwise! This should be clarified in a Working Agreement!

• You have to expect that you coachees may have blind spots and don't know when something isn't going well. So, you need access to further sources of information. 
• The ticket system, for example, is often a great source of information for the usual problem hotspots: overload, overcommitment, overburden, delays, impediments - whatever. 
• Ensure you're not monitoring the team or their work, but their ongoing success!

Outside-Ins

How do you deliver outside-ins? In Remote Coaching, there is a lot of asynchronous communication that you need to bring together. For example, in your work with the coachees' stakeholders (e.g., management, users) you learn things that the coachees would need to be aware of. 

This requires both a communication strategy and frequent synchronization points, so that you're not interrupting or shooting out the message with unintended consequences.

(A specific learning - simply posting something in the team's chat channel that you could have  mentioned in the team's physical office without problems can start a wildfire, so you need to choose words wisely lest your "coaching" becomes more of a distraction than a help.)

Conclusions

If this is your first time Remote Coaching, you may be overwhelmed by this article, and yes - it does take time, thought and preparation to get going.
Sitting back and reflecting on your colocated coaching experience is a great way to get started.

If you have any questions, reach out to me. My contact information is in the Imprint.

Remote work is coming - some pointers for developers

Many organizations find themselves struggling with the Corona Crisis, because they have never prepared for Remote Working. Without going into the reasons, I want to give you some pointers from my own experience of what you can do to make the best out of it.

The domain is huge, so in this post, I'll focus only on Developers in order to keep it a bit concise.

A remote working space - doesn't mean it needs to be much different from an office.

Working Remotely as a Developer

This has three domains:

• How you yourself work
• How you collaborate with your teams
• Participation in agile events

We'll take a look at each, separately.

Working remotely

Working remotely by myself, I have come to appreciate the value of a desk with three-monitor layout: Centrally in front of me, the laptop - on my left, the Web Meeting where I can see people's face - and on my right, a browser where I can switch between the latest build, the CI tool and the ticket system.

It's incredibly hard to maintain break discipline, and so I often spend many hours glued to my seat, despite all promises to myself to take frequent breaks. Therefore, an ergonomic chair is essential.

Although I do what is arguably called "home office", I refrain from taking the laptop anywhere else except my desk. I maintain an isolated (albeit small ) room as office which is noise protected. Still, I only un-mute the microphone when it's necessary to speak.

I maintain "regular office hours" (i.e. typically between 7:30am and 6:00pm) because that's when others need to contact me and I need to be there - for them! 

Since I have the luxury that I have a wall right in front of me, I also keep a Personal Kanban so that I'm always aware of where I myself am heading at the moment. I am not sure how important this would be to developers whose only goals are the team goals - as a remote coach, it helps me tremendously.

( While I have heard rumours that other people don't seem to do this, I keep the same level of hygiene as if going out, including proper attire. Everything else would just be gross - to myself! )

Team Collaboration

This section is more specific to developers, although similar aspects apply to other roles and responsibilties. You don't need to write code to rely on some basic teamwork practices.

Continuous Integration gets an entirely different meaning when working distributed and remotely - especially if your code base is bigger than your team! I prefer to commit after every single line of code change, whenever tests run green. Yes, that can be dozens of commits in a single day, and that's actually how it should be. If you haven't done so yet, now is the time to learn how to rigorously and reliably apply CI and Clean Code practices. It saves tons of arguments and headaches!

A physical board is out of question when nobody is in the room - you'll need a virtual task board, a.k.a. ticket management system. Without entering too deeply into the solution space, you'll need to update your tickets in real time is essential to keeping the team synchronized. The perfect time to update a ticket is to use the CI time between "Push" and whenever the CI returns the commit status. Commit hooks could be valuable to automate this process as far as possible.

I hate disrupting development because of meetings, but we need to synchronize - frequently. The easiest way to cut down on the need for synchronization through frequent pair or mob programming sessions. To do that in a remote setting, you should find an IDE plugin that supports remote pairing, and if your IDE doesn't support that - now may be the right time to move to a different IDE.

The next way to reduce disruptive meetings is to use your team's virtual office room and ping people, asking them for a convenient time to meet. Ideally, you're able to refrain from using separate chat apps, because that creates a different stream of communication that adds distraction and drains productivity: you've already got at least four things to pay attention to already!

Sometime, you'll want to be alone. Let your team know that you need privacy and turn off the camera when that need arises. There are many reasons - make Working Agreements that ensure everyone understands what your team's mode of collaboration is. Some such agreements could include, i.e. the need to recede, specific time periods where everyone has to be online, timeframes for pair programming etc.

Participating in agile events

Some events are inevitable, though: Dailies, Planning, Reviews and Retros for Scrum - as well as PIP, Demos and I+A in a SAFe context. 

Since this post would be too long with my full tips on each of those meetings, I'll cut it short here by giving some generic guidance:

• A "One person speaks" rule alone doesn't help because you often don't know who speaks next until that person does. Be forbearing when someone accidentally interrupts you. Maybe you need working agreements that make sure everyone gets their voice.
• Prepare for meetings offline. Reserve some preparation time on your calendar for this.
• Avoid status reporting during Dailies or Reviews. If you do this, you've got a collaboration problem that should be addressed as soon as possible!
• Arrange for appropriate tooling support for events like I+A and Retrospectives. Relying on your team office platform probably won't be enough. There are tons of tools out there. Invest time to research online collaboration tools. Experiment until you found one that suits you.