Welcome back to the dissection lab! This week we’ll be taking a look at issue and project management, primarily with the tool JIRA, developed by Atlassian.
Issue Tracking and Project Management
When developing software you need a clearly defined workflow. Who is working on what feature, how much technical debt do you have and what business needs are of highest priority. To allow maximum collaboration it is best to try and centralise information, at best a single resource that the entire team uses to keep track of the state of the project. In particular the team I am part of uses JIRA, it allows us to visibly see the amount of work that a project requires and how all of our different roles come together to achieve our goal.
Atlassian’s JIRA has been around since 2002 and allows an entire team to work from a single source. Each team member has a profile and they can create work issues or be assigned jobs to do. There is a lot of transparency and traceability by using tools like this. On the main JIRA dashboard you have an overview of the JIRA instance, i.e. assigned issues; and an activity feed which displays the latest changes that people have been making. Real time reporting is fantastic.
Say that a company wants to design a new piece of software, using JIRA they’d create a new project. When a project is created it is assigned an issue tag. This tag is a series of letters which is then assigned to every issue within that project. It allows different issues to be easily referenced across the platform. For instance a project called ‘Demo Test’ may have an issue tag of DT, an issue within that project will be assigned the issue key DT-1, another one DT-2 and so on. If two issues are related to each other you could created dependency links between their issue-keys or you could easily reference an issue on a different ticket. In order to manage projects they are broken down into a number of components, starting with epics.
An epic is a particular objective with such a level of complexity that it will require many tasks to be completed across a substantial amount of time. A general example of this could to automate testing or to develop a web portal. Long, strenuous tasks. To make managing these easier they’re broken down into User Stories.
Each story has a description which will state a number of scenarios which the story must fulfil, an acceptance criteria list which dictates everything that must be completed and verified for the story to be considered done and a general summary of the problem in a format like: ‘As a business owner I want to add the ability to take credit cards payments to the website, so that the customer has an alternate method of payment’. This easily says who, what and why. Normally a slightly more in-depth description will follow, here is an example of a user story I have worked on:
This particular story is part of an ‘automation’ epic and is assigned to the current sprint. Alongside this description a priority is assigned to the story and a reporter, in this case the reporter is my boss.
As a project will end up with potentially hundreds of user stories, sprints are used to bunch up stories into sorties of work. A typical sprint will last 2 or 4 weeks and as a team we decide which stories should be part in the upcoming sprint. The stories to choose from are inside a backlog like so:
We size up stories into who will be required and the amount of time needed. This way we try and keep a constant pace from sprint to sprint and distribute work fairly. On each story we can actually assign it a length of time which makes it easier to refine stories down and get the fit right for a sprint.
To break stories down into manageable chunk we use sub-tasks.
In a similar vein each sub-task has a description which explains what the task is, why it is necessary and how to complete it. Every time progress is made on the task it is updated so that other team members can go straight to JIRA to check the progress.
From all the added organisation it becomes very easy to gleam statistics about a team from the number of user stories they take on during a sprint and the number that are completed. This can indicate if a team is committing to too much or not taking on enough. JIRA comes packed with tools which can analyse sprints and produce: burn-down charts (the amount of work in a sprint), velocity charts (the amount of value in a sprint), cumulative flow diagrams (exact issue statuses across a time range) and sprint reports (issue list). These are great in after sprint retrospectives where teams can discuss what worked well and what didn’t. This all complements the AGILE way of working, to try things out and continually improve.
JIRA goes even deeper than this but for now I hope this is enough to dig your teeth into. The best way of becoming familiar with this is to just head over to Atlassian (https://www.atlassian.com/), grab a free trial of JIRA (cloud for a quick play, server to tool around setting it up yourself) and mess around.
Thanks for reading and please join me next time for some Continuous Integ