Index
[Downloads (PDF, HTML & XML formats)]
[Other versions]
Documentation for GreenHopper 6.2.x. Documentation for earlier versions of GreenHopper is [available too].
Many developers are now using Agile methodologies to produce results. Hopefully making use of JIRA and Greenhopper for managing the backlog.
Everybody knows, or should know the project triangle.
What we know about this is that we can only edit two sides if we want our project to go well. 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:
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 the GreenHopper Planning Board. Navigate to this board from anywhere in JIRA by clicking the 'Agile' drop down and selecting Planning 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 like want to drill down into the backlog so important issues are more prominent. You can drill down into this backlog from the GreenHopper Planning Board using Contexts and 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 field for your project, please see Configuring your General Project Settings.
You can set statistical markers on your Planning Board to help you see how much work can be assigned to a particular version, component or assignee. You can read about how to set up and configure your statistical markers here.
A typical scenario where you would use a statistical marker is:
These markers will display as a gray bar across the middle of your backlog.
You can use Components — which are sub-sections of a project — to schedule and categorise your cards (issues). You may already have some of these set up, and you can create a new component from your backlog view by clicking the 'Add' button in the top right of the screen and completing the details on the dialogue.
In agile development — especially if you are using a Scrum methodology — you will often set up a hierarchy of versions , so that one large parent version is made up of several smaller iterations or sprints. Your versions will display in this hierarchy on the right side of the Planning Board. Create a version by clicking 'Add' in the top right of the screen. If you want this version to be a sub-version (sprint or iteration) under a parent version, you can select an existing version to be the parent version.
If you go to your Planning Board you will see all the cards (issues) you have. Go to the "Unscheduled" view. Down the right-hand side of the screen you have the versions; these can be sprints, iterations, milestones or whatever progress/grouping points your team uses.
From the GreenHopper Planning Board you can drag issue cards into the versions, by clicking the left side of the card, holding down, and moving the cursor over a version. When you have the issue over the correct version let go and GreenHopper will change the Fix Version field for the issue you have just dragged.
You can select multiple cards by holding down control and clicking on the cards you want to select. You can also hold down shift to select all the cards between a selected card and the one you click on. Selected cards are highlighted, so you can tell what you currently have selected.
Don't for get 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 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.
For all the nitty gritty details about accessing the GreenHopper charts, see Using the Chart Board.
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 green line is the amount of work remaining. Here it is stated in terms of estimated hours, this is a very confusing unit to use, 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 green line therefore, you should be able to see the progress of the project, when all the remaining tasks are completed the green line will hit the x-axis.
The ...green line.... part is where your current rate of progress will lead you. That is to say it provides a line of best fit from the known point of progress to the completion of the sprint. Hopefully it hits the x-axis otherwise your going to want to consider removing from the task list for this iteration.
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 relie on for meeting your completion date.
The yellow line is the cumulative effect of going fast or slower than the red line. This is a bi-product of estimating what can be done in an hour, you will either have been over estimating what is possible in an hour or under estimating and this is reflected by this line.
The blue line shows the velocity, that is to say how many velocity points the team is consuming on the average day. 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 orange line is the velocity required to meet the end date objective. This 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 wont give a proportion increase the the velocity points, thats 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.