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...
Related
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 have a product backlog with some features and a sprint backlog which includes tasks for these features, and also such tasks which are not directly related with stories in product backlog (for example, testing, "to connect to db", "to do interface design" and so on). How can I calculate the velocity then?
You have two options:
Estimate them and treat them as planned work. Not ideal, since these "tasks" don't yield direct value ot the product backlog, but it sounds like work and the product backlog contains all the work that could be done to deliver the product...
Ignore them and treat them as overhead, your velocity will be lower, but that's ok, the velocity then tells you how much work you've been able to deliver that adds value. These other tasks are just "overhead". Or they'd be part of what's commonly called Refinement.
Of course the better solution would be to slice your work in such a way that these tasks are part of delivering the value for that 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
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.
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 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 are following Agile development methodology. As a SCRUM master, I am maintaining the Sprint BackLog. I want to know what is the best practice to accommodate any increase in effort for a particular task in the middle of a project.
For example, I am doing ABC task and in the starting of the sprint I have estimated that it requires 10 hrs to complete it, but on the second day I realized that it requires 20 hrs, so how will i update the Sprint Backlog.
You change the remaining work to 20 hours. Scrum is concerned with the actual work remaining, not whether the original estimate was right. That's important, but it's not explicitly part of Scrum.
If this threatens your ability to deliver on your commitment, then you need to discuss solutions with your team and possibly also the product owner. Perhaps:
A teammate might have a simpler solution.
Other tasks were overestimated and you can still deliver everything.
The product owner might decide it's not worth the effort.
Sprint planning was rushed and the sprint should be declared a failure and restarted.
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
Our software company receives literally hundreds of support requests per day and there's a whole team working on our inbox. How can we gain effective metrics that map directly to our Scrum backlogs?
If we're too specific, the team has too constantly beware of changing metrics, if we're too general, the PO has to sort through too many emails to get reliable priority.
Any ideas?
What do you mean by "support requests"?
Assuming 3 broad buckets:
"How do I do x?" type questions
"This isn't working right" (i.e. a defect)
"It would be really helpful if it did y." enhancement requests
Within each of the categories (you may have more or less than 3, but 3 is a good number to work with), assign some tags that categorize the request. I like to organize the categories as labels for vertical columns, and put a 'flag' for each request in the column. This give a quick and dirty vertical bar chart, and I almost guarantee you'll see a Pareto ratio emerge, wherein 20% of the 'tags' result in 80% of the requests. Now your PO can prioritize among/across the 20% of each of the 3 broad buckets, knowing that they are the high-value ones.
You can keep this as a running exercise.