Planning and Estimating work for an Agile team

Where to begin?

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.

ProjectTriangle

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.

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 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.

My backlog has thousands of issues, can GreenHopper help here?

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.

Organise with Contexts

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.

You can use or create filters from JIRA as well. Note that issues from other JIRA projects will not appear on your GreenHopper Planning Board, as the GreenHopper board will only show issues from a single JIRA Project at one time.
At the top of the Planning Board page in large text is the name of your project, to the right of this is a dropdown which allows you to specify a context (you may see Default or On The Fly there). Contexts are useful to change the issues you see - you can use a context to only show issues of a certain priority, reported by a certain user, or other specifications.
Select "Manage" from the drop down
A Dialog will appear, which allows you to select an existing saved Filter, specify new parameters, and save your specifications as a new Context.
Pick some specifications, or a saved filter, and press "Save and apply"
Your Planning Board will now show a sub-set of your backlog based on the Context you have set.

Organise by Ranking

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.

Organise using Markers

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:

You have set up story points for your project. (A story point is just a custom statistic named "Story Point".)
You have configured a maximum capacity of Story Point values for your versions.
You want to assign issues from your backlog to a version based on issue ranking and your team's velocity (story point capacity per sprint).

These markers will display as a gray bar across the middle of your backlog.

Organise using Versions and Components of a Project

You can use Versions and 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 version/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, 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, on this screen you can select an existing version to be the parent version.

Moving issues to a fix version

If you go to your planning board you will see all the cards (issues) you have. Goto the "Unscheduled" view. This will show you all the issues you have in your desired view format. 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.

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. GreenHopper helps this with by providing a chart.

Understanding the functionality of the GreenHopper Charts

For all the nitty gritty details about accessing the GreenHopper charts, see Using the Chart Board.

Chart in action and how to explain it to your client

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.

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 contant, 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.

Estimations

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

http://www.slideshare.net/pcalcado/agile-estimation-and-planning

A good Agile coach is also recommended.

Child pages