Scrum As Code

Jira is bad. It's tough to use, exists in some space outside of your familiar development setup and only somehow integrates with your continuous integration and deployment process. Let's imagine a world where your Scrum process happens where you feel comfortable. In code.

In the past decade, more and more tooling has shifted to be defined as code. Tools like Terraform allow you to define infrastructure as code, other tools allow you to define documentation as code. This shift brings the advantage that there is a precise textual definition which can be version controlled, reviewed, tested, documented, automated and reproducible build. This increases the quality and decreases the likeliness for bugs since every change is reviewed and tested. It encourages a larger group of people to make changes since they can be sure that another person will look at their change. Let's leverage these advantages within product management.

Product Management Tool Requirements 🔗

There are multiple requirements development teams have for a product management tool.

• It should show the things that are currently being done and the things that could be done in the near future.
• It should offer a shared understanding of the current work and a starting point for discussion on future work.
• The product manager and the engineers should be able to refine the work, adding descriptions, priority, status and acceptance criteria.
• The actual progress in the code should be in sync with the status in the product management tool.
• From the work in the product management tool it should be possible to find the related code changes. From the code changes it should be possible to find the related work in the product management tool.

From the mentioned requirements, the two last requirements are tough to solve outside of code. If the code and the product management work is positioned in two different places, they are inevitably out-of-sync. This can be addressed with relating code changes via identifiers (ticket numbers) to the product management tool. But it requires manual work of correctly relating them and can therefore be error-prone. It requires for each code change a counterpart to be manually created (You just want to fix this one-liner bug? Well, first create a ticket).

Also, is the status of the ticket in sync with the status of the pull request? You might be able to setup an automation to change the status on merge and deploy, but is the ticket actually closed with that pull request? Or will there be another pull request following after that? What if more details worth mentioning arose during implementation, shouldn't these be added first before closing the ticket?

Another complication arises with the product management tool and code being in two separate version control systems. Did the description of the ticket change after or before the change of the code? Where does this new requirement come from, was it already there during the planning meeting or with whom was it discussed afterwards?

All these things can be addressed with product management happening in the same place as coding.

Note Using code does not mean there can't be a graphical representation. It only means that the source-of-truth is a textual representation (code). There can still be graphical views derived from that.

The Idea 🔗

Representing Scrum as code requires us to find a textual file system representation of a product backlog.

The main entity that needs to be represented is the ticket (or story, backlog item). In Scrum, multiple tickets are arranged into a sprint. A ticket can only be part of one sprint. These properties allow us to represent tickets as files and sprints as directories. Creating a ticket is then the same as creating a file, moving a ticket into a sprint is moving a file from one directory to another and starting a sprint is creating a pull request moving and creating tickets into a directory.

- current-sprint
  - create-new-feature.md
  - fix-bug.md
  - fix-another-bug.md
- sprint-1
  - create-another-feature.md

Tickets are typically both loosely structured content (description, acceptance criteria, risks, notes) and structured content (priority, status, assignee). A suitable file representation of such tickets can therefore be Markdown with front-matter: Markdown allows to put arbitrary loosely structured content, the front-matter allows to define additional properties.

---
priority: 1
status: open
assignee: Alice
---

# Create a new feature

## Description

As a user, I want to have a new feature such I can use it.

- The new feature can be clicked.
- The new feature works on desktop and mobile.

## Out of Scope

- The new feature does not need to work on tablet yet.

The Graphical Representation 🔗

Structuring sprints and tickets in this way has another advantage: Static site generators can be used to render the sprints and tickets as websites. Not only can sprints be displayed with their tickets, also other views can be created that show selections of tickets by predefined criteria. Since it's purely a website, you can do any level of customization you need (yes, you could even rebuild Jira). Since it's defined in code, you can deploy that site to a CDN and have an immutable tailored graphical representation for you and your stakeholders with the right amount of detail you need. Editing still solely happens within code, the code remains the source of truth.

Other Advantages 🔗

With the Scrum process being defined as code, the typical as-code advantages arise.

• Reviews: Changes to tickets and sprints are reviewed, ensuring multiple people have a look at a change and encouraging people to make changes that would otherwise be hesitant.
• Tests: Each story in the current sprint needs to have acceptance criteria and story points? Validation for these properties can be setup and integrated into the CI checks.
• Automation: Do you want to send out a reminder to review and/or close tickets that have not been started or touched for a few weeks? You can add a script and have it run as a scheduled job in a CI environment.

Conclusion 🔗

The Scrum process can be defined as code, leveraging several advantages of reviews, testing, automation and version control that an external third-party product management tool is lacking. Sprints can be represented as directories and tickets can be represented as files.

I'd appreciate your feedback on this idea. Would you define your Scrum tickets as code? What potential problems do you see?