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:
The key components of a user story should answer the following 3 questions:
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:
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:
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!