Software projects take effort to manage; that’s indisputable. In order to ensure that we’re spending our time in the most productive way, we make sure that the tools we use to help manage our projects are lightweight and focused on tracking useful information. Our development team usually prefers Pivotal Tracker and our design team likes Trello. No tool is perfect, but these two seem to have the right balance of flexibility and ease-of use while providing visibility into a team’s progress toward a goal. 

Some of our clients ask us to use their internal tools. Often, that means we use Jira. “When in Rome...” we do as the Romans do—almost.

Out of the box, Jira’s Agile module (now baked into the latest version of Jira) meets most of our needs, but still needs a few tweaks to make it resemble our Pivotal workflow. This article addresses the ways we configure Jira's workflows to support a lightweight process that fits with Lab Zero’s agile software development practice. We used the settings described below in our Jira 6.x installation. The same settings are possible with Jira 7 (the latest-and-greatest) which has incorporated most of the Agile Plugin's features. 

If you’re using Pivotal Tracker or a kanban tool for your engineering teams, this will be familiar territory. For this article, we’ll assume that you’re familiar with Stories, Chores (Tasks), using a point-system for sizing stories and calculating velocity. We’ll unpack these topics in later blog posts if you want to dig deeper. Just let us know! 

Limit the Types of Tickets

Out-of-the-box Jira supports many kinds of tickets— too many kinds of tickets to be honest. We typically find that we only need a few. Here are the ones we use:

• Story
• Bug
• Chore
• Epic (not a ticket type)

Custom Workflows

Non-Accept Workflow

For bugs and chores (a.k.a. work with no story-points) we don’t need an elaborate acceptance process. We keep the workflow straightforward:

Accept Workflow

For stories with points, we want the work to be delivered on a test server and clearly be ready for acceptance or rejection by the Product Owner or Designer:

Design Tasks

Yes you read that correctly: We even use Jira for managing our design backlog. Transparency and prioritization are important in all phases of agile projects. Design’s priorities and the status of tasks should be visible to anyone on the project. This transparency can go far to assure nervous stakeholders, especially when it comes to epics with long lead times.

A design backlog and kanban is particularly useful when there is more than one designer on a team. Maintaining the board helps the design team decide how to divide up tasks. It also helps design communicate team performance to product and stakeholders.

We find that putting design tasks directly into the same sprint boards as dev work can be confusing for both teams. Design and dev have different workflows, timelines, and deliverables. To minimize confusion and distraction, we make a second “board” and workflow. We tailor this second board for the Product and Design team with their own steps in the workflow. Most of the time, that workflow boils down to:

1. To Do
2. In Progress
3. Ready for Review (indicates that design is done but that the story is still in need of stakeholder buy-in)
4. Waiting for Approval (to account for delays in getting stakeholder approvals)
5. Ready to Size (helps establish a queue of stories for the next estimation meeting)
6. Sized

Filters

By creating filters and sharing them, we give our teams quick buttons to view the tickets by status or assignee. These filters become handy when we’re looking at the board during stand-up meetings.

Here are a few example filters that we’ve used.

Columns

The project’s “Board View” should clearly show the current state of the sprint. On the Board view in Jira we show tickets that are:

• Unstarted
• In Progress
• Merge Requested
• Delivered (just like in Pivotal Tracker, this is the signal to the PO/Designer/QA to start testing)
• Accepted

This view gives us an understanding of some interesting project traits:

• What stories are ready to be accepted by the Product Owner?
• Is there too much work in-progress?
• Who has too many stories in-progress? (Implicit call-to-action: Go ask them why!)
• What should be accepted & working on the test server right now?

Reports

Not a whole lot to report here (no pun intended). We generally don’t need a chart to tell us if our flow is healthy, but one of our teams uses the burn-down chart during the sprint to keep their eyes on the prize. We wouldn’t grade ourselves on our burn-down charts, but if we see a consistent pattern that affects our ability to deliver working software—e.g. never burning down or adding too many story points late in the sprint—we’d take corrective action.

That team often sees burn-downs like this:

• Team X has been using the burndown chart to motivate the team to put more effort into the sprint beginning (vs. goal-posting delivery and acceptance of last-minute changes).
• One client asked us to include a listing of stories delivered during a given invoice period. e.g.:

project = TX AND status in (Resolved, Done, Delivered, Confirmed, Finished, Rejected) AND updated >= 2015-06-01 AND updated <= 2015-06-30 AND assignee in (membersOf("Team X"))

Conclusion

Yes, Jira can work for lean/agile/kanban design and development teams. We’ve been using Jira configured this way for a couple of years and it is working well for us. Here’s a recap of our tricks:

1. Limit the number of ticket types to the few that the team uses
2. Customize the workflows by ticket type
3. Customize default columns on boards
4. Share handy filters with the team
5. Create a separate board for tracking design tasks

Have you used Jira's agile features? How are they working for your teams? Let us know by leaving a comment or contacting us directly!