Improving our agile process leveraging Jira boards and flows

Struggling to fit design work into your agile process, using Jira? Lacking visibility of status for stories (especially after implementation is done and before they’re rolled)? This note might be for you.

TL;DR

By adjusting our Jira flows to better suit our workflows, we gained higher visibility and better tracking of our development process.

What we used to do and why we needed to refine our process?

Until a while back, we were using our Jira board to help us manage our agile process (Scrum in our case).

We were using the classic 3-columns board: “Todo”, “In progress” and “Done”. Simple.

Since then, the team has grown — another developer has joined, as well as another designer, and we started experiencing some issues that suggested some improvements were needed:

1. Lack of visibility on the status of tasks that are completed but not yet live
   As some stories were being completed toward the end of a sprint, but were not yet rolled out, we saw that many stories had finished the actual development work, but weren’t yet live. So in the following sprint, we were risking missing to pick those up, since there was nothing left to do with them. The result was us trying our best to remember which features and experiments needed to be started.
2. Storing and refining ideas
   On one hand, we didn’t want our backlog to start getting too packed and messy, so we tried to avoid creating stories that are half baked (e.g. abstract concepts about a new partner feature). On the other hand, when a new idea that is not relevant to the epics that we’re currently working on, nor to the roadmap, would pop into our minds, we didn’t have a specific place to store it — which led us to create several docs for capturing those ideas. Creating all those docs here and there, simply doesn’t scale.
3. Merging design into the development workflow
   Since we have stories (most of them) that need design work before the technical implementation can take place, we needed a streamlined way to document the flow of a story between the two stages (design-dev), with its status at all points in time.
4. The way we initially did it was to add a prefix to a ticket name (e.g. “D_user form”), meaning that the ticket would go through the “todo-inProgress-done” flow for the design process. Then, when the design is ready, we would take the ticket back to the backlog and just remove the “D” so we would know that we don’t need any more design work for this ticket. But this is a “hack” and not a real solution to the issue. (In addition, it changes the title, scope and “nature” of a Jira story/ticket throughout its lifetime, which can get a little messy.)

Adjusting the tools and process to our workflow

After a few iterations and learnings, we have now reshaped our Jira and workflow in a way that supports our needs better:

1. Increase visibility for “Done” tickets
   As pointed out above, we used to use the “traditional” 3-column board. In order to increase the visibility of the state of each ticket in its final stages (when the development work is done), we broke down the “done” into 3 columns (statuses) that reflected better the actual process we’re following in the team: 1)“QA/Code review”: this is quite clear, as this is the stage of the QA process. 2) “Ready for rollout”: after the QA process is over and the code has been merged to trunk. 3) “Live”: meaning the experiment is running or the feature is active on production.
   By breaking down the “done” status into more specific statuses, we increased the clarity and reduced the chances of a ticket being forgotten.
2. Refinement board and idea-box status
   We created a new flow for a ticket: Every ticket is being created as an “Idea”. Ideas are not shown in the backlog but only on the brand new “Refinement” board. The refinement board is the board that we’re using during our refinement sessions and it has only two columns: “Ideas” and “Ready for Refinement”. The point is that the “ideas” are all in one column where we can store all our ideas and stories without worrying too much about the order or the content of the tickets.
   Before the refinement session, every team member can nominate ideas for refinement by adding the missing details and moving them to teh “Ready for Refinement” column. Then, during the refinement process, we’re reviewing only the “Ready for Refinement” column. If a ticket is well defined, we’re moving it to our backlog. If not, we move it back to the “Ideas” column until we have enough information.
3. Better reflecting the design process within a sprint
   The last step we did, and we’re still refining it these days, is merging the design process into the whole dev process. Instead of recycling a ticket after the design work is done, we now have a dedicated board where a ticket can move throughout the design process before moving forward to the dev board.

Main learnings

• One step at a time
  We introduced these steps one at a time, instead of all at once, which would have made it quite overwhelming and made it look like lots of overhead.
• Your tools should support your workflow (not the other way around)
  Although the agile process should be kept simple and, well, as agile as possible, there is much room for adjusting it to the way that your team is working. Make sure that you’re adjusting your management tools as well.