How often have you read a Jira card that was so vague or badly written you geuninely had no idea what it was for?

If you’ve ever worked in an agile team, you will have used something like Jira, Notion, Redmine, or one of the many other systems for tracking work in a ticket or “card”. Almost invariably, most the cards are either written badly, or even worse, empty of any detail aside from a pithy title.

I’m going to change that.

A good agile card¹ isn’t a work directive or reminder, it’s a way of communicating background and requirements between colleagues working in often wildly different contexts.

In this series, I’ll discuss how to quickly write good agile cards, giving reasoning, examples, cheat sheets, and also some of the pit falls to avoid.

There’s just three major types of cards. Almost everything is a variation of one of these.

• Story / Feature - deliver a feature, decision, or other outcome
• Bugs / Defects - fix something that isn’t what it should be
• Epics - manage the development life cycle across multiple stories to build larger outcome

Every week or two, I’ll discuss how to write one of these cards. Finally, I’ll round out with a post of general notes, that are applicable across all types of agile cards.

First of the rank are stories, the proverbial main course. Look out for this in a week or two.