Agile Project Planning

This content is syndicated from by Kelly Waters. To view the original post in full, click here.

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.


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?


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.


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.


Leave a Reply

Your email address will not be published. Required fields are marked *

fourteen + one =

There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”



To explore how we can help you, please get in touch