What Acceptance Criteria Are; Why Data Teams Need Them

Acceptance Criteria for Data Focused User Stories: Part 1

Acceptance criteria are a game-changing tool for data teams. They directly lead to more efficient team members who understand the impact their work has on the organization. Unfortunately, acceptance criteria are not always used or implemented well. It is important to know what they are (and what they aren’t) in order to get the best results.

The Benefits Acceptance Criteria Have on Your Team

There are several factors that create a fulfilled and productive data team:

Yet I’ve noticed that agile software teams are happier and more fulfilled than data teams. This stems from the acceptance criteria portion of that equation. That’s because we as humans like to see tangible progress, and that’s easy to see with software products. With data, not so much.

For example: Agile web development projects. The team always knows when they are finished because they have a tangible product, they feel a sense of accomplishment and move on to the next part. This contrasts to the experience of most data teams.

So how can data teams create this knowing of goal accomplishment? Acceptance criteria are the product owner’s way of ensuring their team knows when the job has been completed.

What Acceptance Criteria Are – And What They Aren’t

[bctt tweet=”Acceptance Criteria are often confused with the Definition of Done.” username=”agilelynn”]In order to achieve that sense of goal accomplishment, it is important for data teams to understand the difference so that they can use acceptance criteria in the correct way.

Acceptance Criteria

Acceptance criteria applies to individual stories. They come from the product owner and are used by the stakeholders to assess whether or not the purpose of a story has been accomplished. Here’s an example:

• Recognize the revenue from the sale of a product when:
  • Software product has shipped
  • Hardware product has been received by the customer
  • Installed product has been installed at the customer site for 30 days
  • Services are complete
• Test against 16 specific orders to confirm combinations of products on a single order.
• Test against Q3 last year data to confirm revenue recognition aligns with prior finance system results (this scopes it to a certain time frame).

These are great acceptance criteria because the team knows what the goal is and they also know what’s not in scope (e.g. data outside of Q3).

Definition of Done

The definition of done will differ from team to team (so don’t worry if yours does!). What follows is an example from one team I worked with. “Done” applies to all stories and it comes from the team. It’s their agreement of how they are going to do work. Here’s an example:

• Unit and acceptance tests are written before development
• All unit, acceptance, and regression tests pass
• Each story has been reviewed by a peer to confirm the development and performance standards have been met
  • Informatica Standards v 1.3 (2/5/17)
  • Tableau Standards v2.5 (11/15/16)
• Documentation updated:
  • Support guides for Tiers 1, 2 and 3
  • User training – onboarding and updates
  • Enterprise data dictionary

Happy data teams know what their end users want and how their work benefits the organization. They feel accomplished and have clear goals. And you get there by creating good acceptance criteria.

Read Acceptance Criteria for Data-Focused User Stories Part Two- What Happens When a Story is Not Accepted