“Planning is everything. Plans are nothing.” – Field Marshal Helmuth Graf von Moltke 

Planning is critical to the success of any project. Plans answer the key question of the rationality of the investment itself. Plans help us to know who needs to be assigned to work on a project and help to track the progress towards the goal. And without plans projects are exposed to numerous problems.

Planning is a difficult task, especially at the very beginning of a project. This leads to two opposite attitudes:

1. An organisation decides to skip planning altogether – They do this when they realise that it’s impossible to predict everything. However, having no plan can be really crippling to a project in many different aspects. No one knows what tasks are to be done and in what order, or who is supposed to be responsible for what and what the deadline is, just to name a few. Therefore, such an attitude happens rarely, especially that it is usually mandatory to have things planned before you start.

1. An organisation puts so much effort into planning that it takes a lot of time – It also makes the organisation convinced that the plan must be right since so much time has been spent on it. However, a detailed plan does not guarantee that it will be more accurate or useful than just rough estimates. It also requires from you a lot of attention since you have to be careful to adjust it continuously to the changing environment. Without constant improvements it may turn out that the plan is no longer up to date. What is even worse, this can happen right after a project starts.

Why do you need to plan?

The most common reason why organisations ask you for it is because they simply need plans. Organisations use them to set up marketing campaigns, schedule product release activities, provide proper internal trainings and assign the best possible resources to the project. Beyond above there are even more fundamental reasons to do estimating and planning:

• Reducing risk
• Reducing uncertainty
• Supporting better decision-making
• Establishing trust
• Conveying information

Planning in Scrum and other agile frameworks takes place throughout the duration of the whole project. This is not a single action but a continuous process in which after each iteration the planning process is repeated. The agile planning:

• Is focused more on the planning than the plan
• Encourages change
• Results in plans that can be changed easily
• Is spread throughout the project

Planning before a project starts

At the beginning of the project it’s really hard to predict when the project will end. That’s why before the start of a project, workshops are organised with the customers. Both the developers (those assigned to the project) and the most experienced team-leaders work together to estimate the duration of the project and its complexity.

They do this after consulting the client and from their own experience. These estimates can’t be considered binding as they must be verified during sprints. Especially that the product itself will certainly change during the development process.

Planning during project life

In Scrum, every functionality is usually expressed in a form of a user story which is placed in the backlog. For the backlog to be predictable, understandable and well-timed, you must do backlog refinement. It shouldn’t take more than 10% of the sprint time and it should cover the discussion and evaluation of tasks that are likely to be done in the next sprint.

Also, go ahead with the tasks which are difficult to implement or for which the technology is either unknown or not yet selected. It is a common practice to add a spike that has a specific timebox to find the solution and answer the question of what technology to use and to determine what’s the best way to accomplish the task.

Spikes allow teams to eliminate any problems that may occur in the future and to correctly estimate user stories which are hard to estimate at the beginning.

If you follow these practices, it’ll help you predict the release date better. It is crucial to plan other activities such as marketing, promotion, tests etc. What’s more, working in Scrum enables the release date to be automatically updated after any change in the product backlog is made. This ensures the organisation stays updated.

Remember: working on the product backlog is a full time job for a good product owner, not just a single event.

How to estimate the release date?

To do this you will need to:

1. prepare the product backlog for the first release
2. estimate all user stories with your development team
3. check the average speed of your development team (a common practice is to take an average from the last three sprints)
4. divide the total number of story points in the product backlog by Avg. Dev team speed and you will get the number of sprints needed for the release.

One of the most useful tools that can help to get the release date is Jira. Continue reading if you want to know how to use it for this purpose.

JIRA version report

If the product backlog is complete and all the user stories are estimated, you may assign a version to the backlog items to get a version release report.

You can access this chart in section: reports> report version. The sample report looks like this:

The projected release date with some margin is available in the upper right corner of the chart. You can find more info on this subject on Atlassian’s support page.

Interesting numbers

If you are concerned about the numbers presented above, remember to always focus on the planning. Spend just enough time before the project starts to plan and provide estimates. Try to reduce risks before the project starts and always keep adjusting plans.

Let us know how you estimate release date for your projects. We are always open to new ideas and suggestions.