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
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!
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! |
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). |
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.
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."
Read more about it here. |
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.
Read more about it here. |
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).
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.
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:
|
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!
Please note that we'll always rely on your final estimations in all of our other calculations. |
Well, that happens... so we have to answer this challenge somehow...
You have the following options listed below:
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.
Please note that we'll always rely on your final estimations in all of our other calculations. |
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.
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
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.
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.
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.
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.
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. |
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.
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 |
---|---|
will be ready until the deadline EVEN if your team performs with its lowest ever velocity | |
will be ready until the deadline IF your team performs with its average velocity | |
will be ready until the deadline ONLY if your team performs with its highest velocity (in every Sprint) | |
will NOT be ready until the deadline even if your team performs with its highest velocity |
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...
|