Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
We have a project which is deploying thorough Scrum. In Scrum you will update your estimates during the sprint and set them with the remaining time. We use youtrack for tracking the project and particularly its Agile Board. We used to update estimation -as I told- during the sprint with remaining time.
But I found that decreasing the estimations (when work goes on and estimate of remaining time should be decreased) wouldn't be reflected in burndown chart. It just draw that chart by sum of Whole sprint tasks estimation and sum of fixed sprint task estimations. A change in estimation will just scale whole chart, not be reflected as works goes on.
How should we change our estimates to watch it on burndown chart?
In 5.0.* version youtrack's burndown chart doesn't relies on 'old' estimation values. Ideal burndown and issue estimations values are taken from current values. In 5.1 it will have such ability (http://youtrack.jetbrains.com/issue/JT-22390)
If I'm understanding the question correctly, you need two fields. Original Estimate and Remaining Work. This will allow you to keep track of the % complete of the original size.
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
My team estimate tasks with hours, which is related to the TFS SCRUM Template nomenclature, however I've heard recently that tasks should be estimated in some abstration unit and using of hours is evil, what is the recommended way?
You can estimate in hours provided your team velocity is also based on hours since that's how you decide how many backlog items are likely to be delivered in a sprint.
But it's not necessary to use hours and it can sometimes give a false sense of exactness.
If you use an abstract unit for both estimating and velocity, you (or, more correctly, stakeholders and others who don't understand Agile) won't be confused into thinking that hours is an exact measure.
The confusion will stem from the fact that velocity is work-units-per-sprint and "hours-per-sprint" will be unchanging if your sprints are always a fixed size (say, four weeks for example, which will always be expected to be four weeks by forty hours by some number of workers).
However, your velocity is actually expected to change over time as the team becomes more adept, or experienced people get replaced with those with less experience, or half the team takes a month off on holidays.
That's why the whole concept of story points exists. They provide such an abstract measure so as to avoid this confusion. You simply estimate your backlog items in story points and keep a record of how many points the team delivers each sprint (the velocity).
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
I have multiple variations of an automated strategy for trading certain investment vehicles. For each of these variations I have cross-validated backtests on historic data. I need to pick the best-performing test. There is significant variation between the tests in terms of trades per day, net position size, etc. This makes it difficult to compare one to another.
The nature of the test relies on the predictions of a multidimensional nearest-neighbor search.
Having been recently acquainted with R, I am looking for packages/functions/tests to help me analyze various elements of my strategies' performance. Particularly, I am interested in two things:
1. Packages/functions/metrics that gauge the efficacy of my predictor.
2. Packages/functions/metrics that gauge the relative "profitability" of one variation to another.
If you know something that I should take a look at, please do not hesitate to post it!
I would definitely take a look at these two R Task views:
Taskview Econometrics
Taskview Finance
They provide a broad overview of the kind of packages that are used in these fields. Googling for:
using R for financial analysis
also got me a lot of hits that are relevant for your situation. Good luck!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Could somebody please explain this to me. It seems to me that the number of story points actually delivered at the 50th percentile would be more valuable than a theoretical number that is far more likely to get affected by outliers, especially in the early days of an organization adopting scrum.
Actually nobody says that you can't use median. Scrum just shows way to drive the proces but you can bend it (improve it) to your needs and understanding.
If you want a statistically significant method to calculate velocity, you might try using the average and standard deviation. This way, you will be able to predict with whichever degree of certainty you are required what your velocity is.
If you wish, you can limit the data to the last few sprints, if you notice a change in the trend, and can explain it as valid.
This goes towards the Agile values of communication and courage (for the stakeholders to accept the uncertainty of the prediction).
e.g.
Team: Based on the last 5 sprints, we are 90% certain that we will be able to deliver at least 30 SP in the next sprint.
scrum doens't use average or median, it's a particular team that will choose one over the other depending upon the sophistication they want..
I will suggest if outliers are the problem then choose something like average of last 7 to 9 iterations... so once you are in lets say 15th iteration you won't be having any effect of early 'bad' iterations... .
I've found measures such as average sprint velocity (or median in your case) to be a very poor way to determine what the next sprint velocity may be. The main problem is that the formula is driving the decision making and this allows a team and SM to substitute that for real thinking.
The best way to compute next-sprint velocity that I've found (using Scrum for almost 5 years) is the following:
In the first sprint or two, it's just an educated guess. We make a guess then drop back from that a bit to ensure we don't overshoot.
If the team has picked up, say 5 extra pts in the prior sprint, increase the velocity by no more than 5 points. If the team didn't pick up any new points, keep the velocity where it is unless they struggled. If they struggled, back off a bit, say, 10%.
If the sprint failed, regroup and figure out whether it was because the team picked too much work. If so, work out what stories were actually done 100% - this total of points is your new velocity for the next sprint.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
I know something about scrum and project management. For ex. We need to findout all steps of program and write down with their prioraty and work hours. But I don't know how to draw burn down chart for one sprint (which values do we need and which calculation creates the chart?).
You need
the duration of the sprint (in days). This is the x-axis.
the sum of all task-durations within a sprint. This is the y-axis.
Now you can calculate the ideal-line. On the first day no task is accomplished. On the last day all tasks should be accomplished.
The chart draws the task-hours that are not accomplished for each day.
That's it.
Here is a whole tutorial I wrote up on managing burn down charts including a google docs template and a microsoft excel template
http://joel.inpointform.net/software-development/burn-down-charts-tutorial-simple-agile-project-tracking/
which values do we need and which calculation creates the chart?
I guess crauscher already answered this question but I just wanted to say that there are tons of tools out there which can create the burndown for you automatically. All your Team has to do is enter and burn down hours during the Sprint. Although Agile suggests to prefer interactions and use less tools, if you really want to scale as a project/company you would need some sort of Agile project management software. A few I can recommend are : Scrumworks, Piviotal Tracker, Agilex.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
Is there any formula showing the development cost of an application?
Basically not to reach a very specific number but at least stressing what parts are effecting the overall cost in what magnitude?
Estimated Cost = M x L
M = Total adjusted labor man-hours
L = Labor rate per man-hour
From http://ecmweb.com/mag/electric_calculating_true_labor/ which is not software industry specific but most of the ideas should apply. Probably.
What I do to estimate the cost of an app is to break down into "small" sub-tasks and estimate the amount of work for each one. Then add some needed work for specifications, design, integration, user testing, and project management.
Then, assign these tasks to the different kinds of people in the team (developers, managers, architects, etc.) and sum the products of labor rate x man-hours in each category.
So, it is not easy at all...