Using Jira for an Agile project

We have been using Agile development methodologies at Black Pepper for a while now and have used Mingle in the past as an online tool for managing stories and iterations.

However, we recently decided on Jira as our feature/bug tracking tool of choice and thought it would be interesting to see if we could use Jira to manage our agile projects rather than have more than one tool.

One of the cornerstones of an Agile project is tracking your velocity. This is essentially a measure of how much work you are doing over a period of time. Agile projects are run in iterations, these might be a week, 2 weeks or perhaps a month. The length of the iteration would depend on the project, but 2 week iterations are a good start. Each iteration has a collection of "stories" assigned to it. A story is basically a single feature that has been defined through your analysis of the project before the first iteration. Note that as this is an Agile project, you don't have to analyse the project completely up front and have everything mapped out. You just need enough to get you on your way, you will be creating and estimating more stories as you go.

Stories in Jira

The list of stories is where Jira first comes into the picture for us. In any version of Jira you can define a custom issue type. We have an issue type called "Story", surprise surprise. When you are analysing requirements and creating user stories, you can create new "Story" issue types in Jira, but you don't have to estimate them straight away and certainly don't need to assign them to an iteration yet.

This story has been estimated and the date when it was estimated has also been recorded. These are both custom fields, Story Points is a Numeric field and the Estimation Date is a Date Picker field. Jira lets you add these custom fields just to a particular issue type, in our case "Story".

The reason to add the Estimation Date field is because some of the reports we want to generate want to know when new stories came into play. You could do this based on the creation date of the issue, but it may well be that you only want to start counting a story as being available once it is estimated and this allows you to record some data about the story before estimating it.

The Story Points field is a numeric value rather than the often used t-shirt sizes (Small, Medium or Large) as we need a numeric value to do calculations based on the size of the story and wouldn't like to guess at numeric values that match S/M/L as they will vary on a per project basis. In our case we might use Small=3, Medium=5 and Large=8.

Story workflow

Stories should move through a certain workflow to model the possible states they can be in. If you are lucky enough to be able to afford the full Enterprise Jira then I'm sure this could easily be done with a custom workflow, but actually the default workflow works quite well if you map it like this:

Story stateJira state to model story state
New story ready for estimationOpen story type issue without a value in the story points field
Story ready for schedulingOpen story with a value in the story points field and optionally an estimation date
Story ready for developmentOpen story that has a fix for version
Story in developmentIn progress story that has been assigned to a developer
Story ready for testingStory marked as resolved by the developer
Story tested and completeStory marked as closed by a tester

Note that you can make custom filters to find all the stories that fit into these different states.

Iterations in Jira

It is fairly easy to model iterations in Jira by just using Jira's built in versions system.

In an example setup we have 6 iterations, each with a release date. Two iterations have already been released and iteration 3 is due on Friday 24th October.

Once you are ready to start planning your iterations, you just need to assign the stories you've created to iterations. We use the "Fix for version" field in Jira for this.

We have four iterations planned ahead of us, iteration 3 has one story already completed and three to go.

Note that iterations 5 and 6 have no stories planned yet.

Agile reporting

Jon Pither created a Jira plugin that generates charts based on your story points and iterations called the Agile Velocity Tracking Plugin. It's a good start, but unfortunately Jon has since moved onto other things, so I've taken up where his good work left off and made a few tweaks myself.

Worth pointing out there are a few other options for Agile reporting in Jira and someone has handily recently analysed these options in this blog entry.

You get to choose a few options when setting up the report, but usually the defaults are pretty sensible.

At the top of the report you get a handy summary of the iterations that have completed so far and how your stories/points are getting created and completed. It includes a best guess at when you've going to finish based on the stories that have been estimated so far and your current velocity.

The charts below the summary show the following:

  • Stories/points created during iterations
  • Stories/points completed during iterations = Velocity
  • Stories/points burndown over iterations
  • Stories/points burndown forecast


I've very briefly covered how you might use the excellent bug tracking tool Jira for keeping track of an Agile project. Some might ask why use this over the traditional card wall that is often used in Agile projects. Card walls are the simple and low tech solution, but they are not available over the web, they are not searchable, filterable, commentable or reportable without manual work from someone.

Integrating our Agile workflow into Jira also allows integration with our continuous integration setup and our source code repository so it is easy to track changes and releases and match them to stories all automatically (this is a blog entry for another day).

This site uses cookies. Continue to use the site as normal if you are happy with this, or read more about cookies and how to manage them.