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

Everybody knows, or should know the project triangle.

What we know about this is that we can only edit 2 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.

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 the task be to achieve sign off?
• Is the subject 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 pairs or Bobs 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", this 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 have a team velocity you can then calculate based on the current team performance how long the remaining tasks should take to complete, something which GreenHopper helps with by providing a chart.

Understanding the functionality of the charts page.

This page provides all the nitty
gritty details about accessing the charts 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 whats 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.

Other considerations 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 have also made assumptions about the following:

• 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 moral
• That the error in your estimates is constant

Of course there are more and these should also be factored in when setting expectations.

Estimations

Estimating is still important and here a few links I like to help with that part of the process, really if your looking for help in this area you should find a good Agile coach

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