A Chore Gherkin

Expressing the what and the why of technical stories

Every product team occasionally needs to work on stories that provide no direct value to the customer. This may be in the form of refactoring to pay down technical debt, spiking out a potential solution, or anything in the realm of DevOps. Your team might call these technical stories either Tasks or Chores to distinguish them from Features that provide customer value or Bugs that defy expectations. Let’s call them Chores for the sake of this blog post.

When we write out the details of a Feature, we include the motivation and the acceptance criteria. When we create a Bug, we include the steps to reproduce, the expected behavior, and the actual behavior. Structuring Features and Bugs with these sections ensure that the whole team understands how the product should behave upon completing the given story.

But, what about Chores? How might we best convey the why and the what behind a Chore? I’d like to propose a Chore Gherkin:

We should <task>
Before we <dependency>
Because <impact>.

For a refactoring Chore,

or, for an infrastructure Chore,

Once the whole team has a shared understanding of the Chore’s purpose and potential impact, they can work together to prioritize accordingly amongst the Features and Bugs. The “Before we” section is intended to help the team line up dependencies and emphasize that the Chore actually needs to be done at this time.

A Gherkin-like format is a great start towards expressing the urgency of a Chore, but this particular syntax certainly isn’t perfect. I’d love to hear your suggestions!