With our agile planning feature we try to give you basic tools that help you answer management questions such as

• What would the ideal team structure be?
• How fast will we be?
  • based on historical data or your own estimation
• When will all the Stories be completed?
  • worst, realistic and best cases
• How much will it cost you?
  • worst, realistic and best cases
• What will be ready until the deadline?

We are about to give you answers that are easy-to-follow and easy-to-explain to your management since we believe that transparency is one of the core principles of agile, so we want all stakeholders of your project to understand it after 2 minutes of explanation.

After getting the data from your team (basically Story and sub-task estimations, Velocity estimations if history is unavailable) and from your PM (such as cost of the team for a Sprint), the question is always: can you provide more information than the 5 above?

If you think yes, or you think that with a bit more data (gathered from JIRA or provided by your team) we could tell you more or be more reliable, do not hesitate to tell us!

What would the ideal team structure be?

It is always a good question that how much frontend, backend, QA or other type of work the project requires. If you answer the question you'll get hints about the ideal team structure you should establish.

You can always guess, of course and if it is enough for you then just skip this section, it is probably not for you.

What we try to provide here, is an educated guess. How?

It's simple: just ask your team to split the Stories into sub-tasks, and set the Work type of these sub-tasks.

The more (and more representative) you make split the more educated the guess will be on the distribution of work types in your project.

How fast will we be?

Well, first of all we should define how we measure the progress of your team.

We believe in one of the main principles of Agile explaining that the only proper measure of the progress is the features (Stories) set to Done (the definition of Done is completely up to your project of course).

"Working software is the primary measure of progress."

If you don't believe in the above statement probably we can't help you since your are not in the Agile business.

Let's assume that you are with us. So this case the progress of your team is measured in "Done" stories.

Does it matter what kind of measure you are actually using to estimate your stories? Story Point? Business Value? Ideal Hours? Ponies? Well... think about it... absolutely not.

Within your JIRA Agile Board you can set the measure of your choice. We'll respect this setting.

Assuming that we agreed upon the above, the question "How fast will be be" is simplified to "How many X will we complete in the upcoming Sprints". Where X can be anything you want (and set), we prefer Ponies.

This is also known as the "Velocity" of your team.

This Velocity can be estimated quite easily (if you know an easier method just let us know).

If you have run a few Sprints with your project

The more you have executed the better, since this way you do not have to guess, you have proper measurements.

You can see the actual performance of your team.

Just select the boards (your current board is auto-selected for you actually) and we'll show you the worst, the average and the best velocity your team had during those Sprints.

If you choose not to rely on the past velocity of the project you can change this pre-calculated velocity easily for other calculations.

It is always good idea to ask your team about it!

If it is a brand new project without a single Sprint executed

Well, that happens... so we have to answer this challenge somehow...

You have the following options listed below:

Use velocity of other projects

It can make sense only if you have the same team (with the same team members with the same availability or with very little change) as in those "other projects".

However it can be still unreliable (and in practice we think it is) because even though the team can be the same, this time they may choose another type of scaling (Fibonacci or 1-10 or 1-20, whatever) or even if within the same scaling, they choose another "base Story" (a Story to which all the others will be measured, usually with Story Point 1 or 2).

If you choose to rely on this data or at least you think it would be a good starting point to be revised later on... Just select the board(s) you want to consider and we'll show you the worst, the average and the best velocity your team had during the Sprints of those projects (well, Boards).

We highly recommend you not to rely solely on this velocity, use it only as a hint and use other methods explained down below to revise these numbers.

Run a few Sprints with your team

Well, it is the most recommended approach of course which could easily lead you to the previous situation, but not too realistic if your have a client who wants some facts and figures before wanting to sign a contract with you.

Ask your team to estimate a velocity

It is always a good idea to ask your team about velocity they would predict for the future.

The easiest way to do this is to have a meeting where you ask your team

• to split some (that should be enough for 2-3 Sprints at least) representative Stories (from the beginning, middle and end of the project, small, middle sized and big ones equally) into sub-tasks
• about how much they could complete in a Sprint (worst case, realistically, best case)

This is clearly the best approach.

Why? Who else could predict better how much they can do than the ones who will actually do the work?

Does not matter how much past data you have, it is good idea to counter-check the velocity predictions coming from any other sources with your team.

If you can't close your Stories properly (so the number of your open Stories is growing) and therefore your velocity is 0

Oh boy, yeah, that s.cks, we think here that it is one of the most challenging part of Scrum, well Agile,
you can read about how to overcome this problem here.

The problem is that if you can't overcome this issue than you just CAN NOT tell anything about your progress, since you CAN NOT have any idea how much is actually left out of your Stories.

Have you heard things like "it is 90% Done man, just 1 day more"... and the original estimation was 4 hours... well, it is why we don't estimate Stories in hours and do not give a... well, not too much to it when somebody says "it is 90% Done", it just usually imply that soon we'll have to refactor our whole codebase to use JQXGrid instead of HandsonTable... no, no, it did not happen to us but to a friend of us. 

When will all the Stories be completed?

If you have all the Stories estimated (in whatever measure you want to use, Ponies for us, as always), let's say you have not-Done Stories that adds up to 200 Ponies, and you have the 3 velocity numbers (worst, realistic, and best cases) from the previous step it is an easy calculation.

Just divide the 200 Ponies with the 3 velocity numbers and you will get that how many Sprints you will need in worst, realistic, and best cases to complete all your remaining Stories.

If we know that you have 2 week long Sprints (you can set it) then we can tell you 3 dates as well.

Easy, isn't it? Well, it is as long as you keep our mantra in mind: "You should always rely on a calculation as much as the data behind justifies this" in mind

There are things to understand/consider before rely on this calculation too much.

• Your velocity numbers are in a very strong relationship with the Sprint length
  • for example, if you are in the middle of a project and you had 1 week long Sprints with an average velocity of 5 Ponies, and you want to have 2 week long Sprints from now on (not recommended, but still sometimes necessary in real life) then you should adjust this past velocity, maybe to 10, it depends, but it is very likely that from now on your velocity will be higher.
• Our calculations do not consider national holidays, low performance periods (Christmas time, common vacation periods), etc... they are just educated guesses
  • If your velocity is calculated from data of a whole year or more, then you have a very solid basis to make predictions for the next year, since your velocity has automatically taken into consideration all the holidays, vacations, sick leaves, etc... that will happen in the next year as well with more or less the same probability.
    But usually you do not have such reliable data and your team changes.
  • We recommend you think about it and use our educated guesses as advice.

How much will it cost you?

If you already know how many Sprints you will need to complete the whole remaining project (from the previous calculation) it is easy enough to calculate how much it will cost you, as long as you know how much your team (working on your project) costs you in a Sprint.

It may sound weird that we ask this information from you and do not calculate it for you, but it can easily become very complex... we should consider team members, their location (office costs), their salaries (sensitive), their availability for the project, etc... So we decided to let you answer this question, but let us know if you think we could help you with this.

What will be ready until the deadline?

An annoying question... we all agree on that.

With Plangle you can give you the best answer(s)... based on velocity you set previously of course (what else?).

If anybody asks you to "be more specific" you can always tell them "based on what data?"... and if they have reasonable ideas, please do not forget to tell us.

So after entering the deadline (in the header) the answers are represented as a colour marker line: