Estimating Hours to Points

I am looking to convert that into story points,

Why?

The vendor’s time-based approach to estimation, which is apparently driven by billing, may well be sub-optimal. If so, isn’t that the problem which ought to be solved?

What advantage is to be gained by converting the man-hour estimates from your vendor into other units (story points or otherwise)? Are you trying to fix a problem that your vendor seems unable to fix? If so, have you tried bringing that up with them?

If you have trouble agreeing on the way estimates are done and you think you may have improvements, maybe you can suggest a path where you both benefit, as opposed to you doing "management by excel" :) 

My company is working with a vendor who is developing our system, they are giving us estimation in hours for each story (Billing reasons). I am looking to convert that into story points, 

You already have estimates for tasks they are developing. Why you need to have this conversion to story points ? Is this estimate in hours which is driven by billing not reliable ?

I may understand the problem you are facing a bit. We have (external) budgets to consider as well.

So different story epic/themes are billed against different budgets / different pots of money.

What we do is, there is a cumulative invoice for the labor costs (so X teams with Y people, cumulative invoice is value is Z dollars), and with that, we provide an overview of storypoints per per epic/theme.

However they want to divide the invoice, is up to them, and non of the team concerns. I know it is not an exact or hour-based approach, but we do not want to be bothered with it and our storypoint overview is all we have (and want to have)

Like others I'm struggling with why you would want to do this.  If the external vendor is doing all of the work, what benefit would you get by doing a story point conversion? In the Scrum Guide section describing the Product Backlog there is this statement:

The Development Team is responsible for all estimates. 

It appears that the Development Team is estimating their work so why would you need to convert that to another scale?

Remember that no where in the Scrum Guide does it say how estimates are to be done.  It just states that a Product Backlog item needs to have an estimate associated to it.  If estimated hours is working for the team and for billing purposes, why would it need to be changed?

Remember that no where in the Scrum Guide does it say how estimates are to be done.  It just states that a Product Backlog item needs to have an estimate associated to it.

Well, as I read it, the point here is that TS is the customer in this scenario. The vendor delivering the product is probably not using Scrum. But now, TS wants to parse the estimates from the vendor into story points, probably because he is used to working with story points in timeline/budget projections.

If estimated hours is working for the team and for billing purposes, why would it need to be changed?

Apparently because the customer, i.e. TS, thinks it's not working for him. But now TS is asking advice on his chosen solution instead of describing the problem.

My company is working with a vendor who is developing our system, they are giving us estimation in hours for each story (Billing reasons). I am looking to convert that into story points, 

I echo many of the previous responses in this thread, with the basic question: "Why?"

I also see where Yasir has asked for feedback on his approach/solution, without adequately explaining the problem he is attempting to resolve.   I don't see the value in commenting further without additional detail from Yasir around his desire to convert external time-based estimates into relative estimation units (story points).

Sorry for not being clear, I am trying to capture velocity by converting hours into points so that can be used to Forecast commitments for future increments. 

I am a fan of relative estimation over absolute estimation for many reasons. Given your situation, why can't you base velocity on hours instead of points? What do you gain by converting hours to points?

I am trying to capture velocity by converting hours into points so that can be used to Forecast commitments for future increments. 

Yasir, 

Your external vendor is providing you estimation in hours.   Why can't you use their time-based estimation to forecast target dates?   Unless I am missing something, you are attempting to introduce a wasteful translation layer on top of perfectly good data. 

Remember, story points are not a requirement in Scrum.   Velocity metrics are not a requirement either.   Unsure if this is even a Scrum issue, since it is around measuring work being done by an external vendor.

Shouldn't the ones providing the estimates provide the target dates too (forecasts)?

so they are allocating 160 hours for a month. The teams cadence for a sprint is 2 weeks. My CIO has asked me to to track velocity. Can velocity also be tracked in hours? Currently they are using T- shirt size for estimating. 

My suggestion: 

T-Shirt Size

Hours

Story Points

XS   < 8 hrs    1 Points

S    < 16    2

M   < 24    3

L    < 32    5

XL  < 40   8

XXL < 48 13

XXXL< 80 21

Please let me know what your thoughts are, any suggestion would be appreciated. 

they are giving us estimation in hours for each story

Currently they are using T- shirt size for estimating. 

So Yasir, which is it?   It is quite challenging to provide advice if there isn't clarity on the problem.

My CIO has asked me to to track velocity. 

Did you ask your CIO why the velocity of an external vendor is important?   Keep in mind that we're talking estimates here, which are:

• Best guesses based on information known
• Guesses which can be easily "gamed" to reflect positively on those providing the estimates, without resulting in any increase in productivity
• Just a forecast of effort and scope

Your CIO should perhaps look at the accuracy of the estimates being provided by the external vendor, in order to determine the likelihood of future completion based on their estimates.

so they are allocating 160 hours for a month. The teams cadence for a sprint is 2 weeks. My CIO has asked me to to track velocity. Can velocity also be tracked in hours? Currently they are using T- shirt size for estimating. 

Why do you think velocity cant be tracked in hours ? hours is just another unit like SP or T sizes. Also what is the reason for tracking the velocity ? 

Velocity is the average amount of Product Backlog Items turned into done product increment at the end of every sprint. You can use any measurement that works, whether it be points, hours or grapefruits. As another person suggested, why add another layer between the two. 

Sprint 1 - team completes 250 hrs of PBIs

Spint 2 - team completes 300 hrs of PBIs

Sprint 3 - team completes 350 hrs of PBIs

After 3 sprints, the team's Velocity is 300 hrs. You can then use this velocity to forecast your upcoming work based on the hour estimates your vendor provides. 

The CIO is asking for something that he/she doesn't understand.

He/she might want more insight in what he can expect (forecast). I would focus efforts into understanding what the CIO really wants, and try to provide a proper solution for that.

This "solution" might be an explanation about estimates and uncertainty in general.

When people outside the scrum team ask for velocities, alarm bells should ring.