Do you know why you’re following a particular process?

The reality dawned on me. I’d been blindly following a process with little thought. Why was I doing this?

As a team we’re winding down a large estate of products to be replaced with Commercial of the Shelf (COTS) packages. SaaS and Digital Transformation, that kind of thing.

Currently, I’m a Product Owner and my main role is to ensure that we limit our Features to what aligns with the strategic vision of replacing all our systems.

Process wise, this allows me to keep the teams Jira issues quite light as our changes are mainly small and ad-hoc.

For a few months I’d been creating Jira tickets in what I believed to be a fairly standard way.

I add the:

• stakeholder details
• their original request
• a user story
• any further context
• some screenshots if applicable
• definition of done

There it is — right at the end of the bullet list. Definition of Done. Where did I get that from and why am I putting it there?

Just to recap on some terms:

Issue

An overriding term for Story, Feature, Bug, Spike, Ticket.

Definition of Ready

What does an issue need to have for it to be considered ready for development?

Examples are:

1. Be refined by the team
2. Contain Acceptance Criteria
3. Follow INVEST

Definition of Done

What does an issue need for it to be considered as completed?

Examples are:

1. Peer reviewed by two team members
2. Stakeholder accepts change
3. 85% Unit test coverage
4. Acceptance Criteria met

Acceptance Criteria

Things which add constraints to be issue.

Examples are:

1. 2% Increase in NPS when Purchasing (lovely bit of validated learning)
2. Telephone number Input field to use country specific Input Mask
3. Report can be downloaded in CSV format
4. Kevin can access the accounting screen

Back to me writing Definition of Done (DoD). From the recap, I was really writing the Acceptance Criteria (AC) for the issue.

As I rummaged through Jira tickets made by my predecessor I could see that they used DoD in place of ACs as well. The team lead uses DoD. So, it seems something specific to our team and project.

No biggie, I thought. In all future tickets I’ll use AC. It’s more aligned with industry practice and will potentially avoid any questions with newcomers to the team getting confused. I let the team know of my intentions on the next standup. There weren’t any objections and a few people asked about the differences, so I gave the examples listed above.

A few months later..

Fast forward a few months and I’m happily using AC — the SRE part of the team has stuck with DoD on their issues, but that’s fine. For a different piece of work I need to jump into a different teams Jira project and lo and behold..

They’re using DoD there as well.

I’m concerned that this is systemic across the organisation. It’s quite an Agile organisation, one of the most Agile I’ve ever worked with. In theory they know the difference between the terms, and therefore have taken a proactive decision to name AC as DoD and this is documented somewhere in the Development Handbook.

“The development handbook is the central source of information how we develop technology at Omni Consumer Products. It is a written guide covering the process, policy, guidance and other information needed for people to build software and hardware systems ‘Omni Consumer Products’. This handbook is considered the canonical position on any given topic.”

I’ve replaced the organisation name with OCP. If you’re too young to know of OCP then feel free to replace it with SCP! Although the real company is very fluffy in comparison.

The Development Handbook is an amazing resource, thorough, but doesn’t cover something as basic as writing a Jira ticket.

So, I moved on to asking some of the leadership. In general, one area of the business uses DoD. But they all use it in slightly different ways. Some for each individual issue like my experience, others for Stories only; some for larger stories.

In another area of the business, the DoD is documented at a team level. More in line with what I expect to be industry standards.

To sum up, the term “Definition of Done” is used in different ways depending on which team and what part of the organisation you are in.

This doesn’t cause any problems that I’m aware of, each team understands what their definition is. It fits into their own workflows with all the other idiosyncrasies that naturally occur between teams. There may be a 1-minute eyebrow raise if someone moves between teams, but in reality, I cannot see this particular difference causing too many issues.

This is probably why no one has really looked at the bigger picture and tried to understand how this has organically grown. The more worrying aspect is that people are used to their local convention and haven’t thought to question it in the past. At regular intervals it’s prudent to review process to see if it’s still valid, working for the team and fit for purpose.

If people are blind to their daily routines and practices, there could be more serious issues bubbling under the hood that people are not aware of.

But in this instance, we’re only talking about a minor point. The definition of definition of done… everything will be fine…