Projects are a necessary evil :-) But necessary they are.

Some people really feel the need to understand precisely what the project will cost and exactly long it will take. If this is the basis for investment, of course that's a completely understandable feeling.

For years, traditional waterfall projects have been sold on the false pretense that projects are predictable. Plannable. Of course the reality is, projects are highly unpredictable, and - sadly - that's why so many projects fail to meet expectations.

So when you need to plan a project, in order to forecast the overall costs and timescales, how do you do this for an agile project?

Well, of course, agile development is no silver bullet.

If you are bad at planning, bad at identifying and sticking to at least the broad scope of the project, bad at estimating until you have all the details, bad at controlliong delivery, an agile project plan is likely to be just as bad as a non-agile one!

The benefits of agile development are more to do with early realisation of business value, early visibility when things are going off track, collaboration and regular feedback to ensure quality and provide the right solution, and so on.

Yes, there are also some important benefits in the approach to estimating, but fundamentally, planning a complete project up-front and committing to costs and timescales is still, of course, a potentially potted process. A process full of pitfalls. And a process that requires great skill and experience to get anywhere close to predicting something that will resemble reality.

But, with that caveat in mind, here's how agile project planning works...

Agile project planning is generally referred to as 'release planning'. The concept of an agile release plan is about planning multiple Sprints that culminate in a release of the product. It is not necessarily project-oriented, however the concept for projects is of course the same.

PRODUCT BACKLOG

First of all, you really need to get your Product Backlog in order!

The Product Backlog is essentially a feature list. Above all, it's user-oriented and lists features in a language that business people and users understand. It's not technical. And it's not a list of tasks. Do not attempt to list all the tasks for the project and identify all the dependencies. Just list all the features the project needs to deliver.

Also include any lasting deliverables that are not necessarily part of the software. For example a User Manual, or a Technical Reference Document for any API's. However do not list the *temporary* deliverables that are just part of delivering a feature. For example don't list the analysis tasks or design documents for each feature. Try to keep it as a list of product features and only include deliverables that outlive the project.

What I'm about to say is an important point about any planning process, whether it's agile or not, so listen up! :-)

There are generally only two things that cause your plan to fail: 1) You under-estimate the things you've identified; and 2) you don't manage to identify everything . If you only estimate the items you identify, the quality of your Product Backlog is a critical success factor for your project.

BUSINESS ANALYSIS

So surely I have to do a complete analysis up-front to make sure I've identified everything, right? Yes and no. If you're going to plan a complete project, even if it's an agile project, you do need to do *enough* analysis to identify all the features you think you need to deliver.

However, unlike in a traditional analysis with a specification, you really do not need to identify all the details about how each feature will work. Just enough analysis to list all the features, with a degree of confidence that the broad scope of the system is covered. The details can be left until later, and be dealt with just in time for the feature to be developed.

So it's very important that the Product Backlog is at an appropriate level of detail. This, in itself, is a mysterious art. If the items are too detailed, and you estimate only what you've identified, there is a high chance you'll miss some things out. But if the items are not detailed enough, there's a high chance your estimates will be wrong.

Because agile estimating (which I'm coming on to) is based on broad, relative size of each feature, you do not have to break down the features too small at this early stage when trying to estimate the overall project.

For example, it's probably sufficient to know that users will need to be able to register and log in. It's probably not necessary to itemise what details they will need to enter to register, and how the system will authenticate the login. Unlike traditional projects, you certainly don't need to worry about how long will the fields be and what validation will be needed, and minor details like that. The details can be sorted out later.

When you are reasonably confident you have a comprehensive Product Backlog that broadly covers the scope of the project, listing all the features that need to be delivered by the project - not too detailed but detailed enough to compare the relative size of each feature - you are ready to do your estimates.

ESTIMATING

First of all, do your estimates as a team. 'Planning poker' is a method where each team member writes their estimate on a card and all team members reveal their estimate at the same time. This is quite fun to do and is a great way to get everyone's estimate before they are influenced by others. Wild discrepencies in people's estimates are a great discussion point, a way to identify differences in understanding early on, and a way to understand different people's perspectives about the implementation.

Secondly, estimate your features in points. Many agile teams use the Fibonacci numbering system to do this. The points represent the relative size of each feature. For example, a feature with a 2 is roughly twice the size of a 1, which is very simple. A feature with a 5 is a bit more than twice the size of a 2, and a 21 is much more difficult.

Basically it's the relatively of this estimating approach that is important, not the number itself. The philosophy is that people can't really tell you accurately how many days or hours it will take to implement something they know little about, but they can tell you whether they expect it, on average, to be easier or harder than something else.

When the whole Product Backlog has been estimated, you now know the 'size' of your project, but it's in abstract points rather than in real units of time. How do you convert this into a cost and timescale?

PLANNING

If you are going to utilise an existing team that are already doing agile, and you know their average Velocity per Sprint, it's easy. Just calculate how many Sprints it would take to burn-down the number of points on your project's product backlog.

If, however, you're establishing a new team, that has not done agile before, you have no idea what their Velocity might be and this is another potted part of the planning process. Basically you need to make an assumption about the team size and its Velocity. In this case, this how I would do it...

Get more than 1 developer, of varying skill and experience, to look at a small section of the Product Backlog. Ask them how much they think they could complete in a single Sprint. Remember to explain what you mean by complete, i.e. done means DONE!, so you know everyone is working to the same basic assumptions.

Compare the number of points each developer has effectively said they can complete in a Sprint and decide what you consider to be a reasonable average based on what you've heard. Using that average number of points, assume that's your Velocity (per person) and calculate the number of Sprints you would need to complete the entire Product Backlog. This calculation will give you your approximate project duration based on 1 developer.

SUMMARY

Now you can make an assumption about the size of your team, based on the available people, the target timescales or the amount of funding you could potentially raise, and cost it up accordingly.

As with all projects, it would be wise to add a contingency. As I mentioned earlier, it's often the features you didn't list that cause a plan to fail. The contingency should reflect your level of confidence in the quality of the Product Backlog. If you think it is thorough, and the project is unlikely to be prone to lots of change, maybe you should add about 10-20% to your project. Otherwise it might be wise to add more.

Remember, though - although agile estimating and planning does have some distinct advantages, it is not a silver bullet. The care and attention you put into this process, along with the skill and experience of your team, in the end will really determine how likely your plan is to succeed.

Kelly.

P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...