Posted on October 28, 2014
Given how sophisticated and configurable JIRA is, you’d think that handling dependent design and development tasks would be a piece of cake. It’s not. Usually, the Product -> Design -> Frontend Dev work that goes into creating a new feature/functionality has to happen in order; i.e. it’s hard to start frontend development without visual designs, and it’s hard to start visual design or frontend dev without some wireframes, user stories, and acceptance criteria...
Let’s say that we’re developing a “Create New Project” form. We’d need a designer to create visual designs to represent the form, its various states (e.g. active and disabled buttons, errors, confirmation messaging, etc.). We’d then need a frontend developer to create the HTML form, interaction elements, styling for all states, and JavaScript for submission of the form. We’d also need a backend engineer to handle the server-side scripting to write the submitted content to our database, or if we have a RESTful Web Service we’ll replace this with an integration task for the frontend engineer.
These various cross-functional tasks are most often spread out over multiple sprints (if you’re doing 1-2 week-long sprints). So, what’s the best way to create and track these dependent tasks in JIRA such that we’re not creating duplicate tasks (e.g. one for each of the functions) but are still able to take the story-point credit in the appropriate sprints for when the work is done?
I’m not going to leave you in suspense, here’s how you do it. Leverage the use of JIRA “Components," along with a new Kanban board specifically for your design team. Usually, a very simple Kanban board will do the trick -you can get by with only three columns/statuses: Ready, In Design, and Design Done. If you’d like, you can add another column for Product or UX before the Ready status. Note that you’ll need to create a new workflow in JIRA to support your new design board. When creating your design board, create it from your existing project but change the query filter so that it only ingests tasks having component = “design”.
Now, you continue creating tasks as necessary in the main JIRA plan board for your project but you add the component “design” to any that require design work. These tasks will automatically show up on your design board in the Ready column for your designer to pick up and move to “In Design” when she starts working and to the “Design Done” when complete. This allows you to move the same tasks to the current or future sprints, or leave it in the backlog while the design portion is being done. Another handy artifact of this method is that the current design status for all tasks that have the “design” component will show up in the task pane on your main project board, which facilitates planning and let’s you see from a glance whether or not they’re ready to be added to the next sprint.
There are many other ways of handling related design and development tasks in JIRA. You could simply create separate but identically named tasks for Design and Frontend; the problem with this approach is that it’s messy and time-consuming to create and maintain duplicates; moreover, the conversation that happens on one of the two tickets in JIRA (i.e. Q&A between designer or developer and PM) won’t show up on the other.
Why not just add add a column for “In Design” to your main Development board instead of having a separate “Design” board? It’s definitely possible, and will work in many cases, but it complicates your Development board, which I like to keep as simple as possible. Moreover, if you’re working on a highly technical product, with more application/backend development than design and frontend, then you’d be adding a column/status to your Development board that most tasks will never pass through, which is an indication of a sloppy or poorly thought-out workflow. Finally, with this approach, you can’t spread linked design and development tasks across multiple sprints without having them stagnate on your board at some point.
Another approach is to create Parent and Child tasks on your main Development board. In this case, the design portion would be a child task as would the frontend and backend development. One of my biggest pet peeves with JIRA is that child tasks don’t show up in Plan mode on Kanban boards (making planning challenging); thus, it makes more sense to simply create a new epic for the feature and tasks within the epic for each of the design and development tasks. Unfortunately, this gets us no closer to our goal of cleanly managing this process. It’s still subject to all of the inherent issues that we identified above.