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.

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Leave a Reply

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

Recent Posts

In The Zone with Marcin Zasepa

Welcome to the second in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Marcin Zasepa, CTO at Homegate AG in Switzerland. Every episode will be approximately 30 minutes

Read More »

In The Zone with Sasha Bilton

Welcome to the first in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Sasha Bilton. Every episode will be approximately 30 minutes long, and we aim

Read More »

Case Study: DAZN Data Engineering

Find out how 101 Ways helped DAZN improve their existing data warehouse as well as planning and setting the foundations of the new cloud-based data platform. Click here to download the full case study. Get in touch with a member of the 101 Ways team if you would like to discuss ways in which we can help you and your company

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. Allaboutagile.com is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?

London

101 Ways Limited
41 Corsham Street
London
N1 6DR
United Kingdom

Manchester

101 Ways Limited
No.1 Spinningfields
Quay Street
Manchester
M3 3JE
United Kingdom

Amsterdam

101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam
Netherlands

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at contact-us@101ways.com.