TRY Plangle on our Demo site without installing it in your environment !

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!

Note

We try to follow popular approaches recommended in books such as the ones of Mike Cohn.

You must understand how we make these calculations in order to judge whether they make sense in your current environment (they certainly do in ours).

If they do not, please let us know and we'll find a way how we can support your Agile processes!

Focus on future

Our calculations give you predictions about the future but we do not really give you historical data about Sprints. JIRA Agile has great reports about the past and we do not wish to replace them.

So for instance the cost of the project we calculate is the remaining cost, the velocity you should enter (backed by past data we help you gather) is a prediction for future velocities, etc...

Furthermore, we cannot give you cost estimations for stories that are "Done", since you have facts and figures about it (or at least you should have if you have a proper Time Tracking tool such as Tempo Timesheets).

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?

Worth to watch...

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."

Why?

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.

How much should I rely on this?

You should always rely on calculation just as much as the data behind it. Do not rely solely on our numbers, rely on your own sense!

Examples:

If you already had 10+ Sprints with a team completely unchanged then this data is
- very reliable
- there is no reason to question it
If you only had 2 Sprints with the same team then
- reliability can be more questionable
- it is likely that you'll see surprisingly low numbers (even 0-s) only because the team hasn't worked together
- the beginning of the project is always a bit more troublesome, isn't it?
If you your team has just lost a member and you cannot replace them
- reliability is very questionable
- you should consider revising our numbers
If you change your Sprints' length frequently...well, less frequently
- that means that your velocity will mislead you
  - for instance if you had a 1 week long Sprint with 5 Ponies, and a 2 week long one with 8 Ponies your average velocity is not (5+8)/2 ! It should be much closer to (10 + 8) / 2 but it's not that easy to tell, since a 2 week long Sprint can have different dynamics than a shorter one so you can't just say that "our team will do twice as much during a 2 week long Sprint than in a 1 week long one". It should be close to that but usually a bit more.

Getting rid of extremities

We read in a great book (yes, we do these kinda old-school things) and saw on Mike Cohn's famous site how we should estimate future velocity and we liked it (made sense actually) so we decided to use it.

In practice it means that as you have more and more completed Sprints you have to start ignoring more and more extreme Sprints, both the slowest and the fastest ones, simply because statistically they are "wrong", representing some kind of abomination like Christmas time, Zombie attack (explaining slow ones) or a bunch of Google developers who came to your help for free out of nowhere (explaining the very fast ones) and then disappeared.

We recommend this switch to be left alone but you can always switch it off if you you don't like this concept.

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!

Velocity for other calculations

Please note that we'll always rely on your final estimations in all of our other calculations.

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.

Velocity for other calculations

Please note that we'll always rely on your final estimations in all of our other calculations.

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?

Prerequisites

For this calculation you must have velocity estimations.

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.

Focus on future

Please note that we give predictions about the future, so no matter how many Sprints you already had, how long these Sprints were, we take the the velocities you entered in the previous step, the Sprint length you specify, and the start date you specify.

If you have a running Sprint then the date should be set to its start date, if you don't have any (in case of new projects, or ones that are on hold) then you should specify your next Sprint's start date.

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?

Prerequisites

For this calculation you must have velocity estimations.

This calculation uses the number of Sprints neccessary to complete the whole project based on previous calculations.

Focus on future

Please note that we give predictions about the future, so we do not consider/estimate how much money you have spent (let's assume you are aware of this, and you have more concrete numbers than we can ever guess), we only calculate the remaining costs.

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:

Colour	Description
VERY LIKELY	will be ready until the deadline EVEN if your team performs with its lowest ever velocity
LIKELY	will be ready until the deadline IF your team performs with its average velocity
NOT LIKELY	will be ready until the deadline ONLY if your team performs with its highest velocity (in every Sprint)
IMPOSSIBLE	will NOT be ready until the deadline even if your team performs with its highest velocity

My project won't meet my deadline! Help!

What should you do to when you see that you can't finish until your deadline?

Well, it is not Scrum, Agile or any other methodology specific... you have to be a good PM and...

check if your velocity estimation is correct
check if you can make it any faster with the same scope, QA requirements
1. add new guys to the team (consider learning/teaching time, limited parallelization possibilities, etc.)
2. replace some of them (consider learning costs, breaking morale, etc.)
consider lowering QA requirements (to see how to do it just check our browser restrictions) and ask the team how it will change velocity
consider rearranging Stories moving the more important ones into the Green/Blue zone.
you can try to issue some overtime
1. it can only add 10-20% boost and only to 1-2 Sprints... if you are in the last Sprint that's kind of an OK solution (sorry our poor fellow workers)
2. after 2-4 Sprints the result will be 0 performance boost, and higher costs (sorry, business-owners)
3. after that it will result in negative performance and the loss of your best guys who can easily find new jobs with better management (that happens as well, no question about it)
just tell your management that you won't meet the deadline because it is not possible (yeah, those kind of things happen in real life, sorry)

On this page:

You can always contact us should you ever feel we could do more for you!

Support

Browser not supported