5

I propose the following scheme for estimating user stories in a scrum process:

A good programmer might cost 80000$ a year, so per hour this is 80000$/52 weeks/40 hours per week = 40$ per hour. In a two week sprint, a single programmer can work for 80 hours, which would cost 3200$. So the maximum size of a story for a two week sprint should be 3200$ . So instead of using story points to estimate stories/tickets, one could use the following schema to estimate tickets from lowest to highest complexity

50$, 100$, 200$, 400$, 800$, 1600$, 3200$

One could also add that bugs cannot be estimated, so we might give them always a cost in the middle of the scheme of 400$.

What would be the disadvantage of using such a scheme for estimating tickets? Has anyone tried estimating tickets based on costs within scrum?

Improve this question
4
  • When you ask programmers to estimate a task in planning poker, s/he will not be thinking in these increments. Plus, personally I think this approach can more easily confuse someone under the impression that more money has an instantaneous and linear impact on scope.
    – kojiro
    Apr 1, 2014 at 13:01
  • 4
    Expecting 40 hours a week of productive work per person is an extremely naive metric. See all the related questions on framework overhead, real vs. ideal hours, and so on.
    – Todd A. Jacobs ♦
    Apr 1, 2014 at 13:16
  • 1
    We already had the same question, but this time asking why not using hours instead of history points. I'm not that used to Agile, but I strongly believe the answer is exactly the same: pm.stackexchange.com/questions/2765/…
    – Tiago Cardoso ♦
    Apr 3, 2014 at 22:28
  • 1
    April 1st, surely? Why not use git commits for estimation? Or times you have to go get coffee before you've closed the story? (Come to think of it, the latter actually seems a good idea.)
    – Simon
    Jun 30, 2017 at 12:55

6 Answers 6

Reset to default
6

No.

The common error is to assign a time or cost value to a point, but in reality the value is determined by environmental factors and teams actually doing the work. It is a random number to represent actual capacity that can be used for planning future sprints. So, if you are using points to do relative estimation, your $ amount would mean nothing since you don't actually know how much the team will accomplish. That is the reason for the use of a "point". It has no time or cost tied to it and so informs you of the ACTUAL capacity (velocity) of a team NOT the assumed or desired one.

The original purpose of story points was to apply a numerical value to the process of relative estimation so we had a marker to use for better planning. Humans are horrible at estimating time and we get worse the larger an effort is, BUT it turns out we are actually pretty good at estimating when relating to some other thing we have done or other things around it.

So, if you are estimating a group of stories based on previously completed stories...think a conversation like, "This new story will be a lot like this other story that was a "5" so this new story will probably be a "5"." Or "This new story is going to be a little harder than this other story we did which was a "5" so we think this will be an "8". INSTEAD OF "How long will this take?"

You are relating the effort/size in relation to other reference stories.

Once you are relatively estimating stories, THEN the amount of "points" you complete is based on capacity, interrupts, vacations, previous sprints, etc. The # of points a team completes is determined by them actually doing the work.

Story points are a tricky subject as it can be used with good intentions to create an unexpected negative effect when used in a way it was meant to. Here is another reference on use story points.

http://www.mountaingoatsoftware.com/blog/how-can-we-get-the-best-estimates-of-story-size

Improve this answer
2
  • So is it wrong if management lets the developers estimate features and then based on the estimated complexity, they tell a customer, how much this feature will cost?
    – asmaier
    Apr 2, 2014 at 16:38
  • If you are estimating based on relative complexity of other known features AND the current capacity of the team then I would hope management would use that number as ONE of MANY considerations when quoting customers in a professional services environment. The estimated complexity should also tell you what likely cost RANGE it will take and then again, up to smart managers to take that into consideration if they are using it to make promises. Agile and Professional services contracting is a different subject entirely.
    – Erin Beierwaltes
    Apr 3, 2014 at 18:44
2

That's ... not advisable.

Stories are not estimated in terms of effort, so why use dollars?

Estimate in relative terms rather than absolute terms. Instead of saying, "This will take five days," say, "This thing will take about as long as that thing."

How Can We Get the Best Estimates of Story Size?

To make a long story short there are two main reasons for this

  1. Estimation is a two step process in scrum: both a story and the capacity of an iteration are estimated. The first is done in relative terms, the second is done based on previous evidence.

  2. A team should choose how to develop a story, be able to change it through negotiation and have different people develop it if necessary. If, for example, there is need to pair-program a story because of team improvement reasons, this should not be reflected on the cost of the story -- but it's probably a cost (an investment!) in monetary terms.

Improve this answer
2

Software development is not a predictive process

Scrum is an adaptive process developed specifically to address the challenges of Software development, which is not a predictive process.

  1. I am sure you have seen that requirements change more often than you expect - especially in business software and more so if a GUI is involved.
  2. Technology is unpredictable - version upgrades, security fixes, availability of new frameworks, blocking issues discovered late in the development cycle...etc.
  3. Skill levels can be vastly different. You estimate a task as 4 hours assuming Joe is going to do it. However, Joe has been assigned to some other high priority work. Other developers take two days to do the same work.

You can see more on Predictive versus Adaptive processes in this article by Martin Fowler.

Here is an article by Jeff Sutherland, one of the founders of the Scrum process, explaining why story points are better than hours for estimating software development effort level.

As pointed out by @CodeGnome, if estimating in hours is bad, estimating in dollars is even worse.

Improve this answer
2

I don't think that it is a good Idea for estimating complexity or time of the stories in dollars.

What would be the disadvantage of using such a scheme for estimating tickets?

Estimating features, especially when requirements are not ready and has only high-level description, it is easier to say which story is bigger/smaller and this relative estimation will be relevant in the future too.

Every developer has different specialties, different salary, different speed. If story-points are used, Product Owner knows velocity of the Development Team an it is enough to predict how many sprints (time) is needed to develop features from the backlog.

Has anyone tried estimating tickets based on costs within scrum?

No, Scrum framework is open for extensions but essential ideas should not be ruined. Otherwise it won't be Scrum.

A list of estimates 50$, 100$, 200$, 400$, 800$, 1600$, 3200$ could be useful for estimation of value from business point of view and it is responsibility of Product Owner (e.g. How profitable this feature is?).

Also it would be useful if developers selected stories with highest price. Unfortunately it isn't true and priorities are used in order to specify stories for the next sprint.

I propose the following scheme for estimating user stories in a scrum process

Could you follow 5-Whys technique to define the root cause for using these scheme? I think there might be another and better solution for an issue that you are trying to solve.

Improve this answer
1

A product owner / stakeholders should calculate in dollars / money.

As a developer doesn't know what the costs of a company are or what a feature will gain is it useless to let story-points be done in money.

A developer does it in points as you don't want to use a scalable methode like hours or in your case money.

As some work is NEVER done within one hour, it could be done within 3 or 5 story-points.

Improve this answer
0

Some good answers, won't duplicate what they said.

At one company I worked for, it was widely disseminated knowledge (not sure if everyone knew, but many people did) that the Finance department budgeted $X for a team sprint.

A few reasons why this was useful and different from what you are proposing:

  1. Product Managers/Business stakeholders could easily look at what the ROI of stories are.

  2. Developers could discuss things in terms of story points, then given a team's velocity, the cost could easily be figured out

  3. You want to separate cost for the same reason you want to separate time. It may take different developers different amounts of time to do a task, which in turn affects the cost.

  4. It is better to look at what a team can accomplish in a sprint, not an individual.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.