How to Manage Iterative Projects using JIRA

Shalane Williams, 27 November 2017

Project delivery using an iterative approach appears to have become the norm over the last couple of years. Using a waterfall methodology, though effective, can be a long process & if your organisation is rapidly changing, you could find that the requirements defined in the beginning is no longer relevant. I had one customer comment that during a waterfall project by the time the solution is delivered, they’ve forgotten what they wanted in the first place!

JIRA is a common tool used to run an agile/iterative project after experiencing it with one of our other customers. I found it a great tool to have line of sight of what needs to be done, in progress, completed, etc. No messy spreadsheets here!

However, if you’re not accustomed to using JIRA it can prove to be ineffective. While managing delivery of a project, I noted that I couldn’t see how we were tracking, user stories were incomplete, statuses hadn’t been defined, etc. The reason I realised was because JIRA hadn’t been configured for any of this. Therefore, I tasked myself with learning how to configure it with the absolute minimum to ensure we were using it efficiently and get back on track.

Below is JIRA Lite – the starting point for running a project iteratively:

Customising a Project

Recommendations

1. Configure estimation and tracking to hours.
2. User stories should be robust with clear acceptance criteria.
3. Add a couple of new statuses; “in UAT” and “in PROD” – Done could mean anything, i.e. work has been completed but not deployed. Unless we all have a consensus of what “Done” means.

It All starts with a User Story…

The key components of a user story should answer the following 3 questions:

1. Who?
2. What?
3. Why?

Who: “As an xyz user”.

What: “I want to do this, that and the other”.

Why: “So that I”.

There also needs to be clear acceptance criteria. Acceptance criteria is not only used to test but will give the developers a clear framework to work within.

Here’s a simple example:

As a user in the contact centre, I want to start typing an address and as I type, the system should then suggest addresses based on what’s typed and allow me to select one from a list. This is so that I can reduce my data entry time.

Acceptance criteria for the above user story:

1. A field to start typing the address.
2. When the first 3 characters are typed in, start giving suggestions in the format of <26 Greenpark Road, Suburb, City, Post code>.
3. When selected, automatically fill: suburb, city, post code fields.
4. Suburb, city, post code fields are read only.
5. If there are no suggestions available, display “…” and make suburb, city and post fields editable.

Estimating and Tracking Time

All stories should have estimates to completed, i.e. 24 hours. This will allow the project team to predict how long it’ll take to deliver specific sprints. As you work on the issues during the sprint, you may need to adjust the Remaining Estimates as necessary.

However, in order for the time tracker to work, you need to configure the Issue Screen by adding time tracking as a field:

1. JIRA administration.
2. Issues.
3. Issue type screen schemes.
4. <Project Name> Scrum Issue Type Screen Scheme.
5. Select the Default Issue Screen.
6. Add the time tracking field.

The issue screen will now include 2 new fields:

This will feed into a time tracker on the story, e.g.:

Having the above in place will immediately give you a framework within which to run your iterations and see how you’re tracking!