We're currently starting a new "full-Microsoft-technologies project" using the SCRUM methodology. We've benchmarked Visual Studio Online, it's just perfect for our requirements :
The only problem is, our company security policies won't allow the code to be hosted outside of our company. Also, we don't have an on-premises TFS 2013 server with an external access available yet(so the product owner can access to our project without using some internal AD account + VPN).
So the question is: is it possible to use Visual Studio Online (i.e. have access to the Internet-based portal of VSO with all the nice SCRUM features) together with an on-premises TFS 2013 Server for the source code hosting features?
No
A lot of the more advanced features of VSO/TFS require linking between work items and source control (and other artifacts). These links can only exist in one Project Collection and a project collection is bound to a server (or account in VSO).
While you will be able to manage the work in one place and store the code in another, you'll loose the integration features that give you the most value of using an integrated suite like TFS.
You have a few options though that may help to overcome this:
But be aware that you'll probably run into more issues around configuring Build, Release Management, Test Automation etc when using a split environment and syncing. Build associates work to work items and fetches sources for example. Test requires the Build Artifacts combined with the test cases.
Also note the required license requirements for setting up Team Build on premise while connected to VSO. This requires an additional TFS Server license.
You may also want to have a conversation with your security department, I understand the importance of Intellectual Property and why you want it stored securely. But remember that a Product backlog and set of product requirements (especially your future product requirements), may be considered sensitive business information, especially if you're working at a Stock-Exchange registered company. The initial assessment may be a bit off, or not considering the true value of the future specs of your application.
In the end, the source code for your system may be unprotected anyway, since a lot of .NET code can easily be decompiled, or a lot of your application may be available as Javascript libraries which are sent to the client in plain text anyway.