This article is part of a mini-series on Design in Agile. Here I try to tackle How should project management software be setup to support design organizational workflows?
Ideally, from a JIRA perspective, according to the book (or the SAFe coach), Front End stories should sit alongside Back End stories within JIRA Epics (aka SAFe ‘Features’). Practically, I need some epics for front-end only.
Doing it wrong at first
At first we separated front-end tasks from back-end tasks. For every feature we wanted to support in the front-end web-based SaaS app, we created an epic with stories. This effectively duplicated back-end epic feature description, and defined the front-end screens & behavior.
The benefits of this setup are that (1) it helps keep front-end tasks organized. Each epic the front-end teams worked on was its own topic. (2) The front-end teams are never a bottleneck for back-end releases. (3) Development is easier for front-end developers in that there is less ambiguity. There are high level architecture designs, low level architecture designs, data models, APIs that (should) work, and back-end developers that can provide explanations. (4) The web-based SaaS app can behave as its own product, with its own roadmap, releases, demos, documentation, etc.
Some downsides of this setup are (1) growing backlog. The back-end doesn’t wait, and its easy for a backlog to accumulate between what has been developed in the back-end, and what has to be developed for the front. (2) When features are not documented well, front end developers have a hard time understanding how to implement APIs. (3) Back-end developers do not always remember, or have the time resources to support front-end developers.
A decision was made to work differently, ‘according to the book.’
Doing it ‘right’
According to one agile consultant (yes, that’s a thing), the ‘right’ way to set up UX/UI in agile organizations using Jira, is the following. All stories are end-to-end. Stories that also need front-end in order to be considered done, contain sub-tasks for UI. The sub-tasks contain all relevant information, links to prototypes, etc.
Some downsides of this setup are (1) cadence between BE and FE is not always aligned. It takes different amounts of time for BE and FE for each feature. Something simple for BE may take a lot more time for FE, for example. Or the opposite. So it’s not always realistic for the FE teams to move at the same pace. If we require them to develop together, then one team is always waiting for another. This can delay. And it makes planning significantly more complex. The smallest mis-estimation errors or unexpected development requirement will throw off multiple teams, instead of just one team course-correcting.
So then comes along another Agile consultant, and says no no no, you’ve got it all wrong. In each EPIC in Jira, which should represent an end-to-end feature or functionality that includes both Back-End and Front-End, you need to have a STORY or STORIES for front-end work. The Front-End developers can break the stories down into sub-tasks if they want.
The most recent practice is to have the EPIC assigned to Back-End team, and include a Story or Stories assigned to front-end teams. Then, when the Back-End teams finish their work, we have a handoff event between BE and Front-End. When Front-End folks accept, then we reassign the epic to the Front-End team.
Ideal? Far from it. It’s clunky and not efficient. It’s what we got right now.
Thanks for reading.
About this Series
This article is part of series on Design in Agile based on my experiences.
About the Author
I’m a UX Designer turned Product Manager, with experience in startups, freelance, and international B2B companies. Writing helps me reflect & continuously learn. Connect with me on Twitter.
