Defining Process Definitions:

How Software Testers Can Help Define Process Definitions

By Steven Burton

The “Definition of Done” is a very common and well known artefact produced by a Scrum team. However, it’s not the only “Definition” artefact that can be produced.

Wherever a team has a way of working they wish to define and ensure is followed, they can produce a definition that will help them do this. It’s very important for any team to have defined ways of working that all team members understand, agree on, and can follow. This helps the team avoid confusion, frustration, and disagreements. They also help get everyone pushing in the same direction. Definitions empower every team member to get involved with creating and continuously improving the ways of working together.

Testers often have a great understanding of the way a team works and a connection with every team member. A tester is in a good position to help drive the creation of these definitions and involve the whole team in this process.

Below are a number of tips in order to guide the creation of several kinds of definitions. In addition to the tips, there are example definitions for specific situations which come from my own experience.

General Principles For Defining A Definition Of Done

No matter what you create a "Definition" for, there are some general principles you should follow to make your definition as useful as possible:

Agent Of Change

A definition can be a great way to look to affect change on to a team or a process. When Scrum teams form at the start they will often create a Definition of Done for a user story but many other definitions evolve as time goes on. There can often be issues that the team would like to address and a definition can be a great way of doing this. It can allow the team to tighten up a process and ensure the right things are being done at the right time.

Make It Realistic

When a definition is created to make a change in the team, it’s important that the definition can realistically be achieved within the next sprint by the team. A common issue with creating a definition is trying to do too much too soon. Agile is all about small, incremental changes and this is what a new definition needs to try and achieve.

Whenever you create any definition, try to first model what the team do now and then change one or two clauses of the definition to make a positive change within the next sprint. If this works well, then you can look to build on this and make further changes going forward.

If a definition is too difficult to achieve given the team’s current situation then it won’t help as it will simply be ignored.

Keep It Short

To follow the principles of Lean software development, there is no need to produce artefacts or documentation which will never be used. This is no different when considering creating new definitions. Does the definition have a specific purpose and is it to be used in a specific situation? If so, then try to focus the definition to the areas you are trying to use it in.

There is no point creating a definition with tens of clauses in it if each clause is not adding value. Your definition should be a short list of steps to take in specific circumstances and will be useful not only to existing team members but also to those joining the team.

Your definition should not be a root and branch examination of the team’s current processes. One indicator of falling into this trap is that you have many clauses which have nothing to do with the work in the sprint or are part of the overall agreed ways of working such as:

  • Management of the product backlog and how it is refined and maintained.
  • Details of the tools and technical patterns used in producing the product.
  • What methodology you will be using and how this will be implemented at a high level.

Promote It

Any definition is only useful if everyone in the team is aware of it and knows when and how to use it. When you create a new definition you should be trying to promote its existence and usage at all opportunities. Some ways you can do this are:

  • Print out the definition and display it around the team area.
  • If it is a gate to a column on the Kanban board, add the definition to the column details.
  • Use it in Three Amigos as a checklist of points that may need consideration.

Call It Out When It Is Not Followed

It is quite common for a definition to not be acted upon. Generally, the reasons for this come down to the following:

  • The definition is unworkable or unrealistic.
  • The definition is not known about or often forgotten about.
  • The definition is not understood by the team.

Promoting the definition and keeping it short and realistic (as detailed above) should help to combat these reasons. 

Sometimes team members will simply choose to not follow a definition or ignore parts of it. One way to deal with this situation is to ensure that it is visible to the team. Visibility is one of the key aspects of Agile methodologies and this situation is no different.  When a definition is not being followed, you should look to make this visible; and a stand up or retrospective are perfect places to do this.

When you do call it out, it’s best to make it about the team not following a process rather than an individual. You also need to be aware that there may be a good reason which might need to be addressed instead of assuming a team member has ignored a definition on purpose.  

Example Definitions

I have created definitions using the above guidelines for many teams I have led. Every guideline I create is centred around a particular artefact and describes the activities that must take place or have taken place before that artefact can move to a particular state. I’ll group these examples accordingly by artefact and state.

Artefact: User Story

State: In Sprint Backlog

This is a really useful definition, but one that I’ve seen used in only by a few teams. It defines when a user story can be taken into sprint. The idea behind this definition is that there are certain things that the team will insist are in a user story before they will agree to commit to it within a sprint timeframe.

Some things that often go in this definition are:

  • Acceptance criteria defined and understood by the team.
  • Story written using Given/When/Then.
  • Story has been estimated.
  • UX designs completed.

In my experience, this definition is most effective when introduced to teams which have an existing issue with a lack of information in their stories. A high performing team, with an experienced Product Owner, might always work on detailed, well-written user stories and in these scenarios this definition might not give a large benefit. However, for teams where poor quality user stories is an issue or teams where the Product Owner is inexperienced ( or absent altogether), the introduction of this definition dramatically increase the quality of future user stories. In these situations, it provides an excellent guide for the story writer to follow and a quality gate for user stories.

State: Prioritizing Development Work In Progress

This definition is to help the team members know which user story to take from the sprint backlog when they are ready to start a new user story.

I used this definition a few times in teams with multiple work streams as then it is not as simple as taking the next user story from the top. For this example, the team had the following work streams:

  1. Project backlog
  2. Service work
  3. Prioritised list from third parties
  4. Prioritised defects from customers
  5. Other project backlogs
  6. For each sprint, we had one backlog of all these work streams and within the work streams, there were multiple priority levels. In the service work for example, a P1/P2 incident logged by a user should take precedence over everything, whereas a P3/P4 may be less important that some of the project work in the backlog.

To help with this problem, I introduced this definition to the team, which we would use to determine which ticket to take next. Although I had not seen this particular definition used elsewhere at the time, I have since used it in other teams with multiple work streams to great effect.

Examples of items that I have used in this definition are:

  • Check if pairing is possible on existing tickets before taking a new one.
  • Always take P1 defects first.
  • Prioritise service work over project work.
  • Prioritise customer defects over internal defects.

These were useful definitions for the multi-stream teams, however, if other definitions make sense to help prioritize work, then use those. Make sure the team and the product owner agree on the priorities and then make them visible to the team either by tagging the stories in some fashion or reviewing the stories for priority in a backlog grooming session.

State: Release Ready

This definition was used to describe when a particular user story can be moved to the Release-Ready state. For this team, this effectively meant closed due to releases being handled outside the team.

There are lots of things that can go in this definition and it will largely depend on your team and the tools and processes you have, but we had the following in it for this team:

  • Existing [Unit/automated/regressions] tests passing
  • New [automated/feature/e2e] tests completed and passing
  • Code merged into [a branch]
  • Code reviewed by [developer/tester/other]
  • Code deployed to [environment]
  • [Pipeline/infrastructure/monitoring] updated and tested

Artefact: Code Review

Often definitions are reserved only for user stories. However, there are plenty of artefacts that can benefit from having definitions of how an individual and a team interact with them. A perfect example of this is a Code Review.

State: Complete

Experienced developers may think that dealing with a code review outcome is obvious, but it isn’t always. Some systems allow you to set the state of a code review to multiple different statuses like “With Comments” or “Needs Work”. For anyone new to the team or to these phrases, it can be confusing what to do when someone sets your code review to one of these statuses and this definition helps make this clearer.

For instance, does a “With Comments” status actually require any rework or is it for learning purposes? Should there be another Code Review if the status is “Needs Work” after the rework has been done?

This definition simply and clearly lays out the expectations on how to progress after a code review has been completed. An example from a team I worked in before is:

  • Code must have been reviewed by a developer and a tester
  • Status of ‘Comments’ is advisory only
  • Second code review needed when the status is ‘Needs Work’
  • Branch merged into development when code review status is ‘Looks Good’

This definition was used on all code reviews whether that review was for production code or automation code as all code should go through the same kind of quality gates. We ensured testers were part of the code reviews for two main reasons:

  • They can also be a great learning tool for testers who want to improve their understanding of coding.
  • Testers can help judge the level of unit and integration testing coverage and look to provide a different set of eyes when it comes to coverage and quality of the tests.

Artefact: Retrospective

The retrospective is one of the most important Agile ceremonies as it allows the team to look at how they can continuously improve and move forward as a team. There are many ways to hold a retrospective and an excellent resource I have used before for retrospective ideas is http://www.funretrospectives.com/. However a retrospective is held, it should always involve looking at things that have happened recently and coming up with ideas for things the team should stop, things they should continue and things they should start.

State: Closed

In many teams I have worked in, no matter what the flavour of the retrospective we would produce a list of actions that would be assigned to members of the team. These actions may be about starting or continuing things or they may be about stopping things. 

Either way, a common problem is ensuring these actions are acted upon and they are not forgotten as often the actions never get done or even followed up on.

To help with this issue, I introduced a definition describing activities that must be done to ensure the retrospective actions are acted upon. In this team, it really helped ensure that actions that came from the retrospective were not forgotten.

This definition contained the following:

  • All in team actions assigned to a team sponsor.
  • All actions outside the team raised appropriately.
  • Outcomes communicated to team and stakeholders.

This helps to ensure that the appropriate actions are taken when the retrospective is over and it helps with someone who is holding their first retrospective for the team.

State: Ready to Start

This definition described activities that must take place before the retrospective could begin and it helped to ensure that the actions from the last retrospective were followed up on.

It was a simple definition, containing the one activity:

  • Actions from the last retrospective have been followed-up.

Defining Definitions Can Help Team Processes

There are many times when a definition can help a team. Consider where your existing team can benefit from a definition of some kind, for example:

  • You have a specific issue you wish to address such as lack of detail in user stories or actions from retrospectives being forgotten.
  • You want to ensure the quality gates you have in place such as code reviews are completed correctly.
  • You want to write down ways of working so that every team member is agreed and new team members have something to refer to.
  • If the answer to any of the above is yes, then you should think about whether you can create a definition for the team to use to drive the change you want to happen.

The examples in this article are ones I have used and created before for situations I have been in, but as long as the definition you create is lightweight and realistic there are many ones you can create and use!

Author Bio

Steven is an experienced tester with over a decade's experience in the industry. After studying Computer Science at University, he landed a testing job for a medical company and has been learning and loving testing ever since.

Steven is a big advocate of CD pipelines, Agile (and Scrum in particular) and a team first attitude and has performed a variety of roles within and leading teams across many projects.

Steven has a focus on quality no matter what role he performs and enjoys participating in and learning from the wider testing and software development community both at home in Leeds and elsewhere.

You can keep up to date with what Steven is up to on LinkedInTwitter and on his website.

 

 

You Might Also Be Interested In: