Skip to end of metadata
Go to start of metadata

Where to begin?

Many developers are now using Agile methodologies to produce results. Hopefully making use of JIRA and JIRA Agile for managing the backlog.

Agile is an approach to managing competing project priorities of time, cost and scope. One way to visualize the interplay of these priorities is the well-known project triangle.


In general, we can only adjust two of these scales (sides of the triangle) if we want the project to be successful. In an ideal world we would have control of all three, but generally project resource is finite and the time scales are fixed iteration dates.

On this page:


Planning work

What is a backlog?

For the purpose of this article, a backlog is the list of tasks which are yet to be allocated for completion. Any large project will end up with lots of things people want; as a team you can use JIRA Agile to manage this long list of tasks by ranking, prioritising, and scheduling the work.

In this guide, we are viewing issues on a JIRA Agile board. Navigate to this board from anywhere in JIRA by clicking the Agile drop down and selecting your preferred board.

My backlog has thousands of issues — can JIRA Agile help?

Yes, but you need to be realistic about what your team can achieve. Backlogs are all about priorities: do the most important things first. The idea of a backlog is to have a large pool from which to draw issues and plan work in advance only over the short term — don't schedule all your thousands of issues out and plan work for the next several years! You'll be setting yourself up for failure. Instead, plan only a few versions in advance, over several weeks or a few months at the most. Your backlog will still be waiting for you when you finish the short term work.

Organising with Filters

JIRA Agile will help you by allowing you to filter options. So for instance you can filter out all the issues in your backlog which are not high priority. You may also want to filter on things such as cards with a high business value.

Filters can only search on the data you have. If you don't make good use of the priority fields or add things in, like business value, you can't pull them out with a filter or a search.

Managing backlogs is also a good data entry point as well as at the planning stage. Ensure you ask the right questions of the users who create issues, so you can quickly find the important issue and make sure you flag up the issues which are most important. Linking duplicate and similar issues as you find them will also help, as you can check when closing issue if you have resolved other issues in your back log.

You will most likely want to drill down into the backlog so important issues are more prominent. You can drill down into this backlog from the JIRA Agile board using your board's Filter (and, optionally, Quick Filters).

  1. Your board is based on a JIRA issue filter. This filter can include issues from multiple JIRA projects.
  2. At the top of the board in large text is the name of your board; below this are a number of links allow you to select a Quick Filter (you may see 'Only My Issues' or 'Recently Updated' there). Quick Filters are useful to change the issues you see -- you can use a Quick Filter to only show issues of a certain priority, reported by a certain user, or other specifications.
  3. Select Tools > Configure from the drop down.
  4. Click the Quick Filters tab.
  5. A Dialog will appear, which allows you to type in a name and JQL query for your new Quick Filter.
  6. Pick some specifications, and click Add. Then click Use board.
  7. Your board will now show a sub-set of your backlog based on the Quick Filter you have set.

Organising by Ranking

JIRA Agile allows you to set up rankings for your issues to help you organise tasks in your product/sprint backlog more effectively. Rankings allow you to prioritise issues at a more granular level than issue priorities in JIRA, as rankings are a dynamic number — meaning, there is a number 1 issue, a number 2 issue....a number 335 issue, and so on to the end of your backlog. This is helpful for both short and long term planning, and brings important issues to the top of your backlog.

Once you have ranking set up, just grab a card (click on the left of the issue and hold down) and drag it up or down so it is above or below the other issues you see. The 'rank' number will update automatically.

For information on how to set up a ranking for your board, please see Enabling Ranking.

Organising using Sprints

You can use the sprint marker in the Backlog to help you see how much work can be assigned to a particular sprint. You can estimate your work in Story Points, hours, or any other numeric field of your choice — see Configuring Estimation and Tracking.

You will typically want to assign issues from your backlog to a sprint based on issue ranking and your team's velocity (work capacity per sprint).

The sprint marker will display as a blue bar across the middle of your backlog.

In the Backlog of the board you can:

  • Prioritise the backlog (shown under sprints on the board) — Create issues for your backlog, rank and estimate them, and drag-and-drop to add them to a sprint.
    (info) Right-click selected issues to add them to a sprint, send them to the top/bottom of the backlog, export them to Excel, view them in the JIRA Issue Navigator, or perform  Bulk Operations.
  • Estimate Stories — You can use the 'J' and 'K' keys to move through issues in the backlog and get details on the right-hand side of the screen. Plug in your estimates or story points as you go. 
    (info) Note that, by default, the Story Points field is only available to issues of type 'Story' or 'Epic' — you can change this as described in JIRA Agile - JIRA Configuration.
  • Create Sub-Tasks — To break a story (issue) down into implementable chunks, go to the sub-task section (click the sub-tasks icon within the story that you'd like to have a sub-task) to view and create sub-tasks.
  • Create new Issues — Use inline issue create to quickly add issues to your backlog. Note that this functionality only works if you only filter your Scrum board for one project.
  • Organise via Epics — Group related stories into an epic. Click EPICS to view the Epics panel, where you can create epics, drag-and-drop issues into epics, and filter by epics.
  • Identify the workload for specialists — The avatars for users (specialists) who have work assigned to them in a sprint are shown at the top of a sprint. Click  to view the sprint workload for assignees.
  • Plan Versions — Assign issues to upcoming versions. Click VERSIONS to view the Versions panel, where you can create and edit versions, assign issues to versions via drag-and-drop, and filter by versions.
  • Plan, and Plan Again — When you're happy with the stories for the iteration, start a sprint and the stories will move into the Active sprints. While a sprint is active in the Active sprints, you can still plan subsequent iterations in the Backlog (click Add Sprint), but you won't be able to start them until the active iteration is completed. (You can, however, drag and drop an issue in the Backlog onto the active sprint.) Note that you can only start (or complete) a sprint if you have 'Administer Projects' permission for all projects that match the board's filter.

An issue will only be visible in the Backlog if:

  • the issue is not a Sub-Task,
  • the issue matches the board's Saved Filter (see Configuring Filters),
  • the issue's status maps to one of the board's columns (but not the 'Done' column), and
  • there is at least a status being mapped to the right most column. Eg. If you have the columns To Do, In Progress and Done, ensure that you have a status mapped to In Progress at least. If you map all the statuses to the first column (To Do), you will not be able to see any issues in the Backlog.

Don't forget that by pressing "?" you can get a list of keyboard shortcuts. A little time invested here will save you hours of effort.

So how do Kanban teams use versions?

The concept of allocating cards to planned sprints or versions is Scrum-specific. Kanban teams use an entirely different methodology: they triage the cards in their backlog and then action them according to priority. As soon as there are enough completed tasks to constitute significant value, a version is created and released.

Estimating work

How long will a job take?

Even the best engineers have great difficulty predicting the future. There are a huge number of variables involved in predicting how long a job will take; some of the big ones are:

  • Who will do the task?
  • How difficult will it be to achieve sign-off on the task?
  • Is the code base buggy?

With all these unknown elements, how can you possibly predict how long a project will take? Even ball-park estimates are risky on a project of any real size.

What the charts should provide a good team lead

The charts allow you to learn from your previous encounters. Rather than comparing apples with pears, or Bob's estimate for how long Bill will take to complete a task, we can use the estimates from our completed tasks to guess the likelihood of our remaining estimates being correct.

From the charts you can ascertain a teams' "velocity" — that is, the speed at which the team is able to complete the tasks estimated in units of difficulty (hours/complexity/score out of 10). Once you know a team's velocity you can then calculate, based on the current team performance, how long the remaining tasks should take to complete. JIRA Agile helps this with by providing a chart.

Understanding the functionality of the JIRA Agile Charts

For all the nitty gritty details about accessing the JIRA Agile charts, see Using Reports.

Charts in action and how to explain them to your client

Screenshot: Burndown Chart (click to enlarge)

(tick) Click Non Working Days to highlight days when your team won't be working.

This graph looks fairly cool and might impress someone on a first glance, but you do need to be able to explain it or what's the point?

The grey line is the amount of work remaining. Note that it can be quite confusing if you are using hours as your Estimation Statistic, as most people would expect 1 hour to map to 1 hour of development time, right? Wrong, its an estimate of an hours work, so this could be 20 minutes or 20 days in development time. Best to think of these units in terms of velocity points and use the velocity calculation to estimate the time they take. Across the bottom is calendar time. If you read the grey line therefore, you should be able to see the progress of the project, when all the remaining tasks are completed the grey line will hit the x-axis.

The red line is following the estimates which are in approximate time unit values (hours) where the project will come in, this is where you want to be and not a line to rely on for meeting your completion date.


Screenshot: Velocity Chart (click to enlarge)


The velocity can be estimated as the average, over several recent sprints, of the sum of the estimates for the amount of work completed by a team per sprint — so in the chart above, the velocity = (37 + 47 + 50 +57) / 4 = 48. A team's recent velocity can be useful in helping to predict how much work can be completed by the team in a future sprint.


This is where it gets pretty cool, you can actually build some real credibility for your estimates if the levels out as it shows if your team is consistently producing the same results.

The velocity chart will show you on a daily basis if the project is slipping or not. You can consider changing your resource if you need to alter this but don't forget that adding more people to a project won't give a proportional increase in the velocity points, that's a bug in people not JIRA Agile, so no bugs filed for that please.

Assumptions and managing expectations

The charts you have are still only going to give you projections. You should use them to illustrate your point and show reasoning, not to set unrealistic expectations. You also need to communicate that your projections are based on assumptions such as:

  • The team will maintain the same engineers.
  • Estimates were made by the same people hopefully the same team thats working on the project.
  • You are not flogging your team to death — your development is running at a steady pace 7-8 hours development per developer per day.
  • You are completing jobs fully. For instance you are building up documentation and testing as you go along, not building up a mass of hidden, incomplete tasks.
  • Team motivation remains constant, hopefully with good morale.
  • The error in your estimates is constant.

Of course you may have made other assumptions as well, and these should also be factored in when setting expectations.


Estimating is still important, and the following link may help with that part of the process:

A good Agile coach is also recommended.


  1. I don't think the grey and red lines mean what you think they mean.  Also, how does Agile know how much capacity is available for a sprint or does it just assume that whatever I put in at the beginning is the capacity (i.e. the sprint starts with 40 hours allocated, Agile assumes there are 40 hours available).

  2. I think Shane has a valid point. The red line and grey guideline definitions are either wrong or a bit unclear, and need to be re-worked for grammar and clarity. Thanks.

  3. I am trying to see how much work is assigned per user to a sprint. How can I make the plan view show the amount of time left on an issue instead of the original estimate? This would be handy when some of the issues have been worked on and the time left is quite different than the original estimate. (I would also like to change this for me, and I don't have administrator access.)

  4. @OldGrouch - I would be very much interested in that too!

    It's a bit confusing to see 'original' estimates instead of real ones when planning next sprint. Perhaps there is some option to change displayed value to 'real' remaining estimate?

  5. When our team has already estimated hours for each issue in an upcoming sprint, how do we view the burndown of estimated hours, similar to the way the reports currently display story points?

  6. In Sprint Planning we need to see this by Person.

    Scenario: On sprint planning day, we update the hours available for each person for the project. Next we troll/discuss through Feature/Scenarios (story points) in priority order, firm up story points and then decomposed into tasks, with owners who create hours estimates on the fly.  (Feature/Story = Story Points; Task = hours)

    We're accustom to seeing a real time update in sprint planning.  We're accustom to TFS/Visual Studio online. 

    As a team member enters their task & estimates we watch our available hours for the sprint get allotted by person.  When we get to full, we swarm to load balance where we can and then set expectation/commitment.  We THEN kick off our sprint commitment. We don't over commit. 

    Where oh where can I find this in Jira?

  7. When estimating hours for a task we found that it was necessary to split each task into areas (dev,test,design). Not sure how others are doing this but we ended up creating an add-on to put different roles into the one task.

    Seemed like an obvious change but maybe we don't quite do it right. (smile)