Tutorial - Planning and Estimating work for an Agile team

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

My backlog has thousands of issues — can GreenHopper 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

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.

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

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

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.

Organising using Sprints

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:

• Prioritise the Backlog — Create issues for your backlog, rank and estimate them, and drag-and-drop to add them to a sprint.
  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.
• 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.
  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.
• Create Sub-Tasks — To break a story (issue) down into implementable chunks, go to the sub-task tab (click the folder icon) to view and create sub-tasks.
• Organise via Epics — Group related stories into an epic. Click an epic (in the leftmost panel) to view only the stories that belong to that epic.
• Plan Versions — Assign issues to upcoming versions. (To do this, you need your administrator to enable Release Planning in GreenHopper Labs.)
• Plan, and Plan Again — When you're happy with the stories for the iteration, start a sprint and the stories will move into Work mode. While a sprint is active in Work mode, you can still plan subsequent iterations in Plan mode (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 Plan mode 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 Plan mode if:

• the issue matches the board's Saved Filter (see Configuring Filters); and
• the issue's status maps to one of the board's columns (but not the 'Done' column).

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. 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 Report Mode (or Using the Classic Chart Board for classic charts).

Charts in action and how to explain them to your client

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.

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 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 help with that part of the process:

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

A good Agile coach is also recommended.