During my tenure at Amazon, the teams I was leading used to follow a very effective scrum process. It was made possible by an internal tool called SIM, which was integrated with various other internal tools, enabling a seamless project management experience.

When I joined Lambda School, one of my main tasks was to set up an effective project management process for my teams. We decided to go with scrum and I started figuring out a good way to set up JIRA similar to how I had been using SIM at Amazon to reap the benefits of my learnings.

I started with a light-weight implementation of the scrum process to avoid a steep learning curve for the team. In this article, I will describe how my teams are using JIRA to conduct a light-weight scrum process which some of you may find useful. It is possible to manage projects in JIRA differently than what I have outlined here, including the official JIRA scrum guide, but the process described here has worked well for our teams so far.

Issues in JIRA should be organized in a way that makes it easier for us to manage our incoming requests and eventually run scrum meetings smoothly. We used to have a single backlog for all of the Engineering teams containing 100s of tasks. Such a huge backlog is difficult to manage, so we divided our backlog into different focus areas (or teams) and each focus area was made responsible for managing their backlog.

One of the simplest representations of a team in JIRA is a JIRA Project. We used the Classic Scrum project with the “Scrum” template since we found it to be better in terms of organization than a NextGen project (e.g. Classic projects display all Epics in a left pane, making it easier to glance through their backlog in the right pane).

Within each project, different internal initiatives or projects were represented as Epics. We created 2 Epics for special purposes, viz., New Requests and Ad Hoc, and as many other Epics as we needed for other well-defined projects. Here is a brief description of these Epics:

New Requests: This Epic served as the bucket for all new business requests filed by anyone across the company. These requests are groomed weekly and transferred to either the Ad Hoc Epic or one of the other project-related Epics.

Project-related Epics: For each well-defined project with a known deliverable, we created an Epic. Each project Epic tracked all the milestones and tasks for that project. Stories from these Epics are kept in a prioritized order in the backlog and the top ones are moved to the upcoming sprint weekly.

Ad Hoc: This Epic contains all the orphan Stories which do not belong to any well-defined project Epic. This Epic is also meant for housing any high-priority ad-hoc requests that come in while a sprint is in progress. There is a good chance of this Epic becoming a dumping ground for the majority of our Stories, hence, we are quite disciplined in ensuring that we are adding only those Stories to this Epic which do not reasonably belong to one of the other projects (or are not bugs, in which case they will be prioritized through our oncall process).

It is usually futile to create an Epic for a project where the end is not in sight. These Epics lurk around in your JIRA Epic view forever without getting done. It is best to divide long-running projects into smaller manageable launches and create Epics for them to ensure that Epics are being closed. E.g. a project involving the launch of a new data model can be divided into (1) creating the new data model, and (2) migrating X service to use the new data model, and so on.

Apart from a JIRA project to manage Sprints for teams, each team also has a JIRA project (with Bug tracking template) to house bugs and issues that need to be handled by the oncall. We call this project “Oncall”. This project is not part of the scrum process and does not have a Scrum or Kanban board. Any issue (bug) that needs immediate attention is filed as a bug in the Oncall project.

Our Oncall project is a classic project in JIRA with a “Bug tracking” template. The Oncall project has no board. It just has a list of bugs in the order of priority.

For the scrum process to be successful, it has to be accompanied by the right set of meetings to enforce discipline. All of my teams have a 1 week-long sprint because our priorities change very frequently and we need to move faster.

All of our scrum related meetings are scheduled between the time window of 9 am to 2 pm PST / PDT since this is the only overlapping time window across various office locations in the US. We keep 2 stand-ups, 1 backlog grooming, and 1 sprint planning meeting (with sprint retrospective) per week. Here is how the meetings are scheduled on one of my teams:

Tuesday 9 am — 9:15 am — Stand-up
Thursday 9 am — 9:15 am — Stand-up
Thursday 1 pm — 2 pm — Backlog grooming
Friday 11 am — 12 pm — Sprint planning with a sprint retrospective

Here are the details of what we cover in each of these meetings.

All team members, including the PM

1. Slack based daily update of sprint tasks.
2. Each member takes < 2mins to talk about their assigned tasks, calls out blockers, and asks for help.
3. Call out risks to timelines.

1. Product Manager
2. Engineering Manager
3. Few Tech Leads (optional)

1. Go through the incoming requests in the ‘New Requests’ Epic. Transfer tasks from this Epic to either another project Epic (including the Ad Hoc Epic), in the right position based upon its priority, or to the “Oncall” Project.

2. Ensure that the individual project Epics’ tasks are correctly ranked.

3. Note down any other high priority tasks that need to go into the next sprint.

1. Product Manager (optional)
2. Engineering Manager
3. Engineers

1. List down every team member and their bandwidth for the next sprint, in the number of days (e.g. available for 7 out of 8 days).

2. Assign 0 points to the oncall, since they will only work on bugs, which will not be assigned any points.

3. Create the next week’s sprint.

4. Closeout the previous sprint by moving incomplete tasks from the previous sprint to the next sprint and marking the remaining tasks as done.

5. Move tasks to the sprint, assigning the right tasks to the right engineer (reasonably) based upon their bandwidth, current project, and any other factors.

6. Finally, decide what deliverables from the recently concluded sprint are candidates for the sprint demo session.

Please note that since we follow a light-weight scrum process, we do not keep track of sprint velocity or estimate tasks using planning poker. We will introduce these aspects of scrum if we feel the need for them in the future.

All participants of the ‘Sprint Planning’ meeting.

1. Use a retrospective tool (we use https://www.retrospect.team/), to conduct sprint retrospective.

2. Write down “what went well”, “what can be improved”, and “action items”.

3. Have a healthy discussion on what was entered in the tool.

I was able to figure out how to use JIRA to conduct scrum the same way I used to conduct scrum using Amazon’s internal tools. However, given the size and stage of my current company, I did not enforce a heavy-handed scrum process on the team. We have started light and will continue to tweak our process as we move along.