Using Vanillaround with Jira
Vanillaround and Jira serve different purposes and are stronger together than either is alone. Vanillaround is where requirements are defined and agreed; Jira is where development work is tracked. The integration bridges them.
The division of responsibility
Section titled “The division of responsibility”| Vanillaround | Jira |
|---|---|
| Writing and structuring requirements | Planning sprints and managing tasks |
| Client approvals | Development team workflows |
| The “what” and “why” | The “when” and “how” |
| Living specs with full context | Tickets with status and time tracking |
| Stakeholder collaboration | Engineering collaboration |
The intended flow
Section titled “The intended flow”- Write specs in Vanillaround — the delivery team drafts requirements in full context, with Client collaboration
- Get approval in Vanillaround — the Client approves each requirement card formally
- Sync to Jira — approved requirement cards become Jira issues automatically
- Develop in Jira — the engineering team works from the Jira backlog as normal
- Track both — the Jira issue links back to the Vanillaround card, and the card’s board placement reflects development progress
What not to do
Section titled “What not to do”Don’t use Jira for requirements. Jira tickets are a poor format for writing requirements — they lack the narrative structure, collaborative editing, and formal approval workflow that Vanillaround provides. Start in Vanillaround; move to Jira only after approval.
Don’t duplicate. Once a card is synced to Jira, don’t also manually recreate it as a Jira issue. The sync creates the issue; subsequent tracking happens in Jira.
Don’t bypass the approval step. The point of Vanillaround is the agreed requirement. Syncing unapproved cards to Jira defeats the purpose — the development team would be building something the Client hasn’t confirmed.
Keeping specs up to date
Section titled “Keeping specs up to date”If a requirement changes during development (scope creep, new information, a discovered constraint), update the Vanillaround spec page to reflect the change. Then decide: does this change require re-approval from the Client?
If yes — update the card and resubmit. The Client re-approves the modified requirement before development continues. If no — update the spec for documentation purposes and notify the Client via @mention.
The spec should always reflect what was actually built, not just what was originally planned.
Setting up the integration
Section titled “Setting up the integration”See Jira Integration for step-by-step setup instructions.