Sucesfull planning in software development

All successful people have a plan. They plan literally everything from work related stuff to details of their personal live. One of my friends used to plan how much he’s going to earn the next day. He used to make up a number and write a short sentence in his notebook like “Tomorrow I’m going to earn £5,000″ (It was actually 25,000zl because he lives in Poland). In some mysterious way he was able to earn that money which was astonishing even himself. Obviously if you don’t own a business your salary won’t spontaneously change over a night but a good plan will help you to manage your boss, the development and ultimately will contribute to your success.

What I’m going to say here is not rocket science. It’s actually pretty simple common sense stuff but if you didn’t try it before you are going to be amazed how effective that is. It might be also used as the first step before moving into SCRUM.

Lets assume you received a high level requirements to integrate an online store with PayPal (which by the way is the worse integration experience ever). The requirements might come with a request to do it in 3 weeks or if you’re lucky somebody will ask you for your estimates.

Regardless of the time pressure you need to break the requirements into user stories. If you’re not familiar with Agile a user story is a sentence written in a business language describing what a user does or needs to do as part of his job function. In this case that might be:

• as a merchant I want to setup my PayPal account to collect payments
• as a merchant I want to return money to my customers for orders paid via PayPal if I change order status to “refunded”
• as a customer I want to use PayPal to pay for my order

It’s important to confirm user stories with stakeholders. Usually you can capture and have them confirmed on the same meting you received the requirements. Even if that’s the case don’t worry about over communicating. Write a short e-mail summarising what are you going to work on.

Once you have a good understanding of what to do and you confirmed it’s exactly what the stakeholders want, you can start working on your plan.

Break down user stories into separate tasks (you can think about them as points on a todo list), for example:

as a merchant I want to setup my PayPal account to collect payments:

• research how to integrate with PayPal
• design PayPal section on the payment settings page
• integrate the PayPal design with the payment section page
• design and create database schema
• create PayPal model UnitTest
• create PayPal model
• alter payments settings controller to handle PayPal payments
• log updates to PayPal account settings

It might be boring and laborious process because in real live you will have more than 3 user stories. Don’t rush and stay focused. It’s very important to do it right because you are going to build your strategy around those tasks.

Once the list is done you need to estimate how long it will take to complete each of the tasks. There are few ways to do it and different people might prefer a different approach. I usually go for the following formula:

• estimate in hours
• use simple values like: 0.5h, 1h, 2h, 4h, 8h, 12h, 16h, 24h
• get a pessimistic and optimistic estimate and chose a value between them
• don’t estimate other peoples tasks
• confirm your estimates with other developers

If you would like to have a proper Agile experience go for the planning poker.

Now it’s going to get fun.

Sum up all numbers and add about 10-15% for QA and bug fixing. Confront it with available resources and you will get a guess (and this is the right way to call it) of delivery date. Obviously that’s under assumption that the world is a perfect place. Nobody will get off sick and everybody is going to be 100% productive. In the real live something will always go wrong so you need an extra 15% of time for contingency.

Just to make it clear, contingency is not a free time added to a project by default. You need to operate as it’s not there and you’re allowed to claim it only for a valid reason.

If the delivery date doesn’t fit your deadline you have the responsibility to communicate it to the business. I recommend a simple but very effective presentation where you display high level requirements as multi color boxes. In our simplified example I would create only two of them: “paypal payments” and “paypal returns”.

This is the complete set of features which the business expects you to deliver (in the real live you would be looking at something similar to a chessboard). Now, lets assume you have only 20 man-days available so the realistic scenario will look as follows:

This diagram shows core functionality, which can be delivered to the end user in a given time frame. It provides 20% contingency (4 days) which reduce a risk and is much more realistic.

Obviously there might be a business need to deliver everything in the given time. If that’s the case you will need to ask for additional resources. If there is no budget available then you need to be transparent about the risk. There is always a chance you will deliver on time but if things go wrong than everybody will know what to expect.

The idea is to print those diagrams and handle them to everybody on the meeting. Encourage people to write on them and rearrange things if they want to prioritise.

At this point you should have a complete and approved plan. You can print it off and monitor your progress on a paper or (more likely) us a web application. There are plenty of good tools over the Internet and you need to select one which will suit you the best. My recommendations are:

• Google Docs – good old Excel spreadsheet with version control is a sufficient solution for many organisations
• Trello – I personally didn’t use it for my projects but I know many people who absolutely love it
• Basecamp – very successful project management and collaboration tool
• Moovia – Trello on steroids although little bit confusing interface

If you would like to see more tools have a look at Agile Designer website. They have a great catalog and it’s a good website to know.

Planning is extremely important even you are the only developer. It improves communication with stakeholders, gives a structure to your work and motivates. Every time you tick a task off your list you will experience an immediate sense of accomplishment. If on the other hand you were not productive enough you will instantly notice an annoying trend change.