Estimating and Planning and monitoring day to day development is a lot of what's involved in the job of a team leader. This is the approach I take to this, I don't claim to have created any of this, rather it's just the collection of agile methods and tools that I find useful. This is what I do for sprint planning every 2 to 3 weeks. When doing ball-park planning for a longer period I follow the same basic process but at a less granular level with corresponding drop in accuracy.

Before Planning

There are a couple of questions that really need to be answered pre-planning. This is the side of planning that's often not visible to the juniors in the team. It's the bit that gets forgotten about and contributes to that wonderful "I don't know what my manager does, but when they're away it all goes bad" feeling in so many well run development teams.

The two questions you need to answer are

1. How much time do you have?
2. What are you trying to do?

How Much Time Do You Have?

The whole point of planning in an agile project is to commit to a given set of tasks to be delivered at the end of a sprint. To do this you need to know how much time your team actually has available. This can look like quite a daunting question, there is any number of meetings, sicknesses and other distractions to take your developers away from your sprint.

The good news is that it actually doesn't matter that much, all of these things can be rounded up into "good enough" percentages or buckets so that they balance out over time. If it all goes horribly wrong, then you can always stop and re-plan. There is a cost to this but there are times when it is necessary.

Like all managers, my worlds seems to revolve around a series of spreadsheets, so of course I use a spreadsheet to work out how much time I have available. Nice and low-tech. Basically I crate a table like the one below. The days of the sprint (or period being planned) down the left and how many hours each developer will be contributing to the sprint.

	Bob	Mary	Alice
Mon 17 Oct	6	6	2
Tues 18 Oct	6	6	2
Wed 19 Oct	0	6	2
Thurs 20 Oct	0	6	2
.....
Total	30	48	14
Grand Total	92

I plan based on 6 hour days which gives enough time for the general meetings, interruptions, email and the like which is just part of a normal day. When I have someone new in the team that's still coming up to speed I scale back the amount of hours they logically contribute to take account of the lesser productivity and impact on the other members of the team. E.g. in the table above Alice could be new and while working exclusively on my project is only logically contributing 2 hours.

It's tempting to extend this to try and account for the difference in productivity between Juniors and Seniors. But I find that this just complicates the process and warps the results. The standing differences are easy enough for the team to take into account while estimating as they know each others abilities. The reason we decrease hours for a new member is more about the fact that they're an unknown quantity to the team and at least a part of their contribution will be cancelled out by training and support time from the existing team members.

So now that we've done that we've got 92 hours right? No. In addition to the usual non-project stuff that's covered by assuming only 6 hours a day, there's generally an amount of project stuff that needs to be accounted for but is not so easily quantifiable as tasks. This is things like support of existing versions that are already deployed, supporting testers, technical writers and other members of the wider team and even fixing show-stopper bugs that block testing of your last sprint (there's never any of those right?).

I find it's good to actually track these things as it creates visibility on what the team is doing and provides a good bell-weather to see if these things are getting out of hand and derailing your planned work. I generally pick a reasonable "hours per day" number for the entire team and then multiply by the  total number of days regardless of the number of developers. E.g. I'll generally pick something like 2 hours per day for "general support", so in a 7 day sprint I'll have a 14 hour bucket task for support that the developers can draw on.

If these bucket tasks start to blow out above your allocated time then it's time to re-plan because something unexpected has happened. Generally these estimates can be refined sprint to sprint by looking at how much time the developers actually spent on these buckets.

One thing to remember about buckets is that unlike time-boxes they decrease as the sprint goes on. I don't care if you haven't done any support all sprint, you can't do 14 hours of it on the last day.

What are You Trying to Do?

The other key question you need to answer is what are you trying to do. What are the candidate tasks. This may seem obvious but I find the biggest single indicator of how good planning will be is whether the feature is broken down into good sized tasks before we actually start planning.

I find it makes planning work a lot better if the initial breakdown and approach have been thought through before hand by at least one person. The key is that this pre-planning breakdown is only a straw-man and a starting point. It will change during the planning but it helps to have a starting point to frame the discussion.

There are three things that I consider when breaking down tasks for planning. These are the same things that I consider when breaking down tasks before planning and during the planning session.

• Small
• Testable
• Independent

I try to break features into small enough tasks that they can be completed in 2 developer days. That's 12 hours based on my 6 hour days. This is not a big period of time. The reasoning for this small size is that if you get much bigger then the details tend to be forgotten during estimation and the estimates become overly optimistic. Developers will need to constantly re-estimate the time remaining on each task as they work on it. Having such small tasks makes this easier as the developers are only needing to think a couple of days out at most during this re-estimation.

There are cases where you really can't break things down to this level. Generally this means that you really don't know enough about what you're doing to get an accurate estimate in the first place. In these circumstances you generally need to just allocate a time-box to investigate the issue. The core deliverable in this case is not actually the change it's self, but the broken down tasks to be estimated in the next sprint.

Equally important is that each task results in something that is complete and testable. The main reason for this is to avoid thinking something is done then having to come back and re-work it. If the task results in something that can actually be tested then you can be far more confident that it's done and dusted and you won't need to come back. This also means that you can't generally split off the non-coding tasks. Each task needs to include the code change, unit testing it, updating the documentation, development guides, handover of the task to testing etc. This means that 12 hours is starting to look really short indeed.

There are some secondary reasons for this which are worth keeping in mind. Because each task is testable, it's also visible to the project sponsors. This avoids the situation where it appears there is no progress because infrastructure is being worked on first. This allows for a tight feedback loop that can nip problems in the bud. The other benefit is that because everything is testable, system testing can take place on nightly builds or the like as soon as the task is complete. This can result in bugs being found and reported while the code is fresh in the developers mind, reducing the cost of fixing them.

The final criteria I aim for is to keep tasks as independent of one another as possible. The goal is to allow as many tasks to be done in parallel as possible. If this is forgotten about you can get chains of tasks that while effort wise will fit in the available resource, will not actually fit in the time allocated to the sprint because they can only be done one at a time. There will always be some dependency but they key is to avoid this where possible, but if it can't be avoided, at least identify it to ensure the first tasks in the chain are done early in the sprint.

For all three of these concerns I generally find that taking a vertical slice through the feature is a good starting point and then enhance around the sides. This does mean you usually have a first task that has to be done, followed by several enhancements that extend the edges. These enhancements can generally be done in any order and even done in parallel you have enough developers.

For example, take a slice through the entire system, add a screen, service and data access layer that don't really do anything but get the communication happening. Then add one field or function into all three levels. Rinse and repeat. It's always tempting to break the feature down by levels, e.g. do the data access first, then the service, then the screen. This is problematic though, because you don't know that you won't have to revisit the data layer when you do the screen.

Tools

All the above is really just general approaches it doesn't require any tools beyond a spreadsheet. That said the right tools can make this easier. Particularly if you can do the breakdown and planning in the tool you're using to manage your backlog it avoids a lot of double handling.

Personally I use Jira with the greenhopper plugin. These are not free tools but they're not overly expensive either. Jira is our source of truth about what we're working on and what is coming up. All tasks, features and bugs are raised in Jira.

Greenhopper gives some nice tools for working with the above process. A virtual kan-ban board (those post-its that people get so focused on when they hear about agile). There is also good support for doing a the burn-down and other charts that are useful for monitoring the work in progress.

On the planning front, Greenhopper provides a really quite stramlined UI for triaging, ordering and breaking doww tasks as they come in which lightens the load of doing this stuff.