The age old question - Story Points vs Hours

My biggest challenge is that our Business Sponsor is heavily involved in our sprint planning process and requires Developer vs QA capacity to share with the wider business after sprint planning every 2 weeks. Based on this we estimate Developer and QA points separately.

What is more relevant - to have team collaboratively delivering values each Sprint or the time each member spend in a sprint ? Accountability belongs to whole team for an increment, what benefit this separate estimation will bring in ? 

Regarding points to hours - How about equating Kgs to hours? Scrum Guide says to have estimates and Story point is just one of the unit for estimation. There are teams which use time, story points, t-shirt sizing , even don't estimate at all. So, as per me your team should decide together which suits them best to provide estimates to PBIs. 

My question is, how can I move the team to complexity based points while still being able to provide the Developer and QA capacity in hours for the Business Sponsor?

Don't you think its easy to fake the points if it used for individual tracking ? what management will achieve with no trust and lack of transparency ? Can Scrum be beneficial in such environment ?

I always avoid story estimation in hours. My main reason for doing so the hours worked may not correlate to the quality of work required or delivered. As you are right to point out, it also creates confusion at various levels. 

I found a solution that works for me. I use the unit of force "Newton" (N). As you know the simple equation is F= mass times acceleration. I found it works much better since the teams were able to estimate the amount of work (efforts) required irrespective of time and acceleration or agility (prioritization) required to perform the work. As a SM I found first two sprints were hard for the team to understand the importance but later they were able to accurately assess and fine-tune their own efforts and agility. As a result, they improved the velocity and were able to dedicate more time to inspect and innovate. 

In this way, you might be able to provide the developer and QA capacity in hours if it is non-negotiable.  However, as Harshal suggested, you should try to explain that these estimates/capacity are a result of "collaborative" efforts between your dev team members and not independent and should not be used for measuring individual performances and subject to change when team composition changes. 

Let me ask you this and see if it might help you formulate a strategy.  If I had asked you to estimate how long it would take for you to drive to work this morning, could you do that?  And if you did provide an estimate, would it be fair for me to hold you to it and provide consequences if you encountered a large traffic accident on the route you chose to take?  

Story points are estimates.  Estimates are guesses based on the information you have available. Estimates are made without any actual work being done.  When you start working and log the hours you actually use to do the work, it is based on facts and reality.  Will estimates and actuals ever equal?  In my experience it is more likely that they don't than when they do. And when the equality does occur, it can never be explained as to how or why it did. One of the reasons that Waterfall was seen as flawed was because estimates are more often wrong than right and since the plans were based solely upon estimates, the plans were being created to fail. 

I suggest that you take some actual data where estimates and actuals did not equal. Do some root cause analysis and share all of that with your Business Sponsor.  I'd even go as far as to ask your Business Sponsor the same question I opened with.  They need to see how their expectations are flawed.  

(BTW, I really wanted to abbreviate Business Sponsor to two letters but decided that probably wouldn't be the best thing to do.  :-} )

My biggest challenge is that our Business Sponsor is heavily involved in our sprint planning process and requires Developer vs QA capacity to share with the wider business after sprint planning every 2 weeks. Based on this we estimate Developer and QA points separately.

It would be understandable if there was a business interest in product value, and how it is maximized incrementally by the team.

Is “Developer vs QA capacity” really what they hope to inspect, adapt, and optimize Sprint by Sprint? Have you queried that with them? It seems like a strange sort of business for anyone to be in.

I apologize in advance Ben, but so much of your post just rubs me in a bad way:

there is confusion amongst the team as to whether they should use points or actual hours. 

Why do you think they're confused?   Could it be that they are being asked to provide two different measurements that basically mean the same thing?   This is something I've always posed to teams misapplying relative estimation: "If your Story Points equate to underlying time equivalents, then why not just use the time equivalents?   Why incur the waste of translation between the two?   

You're just calling something by a different label, and believing that is somehow an improvement.

For example, if a story was estimated by one developer and one tester as a day to complete

Why is an item being estimated by only part of the Development Team?   Should the estimate hold true if these two individuals become unavailable for whatever reason?

our Business Sponsor is heavily involved in our sprint planning process and requires Developer vs QA capacity to share with the wider business after sprint planning every 2 weeks. Based on this we estimate Developer and QA points separately

Why does your organization care about productivity by role?   Or more to the root cause, why doesn't your organization trust the team to deliver according to their forecast?

Thank you so much everyone for your feedback, I'm working my way through all the ideas and suggestions.

Why does your organization care about productivity by role?   Or more to the root cause, why doesn't your organization trust the team to deliver according to their forecast?

A lot of you picked up on a similar theme to above, I completely understand the confusion here, the reasoning behind it is budget related, we have a mixture of Permanent and Contractor members in both Developer and QA roles. As I'm sure is the norm across most businesses there is always an emphasis for us to go faster and our Business Sponsor handles the budget and has to request increases in budget from his superior. Completely agree with the bad taste this leaves in most SMs mouth as throwing more budget/contractors at a team does not equal higher productivity.

We work primarily in Scrumban/Kanban as the style of work is more like a Support team with smaller work tickets coming in constantly that go through Requirement, Tech Refinement, Development, QA and Deployment sometimes in less than a week. 

On average for a sprint we have 50% planned work from our backlog and 50% new/unplanned tickets.

The conflict is as I mentioned the requirement to present a forecast of what we plan to deliver in the next two weeks which is why we're in more of a Scrumban format.

Story points are estimates.  Estimates are guesses based on the information you have available. Estimates are made without any actual work being done.  When you start working and log the hours you actually use to do the work, it is based on facts and reality. 

This seems really simple and obvious but has helped me to see this i a new light. The confusion is we have 1 measure for two different things. 

My aim for my next sprint will be to remove the confusion. Stories have story points. Tasks do not.

As I'm sure is the norm across most businesses there is always an emphasis for us to go faster

As a Scrum Master, do you agree with this goal, or is there a different goal that you should be trying to educate your business to focus on?

My biggest challenge is that our Business Sponsor is heavily involved in our sprint planning process and requires Developer vs QA capacity to share with the wider business after sprint planning every 2 weeks. Based on this we estimate Developer and QA points separately.

Why does the business sponsor need the hours to be spent every two weeks as a forecast instead of having the hours spent every two weeks as a report? What impact does this forecast have on the sprint itself and the value provided by the work the team does?

On average for a sprint we have 50% planned work from our backlog and 50% new/unplanned tickets.

The conflict is as I mentioned the requirement to present a forecast of what we plan to deliver in the next two weeks which is why we're in more of a Scrumban format.

If you are being asked for forecast what you will be able to do in the next 2 weeks, you only have the ability to forecast 50% planned work from the backlog, so do that.  As for how much money it is going to take to cover the cost of ALL THE WORK you do in the next 2 weeks, will depend heavily on the 50% of the new/unplanned tickets.  You can only forecast based on the current information.  Perfect example of this is would be a 10 day weather forecast. They usually change daily and sometimes more than once a day as new information comes in.  So you can give a forecast that the business sponsor can use to estimate a future cost but they, and the ones providing the actual funding, have to realize that it will change.

I point to this page from Merriam-Webster where it defines forecast.   https://www.merriam-webster.com/dictionary/forecast   Remind everyone that forecasting is a Scientific Wild Ass Guess(SWAG) at best. 

Right from the start of this thread there has been five  units of measurement added for time, we now have mornings, hours, afternoons, days and half days.  Exactly how many hours are in every ones mornings, and how long is your work day. Until you level set on point/ UOM you will never have a  solution and this will perpetually be the "age old question"

It's not even the question. It's some stubborn Scrum masochism

After all what was written to explain that story points are NOT METRICS (while time naturally is), bringing them back into the metrics field is some masochistic desire to wreck own team off the rails.

Here is more https://www.datainventors.com/publications

Check for "danger of story points in Scrum"

The conflict is as I mentioned the requirement to present a forecast of what we plan to deliver in the next two weeks which is why we're in more of a Scrumban format.

Hi Ben,

I assume that your team wants to improve your forecasting accuracy. Taking the empirical approach the team needs to depend on what is already known, which is what happened in the past. 

Let the team take some of the PBIs delivered in the past for which the effort spent is already known. When forecasting the new PBIs the team compares them to those already delivered.

You don't do forecasting but comparisons. You can get forecasts based on past reference PBIs. 

This above is in many cases oversimplified. As you mentioned you have development and QA work separated, and maybe the time spent depends also heavily on who was doing the job, etc. So, some additional factors might need to be taken into account to address these. Also, your work might have huge uncertainties (e.g. working with some old codebase, which nobody knows from the team), so this will definitely impact the accuracy even further. However, the key point is to use the past when forecasting the future. The bigger the sample from the past the better.

Still, this is only the forecast since what will happen is always unknown. 

How experienced are your team members in the domain where they working? Are they able to compare tickets? Are they able to forecast for the whole work what needs to be done?

If you use story points to simplify time forecasting, you will run over time into the issue, that the time-SP relation will shift and then your forecasts are getting really bad. If you do that, because the (waterfall) organization around the team needs estimation what they can understand - and time is more understandable than SP - stay on time estimation.

There is no Scrum way of doing forecasts. Time estimation, SP, T-shirt sizes and no estimates are all valid, it needs to fit into your team and organization.