Which one of these story point estimations make sense?

Curious as to what others think and what are some things I can do to move to a place where everyone is on the same page. 

My advice is to start by reflecting upon your first paragraph, which clearly indicates that Scrum is not being used.

Unless a forecast of work is planned for release every Sprint, and team members are jointly accountable for the work they do, estimation is unlikely to make a great deal of sense. The prescription of rubric does not compensate for that.

Neither makes sense.

The first thing that stands out is that the idea of completing points moves the team toward a feature factory. A team that churns out features or changes rather than committing to objectives or goals and solving problems is inherently anti-Agile. It doesn't show trust in the team to get the job done and doesn't promote a sustainable pace of development. This also goes to measuring hours. Unless you are obligated to do so, such as some contracts or for capitalization of expenses, there's no need to track hours or points. Just track if the objectives were met by the team as a whole.

The exercise of converting points to hours seems wasteful. If you want to figure out either the ideal hours or actual hours to complete work, why not just estimate in that unit anyway rather than obscuring it behind a conversion formula? Or, even better, why go through the process of estimation at all and focus on understanding and decomposing the work into the smallest deliverable, value-adding chunks that are well understood by the team?

If you do decide to estimate, the estimate should not depend on who gets the work. My personal rule of thumb is to estimate as if the least experienced person gets the work. This makes sure that you aren't overloading the capacity of the team. If you do end up with buffer time because a more experienced person picks it up, that could be a good opportunity to cross-train people and build up the skills of other people on the team. That is how you turn more junior people into senior people.

IMO It does not matter in what units you perform estimation, as long as it helps participants to gain a shared understanding of the subject that is estimated. Each approach will have its own pros and cons, but the end goal is the same.

A question like this:

(...) how do we know how many hours someone worked in a week if there's no threshold? (...)

might be a sign of (over)accountant habits, and it may be worth to challenge why it is important to track and know that? What value does it bring?

The team members should not be forced to have the same algorithm in mind - let each one find its own way of thinking, if you do things like 1sp = 3h, then you only cover the true question of "how much hours it will take?". It is an unnecessary overhead in my opinion when it is used like this.

When the topic of hours in estimation arises, I always wonder what interested people do with cases such as:

• Someone tells you it is about 2-3h, therefore you decide to give it a go, after 6h it is still not done, what do you do? proceed further (risk of sunk cost fallacy) or drop the work?
• Someone tells you that it is about 20-30h, therefore you decide to not do that, in fact, it could be done in less than 5h (and you definitely would invest that) but you will never find this out - was that estimation helpful then?
• If you track and consider the exact time spent on a task, do you also account for each minute that someone thinks about the solution "after office hours" - i.e during the commute?
  • I like the example with the "slide to unlock" feature on the first iPhones, the developer was inspired by WC doors in the airplane when he was returning from a trip. I don't think that anyone tries to account for the time he spent thinking about the problem and possible solutions.

I think that a better approach to try is to simply trust employed people and ask the PO (or a sponsor of the initiative) how much potential value he sees in the task at hand and much time in the worst-case scenario he or she is willing to invest before giving up? He or she knows the price for an hour of work, so that should be a simpler question to answer? Business requires risk, you just can not avoid that 🤷🏻‍♂️

@Piotr Górajek

So the current issue we're facing is that once a project is done the CTO doesn't know how much dev effort was put into the project and then compare was the investment worth it. I'm not sure what the best solution for this would be. The current answer it seems is to have devs update the original estimate to how long it actually took them to complete the task and then use that metric to analyze the overall effort spent on the project after it's completed. 

Why are story points and sizing necessary? Is it mandated by management so that they can run reports on productivity and for projections? If it is a requirement, then keep it simple. 1 point = 1 day's work per Development Team member.

If sizing and story points are not required, life gets simpler. When allowed to, I ask the Development Team members to tell me which feature or Product Backlog Items they can fit in a week's Sprint (I prefer one week Sprints). I have only been able to get away with this simplicity when I've truly been empowered to make decisions and deliver a quality product without having to obsess over velocity.

If the issue is trying to determine if the investment is worth it, it's too late for that. Agile methods tend to handle this differently. A common practice in Agile methods is to have a stable, consistent, cross-functional team. If you have such a team, you can figure out their cost per time, such as cost per Sprint or cost per month. If you can also estimate the value of implementing an idea to the organization, you can set your team down the path of ordering and implementing the requirements using iterative and incremental approaches that promote a high amount of visibility into progress and risks to the stakeholders. You can, on a regular basis, compare the number of iterations, the total cost, the achieved value by having a usable product frequently, and the estimated value to see if it makes sense to perform one more iteration. The work can stop if the risks of proceeding are too great or the cost of one more iteration no longer adds sufficient value to the product.

You don't need Story Points at all for this exercise. Story Points can be one tool that may help a Development Team make their progress visible and forecast when certain items are completed. Other metrics may do this as well, though.  Monitoring cycle time, and throughput can also be beneficial. How many units of work (Product Backlog Items, User Stories) are implemented per unit of time (Sprint)? How long does it take one unit of work to progress from a ready state to a done state?

@Vildana E Let's go through your post with the Scrum Guide in hand :)

So the current issue we're facing is that once a project is done the CTO doesn't know how much dev effort was put into the project (...)

In the Scrum Guide, we can hook for a while on those parts:

Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.

So simplification for the question of how much effort? would be an answer: one sprint. As each sprint is (can be considered) a project.

Going further in what you highlighted in your response:

(...) and then compare was the investment worth it. (...) analyze the overall effort spent on the project after it's completed.

Take a look at those parts from the Scrum Guide:

(...) The heart of Scrum is a Sprint, a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created. (...)

(...) Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month. Sprints also limit risk to one calendar month of cost. (...)

(...) A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. (...)

So that comparison, or simplifying it to finding an answer for the question: Was it worth doing? Should be seeking at least during (each) Sprint Review.

(...) I'm not sure what the best solution for this would be. (...)

Does your CTO also act as the Product Owner? Is he participating during the Sprint Review? I would take a look at that and consider if there is some room to improve the collaboration and feedback that should be there to influence decisions that are made by providing answers to questions that I suppose you seek here in this topic on the forum 😉

A small IT team which works in 1 week sprints, has deployments every 2 weeks, has a threshold that each dev on the team has to complete 30 points each sprint which somehow equals to 40 hours, and use the following story point "rubric" for estimating work:

Whoever put this together does not at all understand Scrum. As a SM my sirens would go on here. Is that sold to the customer? If so, you should coach your organization and the customer about Scrum, espescially the self-organization part.

To me having a story that's worth 13 points in a 1 week sprint seems unrealistic and inflated. So I proposed the following (added hours for guidance): 

I would support you from my perspective and how my teams estimates. But if I would come new to an existing team, I would not object if they handled it that way, as the story points are defined by the DevTeam. (self organized)

The results were that in the old system work was being overestimated significantly. For example: an originally estimated story of 13 points turned out to only be worth 3 story points of effort that was actually put into that story. 

Sure, if you tell a team to work on at least 30 points, while half of Sprint shall be estimated with 13 only, and the team may estimate themselves, they will overestimate to fulfill the goal of 30 points.

How can a 1 story point mean the same for a jr dev and a sr dev?

you cannot calculate points to hours or vice versa (another error done in the "rubric") You only estimate relatively and have complexity and risk included in the Story Points, plus volume of work. The amount of hours per Story Point is then like a Gaussian distribution, while every Story Point overlaps with their neighbor Points. And yes, a Senior may be quicker than a Junior, but they have the same Point, just a different velocity.

And last but not least, one very important point against the way Points are counted. Everything done in the Sprint is always done by the DevTeam, not by single developers.

I'm going to post this article from the individual that is said to have created Story Points in Extreme Programming.  It might help you understand how your suggested solution is unreasonable. 

https://ronjeffries.com/articles/019-01ff/story-points/Index.html

As everyone has said, the practice of requiring each developer to complete a specific number of story points is only going to cause problems.  If your CTO wants to know if the investment was worth it, they should be looking to the customer for the answer.  Does the customer see the money that they spent as being worth the solution that was delivered?  If so, it was successful.  There might be secondary questions asked about whether your company made enough profit but that is not going to be solved by having each developer complete a specific number of Story Points or a specific number of hours.  If employees are being required to complete a specific number of units of something, they will complete at least that many units. Especially when there is no way to accurately determine how many of the units were actually done.  In work like software development or knowledge work in general, you can not know how much time an individual spent on something.  Time spent thinking is hard to measure.