I like @sarov's answer, and just wanted to add some TFS related bumph in realted to the Scrum bumph, maybe with a little extra Scrum bumph.
Investors require dates of high level estimates for certain
milestones. For example, when should we expect a MVP (minimum viable
product) to be ready. However, only tasks can be measured in hours.
How can I provide the investors with a good set of proposed milestone
dates in this case?
(scrum theory) This is something that is totally within the purview of the Product Owner and does not belong in TFS. TFS is an effort tracking system rather than a time tracking system.
(scrum practice) If you are planning in Scrum then one good practice is to have your Development Team estimate each of your backlog items in relative sizes based on numerical points. While your Development Team can use those point to help them decide how much work to forecast for the next Sprint, your Product Owner can use them to forecast multiple Sprints and when some of their milestones might be hit.
(tfs/vsts) I would try to get your Product Owner some training in how to monitor value. There are good training courses from both Scrum.org and the Scrum Alliance. If you are using VSTS (cloud TFS) then you get the Delivery Plan (https://marketplace.visualstudio.com/items?itemName=ms.vss-plans) extension that will allow you to easily and visually plan for future sprints, but its still not about hours.
(scrum theory) Ultimately if anyone is giving guarantees to your investors then you are not respecting them. It is fundamentally imposible to determine up front how long a backlog item will take to deliver and when it will be available. Make sure that you focus on forecasts, not exatimates.
I was told that Ideally, we should NOT use EPICS to represent a
release. But since I see no other viable way of achieving this in TFS,
I created an Epic called 'Minimum Viable Product' and added the
features we want there. Thoughts?
(scrum theory) The Scrum guide does not talk about Epics or Features because they are all just Backlog Items...
(scrum practice) There are many ways to organise your work and it is up to you how. However a common practice is that Epics, Features, and Backlog Items all represent the same thing just with varying degrees of granularity. Since they are all in the execution flow they all need to represent the value delivered to the customer.
(tfs/vsts) There are no hard rules here, however TFS has an out-of-the-box method for managing time based predictions. You will already have Sprints in the Area Path and since it is hierarchical you can add many levels. A common method is:
\Release 1\
\Release 1\Sprint 1
\Release 1\Sprint 2
\Release 1\Sprint 3
\Release 1\Sprint 4
\Release 2\
\Release 2\Sprint 5
\Release 2\Sprint 6
\Release 2\Sprint 7
Since you can point "Teams" at a particular set of paths you can create an additional team and point it at Releases, giving your Product Owner a high level planning feature. I created a pretty detailed post on how to configure it: https://nkdagility.com/creating-nested-teams-visual-studio-alm/
Finally, I got contradicting opinions on whether operational aspects
of the product development should be included in TFS or not. Things
such as 'decide on framework', 'set-up development environment', etc.
One Scrum Master tells me we should NOT do this because Scrum should
only list product deliverable, while the other told me told me that it
is obvious that these things should be there as we need to account
them in the product development.
(scrum theory) Your Product Owner is accountable for the Product Backlog, its contents, and everyone's understanding of it. With that in mind it may, or may not make sense to have these items in the Backlog depending on your Team, your Product, or your company.
(scrum practice) Many Scrum Teams will put clearly marked 'architectural' or 'infrastructure' items into the Product Backlog to make sure that things are not forgotten. [this practice comes from SAFe]
(tfs/vsts) From TFS 2015 there is an additional field on every execution work item (Epic, Feature, & Backlog Item) that is a dropdown list with the values of "Business" and "Architectural".
(scrum practice) A conflicting good practice is to never put anything that your stakeholders would not understand in the Product Backlog.
(warning) Whatever you choose make sure that you can transparently represent technical debt transparently.