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.
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 GreenHopper to manage this long list of tasks by ranking, prioritising, and scheduling the work.
In this guide, we are viewing issues on a GreenHopper board. Navigate to this board from anywhere in JIRA by clicking the 'Agile' drop down and selecting your preferred board.
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.
GreenHopper 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 GreenHopper board using your board's Filter (and, optionally, Quick Filters).
GreenHopper 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.
You can use the sprint marker in Plan mode 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.
Screenshot: a Scrum board in 'Plan' mode (click to enlarge) In Plan mode you can: An issue will only be visible in Plan mode if:
Right-click selected issues (in GreenHopper 6.1.2 and later) to add them to a sprint, send them to the top/bottom of the backlog, view them in the JIRA Issue Navigator or perform Bulk Operations.
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 GreenHopper JIRA Configuration.
In Plan mode you can:
An issue will only be visible in Plan mode if:
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.
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.
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:
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.
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. GreenHopper helps this with by providing a chart.
Screenshot: Burndown Chart (click to enlarge) Click Non Working Days (in version 6.1.1 or later) to highlight days when your team won't be working.
Click Non Working Days (in version 6.1.1 or later) 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.
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 GreenHopper, so no bugs filed for that please.
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:
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.