At Bitovi, we embrace the concept of a design system. Global patterns and components provide standard look, feel, and reusability across a suite of applications. We have our own, and we often build them for our clients. Ideally, a design system is fully developed and available before building applications that will use it.
For many reasons, circumstances are often not ideal. Ocaissionally, teams must build design systems in parallel with the application work. What happens, then?
How to Write Tickets for a Design System
A design system is created and managed in a tool like Figma, which means design systems live separately from platforms software development teams use to track the backlog of work, like Jira.
In order to streamline the development work, you need Jira tickets representing each design system component to be built. You can create a custom work item type or use the standard User Story item with tagging or naming conventions to keep the work separate from application tickets in the backlog.
You can place hyperlinks in each Jira ticket back to the specific Figma component (and vice versa, if desired).
Each ticket is written with a story-like description and acceptance criteria to guide the frontend developer in flexible implementation per the visual requirements. Using the Alert component as an example:
The design system needs an alert component with status, title, and description inputs so that we have one flexible alert message indicating success, failure, or system information.
In Jira, keeping these tickets as children of a Design System epic for common tracking and management is a good practice.
Connecting Components to Application Stories
Let’s say you’re on an application team, and a story you’re considering in planning the next sprint is:
As a user, I want to be able to enter a new data record so that the record can be used by other workflows in our system.
As a user, I want to be able to “back out” the last record I added so that no other workflows are affected by data that should not be there.
One of the most powerful tools in Jira (or Microsoft ADO or other similar platforms) is link types showing which tickets block other tickets. It is also common to create a “dependant”/”depends on” link pairing to specify that the relationship is different from a typical issue which blocks other work from being done.
In this case, the links from the “Create a new record” story indicate the item depends on three design system components, the “Back out” story two. In the other direction, the “Create a Button component” item would show it has two dependents, the other three Design System items one each.
The power of this approach comes on larger-scale projects with multiple Scrum teams working at scale on an application. Centralized tracking of the component work allows each team to take the feature designs they have using the system, determine which component tickets are needed for their stories and their status, and know they can safely start their own implementation if the component is not yet committed to work.
Planning the Sprint
In a scaled Agile process, you’d likely have one team developing the design system components and others developing the application features that use them.
On a smaller project, you would have to blend the two sets of work together in sprint planning and stack ranked to get the components done before each user story and create a new record before you try to back it out.
It may be challenging to have a common story-sizing approach when mixing component and user story development on the same team. Still, it’s essential to try to think of the work relative to the rest of the scrum team's work rather than having one relative scale for components and one for user stories.
Anyone who has been on a project or used an application where three developers made three different “Are You Sure?” dialog boxes is very aware of the value of a design system. Suppose you’re the Scrum Master or in another role on a team where the design components are being shared simultaneously with the actual application development, fear not. Keep everything distinct in a single source of project truth, such as Jira, with meaningful links to track dependencies, and you’ll keep delivery prioritized and velocity high!
Do you have a better way?
We’d love to hear about it! Join our Community Discord to chat about tech, seek assistance, and network.
Never miss an update!
Subscribe to the blog 📬