4

Currently in my office we have an age old problem, which I feel has been discussed to death by many, yet solved by few. The clients want a monetary amount, project managers want to know how many hours it will take, and developers only want to discuss in terms of effort.

How do you approach appeasing all of the three different scenarios? Developers are reluctant to put timings on things, project managers think story points are a waste of time and clients just want things done!

Improve this question
6
  • 1
    I'm failing to see any research into the problem. There is literally a ton of literature (if we still printed things) on the topic.
    – RubberDuck
    Aug 20, 2017 at 23:27
  • 7
    The cynic in me says that story points are just a cop-out, an admission by developers that they suck at estimating. The problem is not the units of measure; it is that providing an accurate estimate with a reasonably small degree of uncertainty is expensive. In any case, if you want a reasonably good estimate, conversion from story points to one of the other units of measurement is fairly simple; all you have to know (which you haven't mentioned yet) is the velocity of your team.
    – Robert Harvey
    Aug 21, 2017 at 0:40
  • 2
    Start paying your developers in salary points.
    – Blrfl
    Aug 21, 2017 at 3:02
  • 7
    You keep data from sprint to sprint. Regardless of whether they estimate in points or hours you record the estimates. You also record the actual hours. Eventually you learn things like 20 points averages 100 hours +- 20 hours. It's the law of large numbers. With enough data the points start to have meaning. If they had told you hours not points you do the same math comparing estimated hours to actual hours. The team doesn't have to get better at estimating. Just being consistently wrong is enough.
    – candied_orange
    Aug 21, 2017 at 8:29
  • That sounds like an opportunity for agile development. However, if your organization is not ready for that yet, why not introduce some currency exchange model, i.e. effort in days would be equivalent to that number of calendar days, and that amount in dollars? start with a 1 to 1 to 1 conversion rate, then keep on updating it whenever an item is actually delivered.
    – A.Rashad
    Aug 21, 2017 at 16:27

3 Answers 3

Reset to default
5

The idea of story points is to communicate better that estimates always have some uncertainty. Story points don't relate directly to a time frame.

If you're using agile-ish methods internally but fixed time/fixed price contracts externally, someone needs to translate between the two. That someone is probably the product manager.

As CandiedOrange suggested in a comment, they can use historical data to translate the story points of an estimated backlog into time-estimates for the client.

Additionally, they should employ risk-management strategies to avoid underestimating the required time. A simplistic estimate that just considers the average of the historical data will only give you a <50% chance to deliver in time! If such an estimate is misused as a deadline, that would set you up for failure. Instead, they should consider the variability of historical data and externally communicate timeframes that have a higher chance of completion, e.g. a delivery date when they are 80% certain that the team can deliver before then.

Further reading:

  • Steve McConnell: Software Estimation. Demystifying the Black Art.

    • Chapter 4: Where Does Estimation Error Come From?
    • Chapter 20: Special Issues in Estimating Schedule.


    This is a very thorough book that covers estimation from historical data in great detail. It is mostly concerned with non-Agile techniques, but that doesn't mean it would be inapplicable to your situation.

  • Tom DeMarco: Slack.

    • Part 4: Risk and Risk Management.


    The mentioned chapter explains very clearly why estimates are often too optimistic, and has high-level guidance for accounting for risk.

Improve this answer
3
  • 2
    I think it's important to note (in your 3rd paragraph) that you shouldn't be translating points to time. You need to know a velocity (points per timeboxed iteration) to figure out how many timeboxed iterations you'll need to complete a given backlog, recognizing that the backlog may change. Based on number of iterations, you know how many hours from each role you'll need. The rest of your points stand - you need to account for error and risk. And this is dependent on the same team using the same tools and technology stack in known software - changing things will lead to a slower velocity.
    – Thomas Owens ♦
    Aug 21, 2017 at 10:50
  • This is probably obvious, but, even an 80% success rate is not an awesome choice, at least where failure would be catastrophic (i.e. sink a company). I've seen a 90% likelihood target chosen on the project estimation systems, which means that the estimate may be substantially overestimating, however, that is not an unreasonable technique on a project where "failure is not an option".
    – Reginald Blue
    Aug 21, 2017 at 21:04
  • @ReginaldBlue Of course, the acceptable rate of missed schedules is entirely dependent on the context. Lower probabilities are fine within more cooperative customer relationships. A 80% success rate still means 1 in 5 has slipped which is a lot. But getting better odds means buying more time which might not be worth it – a slipped schedule is not necessarily a failed project. BTW failure is always an option, though usually not an attractive one. If a company depends on a single deadline for its survival, something has gone wrong long before that.
    – amon
    Aug 21, 2017 at 21:34
7

In scrum you have a team velocity: points implemented/done per sprint.

If you know

  • the average velocity of the last 3 sprints and
  • how many working days a sprint has and
  • how much a working day costs you

then you can calculate dollars per point or hours per point.

Improve this answer
2
  • 7
    ASSUMING you don't do something stupid like changing the team composition halfway through, or apply creative maths like "if I add one more person to a 4 person team, they'll have 25% higher velocity".
    – Erik
    Aug 21, 2017 at 10:38
  • 1
    But how to handle a client that wants an estimate for a complete project before starting it?
    – Kwebble
    Aug 21, 2017 at 20:05
0

Developers are reluctant to put timings on things,

This is because they are smart and have learned from experience that this is a stupid idea which has no upside for them.

project managers think story points are a waste of time and

Your project managers need training.

clients just want things done!

That's right! But estimates have nothing to do with getting things done. Spending lots of time and creating anxiety around hour estimates will actually have a negative impact on productivity (getting things done.) This is especially the case if you hold your developers to them. They then need to be strategic in their estimates and this takes time. Time spent not programming; not getting things done.

Using hours is almost the worst possible way to estimate:

  • What's an hour exactly? If the developer takes a bio-break, is that an hour? What if a PM interrupts asking for estimates or percent completion on their task, forcing the developer to spend 30 minutes getting back to what they were doing? Is that an hour?
  • How many hours are there in a day? 6, 8, 10? How many hours are there on weekends? Thinking in hours leads to the bogus idea that you can make up for lost days with more working hours.
  • Are all hours in a day the same? Scientific studies show they are not.

Story points are much more effective but the PMs need to know how to use them. People are not good at judging how long things take when they are in flow which is characterized by a lack of sense of time. However, people are good at comparing things. If I know that building the authentication page takes 3 points, and I think that the home page is roughly the same amount of work, I tell you 3 story points.

What the PMs are supposed to do is take those estimates and determine, using empirical analysis, how many days it takes to the team to complete 3 story points. There will be variance in these numbers. There's this whole field of human knowledge called statistics that helps us to make use of that kind of information. Using these calculations the PMs then predict when the work will be complete what level of precision is appropriate. For clients and 85% estimate (i.e. it will be on time or early 85% of the time) is good enough but for other clients a 95% estimate is needed. You can also use the data to help you show the cost of features and how changes modify performance.

Improve this answer

Your Answer

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

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