Scrum With JIRA

JIRA is one of the leading (if not the leading) issue management systems on the market with more than 18,000 customers at the time of writing. JIRA is positioned as a general-purpose issue-management system, but the vast majority of organizations use it as a bug-tracking system. A software bug is one example of a JIRA issue-type, and to manage bugs, basic workflows (state-transition sequences) and user-roles can be set up to match the needs of your team. Within JIRA, other types of issues can also be created, like Tasks (for project management), and, yes, User Stories, for scrum or iteration management. There is also a plug-in available, Greenhopper, which can be used to create sprints and burndown charts, but that is not a prerequisite to doing scrum with JIRA, and we will not be discussing it at any length.

As we will see, JIRA imposes some restrictions on the number of layers available for display in an issue hierarchy that make it far from an ideal solution for scrum. What we really want to be able to do is capture Epics > User Stories > Sub-Tasks, and see the issues laid out like that in any report, with sub-tasks nested within their parent user stories, and user stories nested within their epics.

Let me back up a little and talk about Epics vs. Stories. In any significant project you are going to start with high-level, customer-facing requirements or features. These are the capabilities provided by the system to address end-user needs, and would be the major line-items that you might see on the product data sheet. In scrum these would be referred to as Epics. As part of release planning, epics are broken down into User Stories, which are the discrete items of functionality that make up each epic, and there will typically be a one-to-many relationship between epics and stories. Thus, it is really important for any tool to be able to show both levels of detail and their relationships in a structured way otherwise it will not be possible to see the forest from the trees. Once the epics have been decomposed into user stories, the next step in the sprint planning process is to break each story down into tasks that describe the actual work to be done to implement the story. Something like this:

Figure 1. Basic Issue-Type Hierarchy for Scrum
  • Epic_1234: User Administration
    • User_Story_0100: Users can self-register
      • Task_8001: Create new page with registration form
      • Task_8002: Create user class to support all required data
      • Task_8003: Create methods to collect user data and insert into database
      • Task_8004: Create database schema to support user details

The problem with JIRA is that it is not possible to set up a 3-level hierarchy this way. You are restricted to a 2-layer hierarchy (issue and sub-issue). However, there is a way around it, and that is by using relationship links. You can create epics and then link them to user stories, via a “is comprised of” type of link. This is far from ideal, and not as visually useful (even with Greenhopper) as what is available in other tools that have been designed specifically for scrum. However, the advantages of being able to track sprints, bugs, and many other project artifacts in a single tool may, for some, outweigh these inconveniences.Finally, sprints can be setup as “versions”, as the vehicle to plan and track everything.

User Story Workflow. If you already have a workflow defined for bug tracking that looks something like: Created > Assigned > Resolved > Closed, then keep it. Use as follows:

  • Created: created
  • Assigned: Assigned to an individual responsible for overall story
  • Resolved: Development team are ‘Done’ with the story, its ready for QA
  • Closed: QA have successfully validated the story

To summarize, 3 issue-types are needed:

  • Epics: customer-facing product requirements (a typical release will have 20-50 of these in total). Epics are linked to User Stories via an “Is Comprised Of” relationship. Epics may span multiple sprints.
  • User Stories: Must be linked to a ‘parent’ epic. User Stories must be completed in a single sprint
  • Sub-Tasks: Use to define work/effort related to a single story

Sprint Tracking. JIRA comes with a set of built-in ‘gadgets’ that allow you to create dashboards for your project or sprint. Even without the Greenhopper plugin, you can still create a dashboard that provides good visibility of sprint progress. I would create a dashboard and add the following 4 gadgets: This will give you a status summary of all issue-types, and a set of ‘burn-up’ charts tracking stories, sub-tasks and bugs.

  • 2-dimensional filter gadget. (Issue Type vs. Status)
  • Created vs, Resolved Chart (User Stories)
  • Created vs. Resolved Chart (Sub-Tasks)
  • Created vs. Resolved Chart (Bugs)
Figure 2. JIRA Dashboard for Scrum Tracking

 


 

Print Friendly

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>