How to visualize the status of a sprint in JIRA?

The chosen project model is often critical to the project’s success. That is why we at Druid prefer agile methods and Scrum. Scrum requires all the work of a project to be gathered to a single place so that it can be managed properly. Even though a hip method might just be to scribble notes on pieces of paper and stick them to a wall, we have settled on a more engineerish solution, and use the JIRA project management software. We might lose out on some hipster points, but what we gain are various different project views, comprehensive reporting and other useful features.

On default settings JIRA creates two views for a Scrum project; a backlog view and a view for the active sprint. In addition, the workflow is very simple; just ‘To Do’ → ‘In progress’ → ‘Done’. For many this is enough. Or is it? Let’s find out.

In the ‘Backlog’ view you create stories, give points, assemble a sprint and initiate it. The stories get (technical) subtasks added to them. So far so good. Let’s switch to the view for the active sprint. I undertake one of the stories. I can easily see what subtasks the story has, and the status of those subtasks. One by one, the subtasks are completed until all of them are done. The story is finished!

No, wait a minute… Of course the story has to be put through peer review to ensure the technical quality of the work. And naturally the product owner will want to use a separate testing environment to check that the story’s requirements are met before signing off. Hmm… Should separate subtasks be created for all this? For each story? That sounds like a lot of repetitive work.

The correct solution is to follow the golden rule of software architecture: model the desired structure with the features that the system offers, so that the system will ‘understand’ what you are doing. In this case, the goal is to model the whole process of the stories from the beginning to the end, so the first step is to expand the JIRA project’s workflow to cover all the phases of the sprint.

The necessary phases will vary between projects. Here is one example:

• Sprint Backlog
• In progress – Frontend
• In progress – Backend
• Development Done
• Peer Review & Deployment
• Acceptance testing
• Done

This too is best handled agilely. The first version is drawn up according to your best knowledge, and after that the phases are modified according to the experience gathered. (Pro tip: The project’s workflow should be labeled ‘Simplified Workflow’, so making changes is easier.)

When the workflow is all in order, we should work magic with the views. The view for the active sprint should work as before, so that the development work will run as smoothly as possible. That’s why you’ll only need the first four steps in the view (from ‘Sprint Backlog’ to ‘Development Done’).

In addition to that, a new view is created, called the ‘Review’. The purpose of the Review view is to offer a quick overview of the status of the sprint, and to allow processing the work on a story level, which is required on the final stretch of the sprint pipeline. In addition, we want to group the first four phases (‘Sprint Backlog’ through ‘Development Done’) into a single column titled ‘Develop’, because those phases have to do with the subtasks, and at this point we are interested in the stories themselves.

See a more in-depth installation guide on video:

The end result is that the stories’ workflow has been modelled into JIRA, and now you don’t have to guess or try to remember what phases the stories are on. In addition, it’s easy for everyone, even outside of the project, to check on the sprint’s progress.

Visualization also helps in finding bottlenecks; if, for example, stories keep cropping up in the peer review column, the development process should be modified to lean more towards peer review. There are exceptions, but continued congestion is a sign of a defective process. Luckily the retrospectives that are built in to Scrum can be used to bring the issue to light, and possible fixes can be tested easily. The views will show directly whether the fixes work.

A couple of known issues:

– At the end of a sprint the stories are in ‘Done’ status, but their subtasks are left in ‘Development Done’ status. Before closing the sprint, the subtasks have to be manually moved to the Done column. The move action can be performed on all the subtasks by searching them with the ‘Issue Navigator’ and changing their status with the ‘Bulk edit’ tool. The fix can also be implemented automatically with JIRA’s own script language, but we haven’t gone that far yet.

– In the ‘Review’ view, the ‘Only stories’ filter has to be manually activated. If you find excessive clicking annoying, a quick fix would be to add the view to your browsers bookmarks and to the bookmark toolbar. We developers use Grease Monkey scripts that add the proper links automatically to our browsers.