How are Story Points not always defined by time?

So, how can the Story Points not be related to time when they exist within a 2 week Sprint?

The purpose of estimation in Scrum is for Developers to get their arms around how much work they can take on in a Sprint. Everything else reduces to value delivery and empirical process control.

If the Developers are estimating with Story Points, you would indeed therefore hope that they would relate their forecast to this timebox. The amount of work they can reasonably induct may depend on additional variables other than time, such as effort and complexity, and the nature of a Story Point in their scheme may reflect this.

Alternatively, when Story Points are associated with hours or days e.g. 1 point is half a day, 2 points is a day etc.

I'm going to recommend that you read this article from Ron Jeffries about Story Points.  (https://ronjeffries.com/articles/019-01ff/story-points/Index.html)  He is said to be the creator of Story Points and this article clarifies a lot of about the original intention.  It debunks a lot of myths and provides some good insights.  I do not know where you learned the basis for your statement above but according to that article, it is incorrect.

You never complete Story Points.  You complete Product Backlog Items.  Story Points are estimates (i.e. guesses) made at a point in time based upon the information available at that time.  After work begins, new information is gained and the original estimate is no longer valid. Velocity based upon past estimates is inherently flawed. 

Story points are abstract estimations of effort. If you want to estimate backlog items in time its perfectly ok in Scrum, in fact its better for inexperienced teams. There os better metric for measuring time then story points.Its called seconds, minutes and hours.

In Scrum there is also a concept of "ideal hour/day" vs real. Check it put, very useful

Daniel, thank you for the link to the article. It was excellent. I think the problem is that the "horse is already out of the barn." Management loves Story Points, because they love Velocity. They also think that Velocity should always be increasing. They also want to know when the software will be done. Even though, no team has delivered software on time without either changing the date or cutting features. I also have not heard of a single PO or scrum master think we shouldn't be estimating with Story Points. I think they all own a piece of the company that manufactures the Fibonacci card decks.

Points are estimates (i.e. guesses) made at a point in time based upon the information that available at the time the estimate is made.  Once work begins, new information is gained which makes the original estimate obsolete.  Trying to determine a team's ability to deliver work based upon the guesses made before work is not going to be consistent.   However, looking at flow metrics has been pretty successful for me.  Flow metrics like Cycle Time or Throughput based upon the actual Product Backlog items can be very helpful.  Look into the book "Actionable Agile Metrics for Predictability" by Daniel S. Vacanti.  And then his follow up "When Will It Be Done"

I have no problem with management being in love with Velocity.  But they need to use something better to measure it. 

Management loves Story Points, because they love Velocity.

Please allow me a short remark. This is obviously wrong and dangerous thing, which many Scrum teams suffer. "Story pointing" and obsession about velocity instead of value became a cancer of Scrum.

But this is not a fault of the management.

Danger of "story pointing" is one of the biggest problem any Scrum master has to address, and it is HIS JOB to do so.

By explaining that velocity is just an meaning of Scrum team based on their own thoughts, and making any business conclusions based on that is as valid as making economic prognosis based on the tomorrow weather prediction made by grandmother hunch

It is Scrum masters job to educate management about Scrum, not visa versa. If environment where Scrum is taking place is not openly hostile, but Scrum master is to shy to promote and educate management, then its better not to do any Scrum at all.

Yes teaching own employer is certain risk, but... Remember "courage"?

I agree, but it is surprising that after 50 years of "modern software development," so few in management have even the smallest understanding of how software is created.

Also, I think a Scrum Master would argue that "courage" doesn't pay the bills.

Rod Scrum, master is literally hired to teach managers Scrum. In a same way like they may hire French teacher or marketing consultant.

If SM discovers that managers don't need Scrum, it is nice idea to offer them his services as regular project manager or team leader, explaining that following Scrum events without purpose is useless, and it is simply wasting time of the stuff, who can otherwise spend the 15h/month doing their work according to the orders.  You can promise to keep things in order as good team leader should

If manager will decide that they want to keep both "control and command" waterfall style of management and zombi scrum in a form of entertainment or performance without actual purpose, its fine. Its their business and their money.

But before things will get to this situation, it is professional duty of Scrum master to explain things to the management, and make the options, consequences and settings clear to them.

Basically it is simple question:

"Hello, according to my contract, its my duty as a Scrum master  to consult you(using word "teach" with own managers is not always wise) about Scrum and its implementation. So, lets please start with making things clear. What do you prefer in your firm: we actually implement real Scrum which basically means putting your traditional way of operations upside down, but has many benefits; or we can simply do thing the way they always were, but call Team leader a "scrum master" and head of sales department "product owner"?  

If the answer is the later-that's fine. Its their business, and their risks and profits(unless Scrum master is one of the owners or CEO, which is also sometimes a case).

You have your hands washed, and can happily, and may be even successfully work as a regular project manager/team leader, having monthly presentations called "Sprint review", daily status update meetings called "Daily Scrum", skipping the retrospective as waste of time, and receiving the monthly instructions and orders from the board, which will be called "Sprint planning"

You would not have to ask anyone questions about "how Scrum should be run in such situation", because yourself, and everyone else would know that what you do is not a Scrum. Is just some performance which firm decided to put on for the employees. Like a dress code or code of conduct.

That situation is alright if there is full understanding.

What is not right is being hired by a firm as a Scrum master, and then not doing it because of habit of putting superior orders above professional duties. Its like building architect who is agreeing to set up potentially dangerous feature without telling the customer about danger, or doctor who is not informing client about bad diagnosis, just to keep customer happy.

The issue of "pleasing customers feelings vs professional duty" is nothing extraordinary or exclusively related to Scrum. It exists in any skilled trade from medicine to law offices or accounting.

The way of setting up work process(which Scrum creators called "framework" for some wierd reason), managing risk and influencing value($$$$) is not a an office position that requires little or no work, no responsibility  and but usually provides an income. Not the job where pleasing the boss would be most important thing at the job.. In fact the profit or loss of the firm is heavily depended on that.

Having said this all about the profit and loss situation, this is also reason why I think it is a mistake to implement Scrum in non profit organizations. There is no motivation and logical reason to have it from the start. Usually confused Scrum masters who fill social media with questions "I can not find out what is value in my Scrum team" come from that direction.

But they to can have their own little circus and call it "Scrum" if the employers want , why not?

Nicholas, I appreciate the detailed response and although there are probably a lot of companies that hire a Scrum consultant, that has not been my experience. Usually the SM is hired as an employee and not give the authority to actually implement the change that is needed. Many times they are fresh out of "scrum school" with little to no experience. Management often has their own ideas, which seldom align with how software is actually created, so they don't enable the SM to actually do their job correctly. So the company ends up with a bastardized version of Scrum with ceremonies, Story Points, and Velocity, but no real and effective development process. Then they wonder why it takes so long for software to get completed.

I ran across this Reddit post this morning the first comment was:

"points represent complexity not time"

That sentence fuels my hatred of agile certified project managers.

There were nearly 500 comments then.

https://www.reddit.com/r/ProgrammerHumor/comments/13h0g6w/while_stuck_i…

Story points are progressively killing Scrum (especially since Atlassian pushed them into Jira's core), thus it's preferable to find a solution.

Regarding the status of Scrum within the firm, many businesses purposefully hire Scrum masters, pay top money—up to 500 Euro per day in the Benelux—and even hire Agile coaches to assist in their transformation.

While most people execute it correctly, some simply run their businesses as usual after that , with the scrum master serving as the standard team leader.

Here is my essay from February of this year about "Guerillia scrum" if you're interested in learning more about how to operate Scrum in environments where managers don't care but developers are, for whatever reason, determined to produce value through Scrum.

https://www.linkedin.com/pulse/what-guerilla-scrum-nicholas-gabrichidze/

Management loves Story Points ...

Personally, I think you are lucky. It could have been the other way round that management insists on time estimates and use those estimates as deadlines. Time duration can also be miss-used, just as easily. 

For me one advantage of story points is to abstract from the time duration component, to  focus more on complexity, amount work and risk. 

Sure there is a strong link between story points and time, and both time and story points can/should generate the same discussions, but thinking in terms of story points often allow for a better conversation in my opinion.