i am having a TFS 2012 server for managing my project
i have several sprints with same length 2weeks
Is it possible to set a whole project start and end dates ?how can you see the whole project start and end dates with all the sprints informations weather it is ongoing, finished, late.
Thanks
The sprints should be defined under a parent node. You can set this node's start and end dates just as you would the sprints.
As for seeing information about the project (i.e. whether, or not, it is on-going, finished, late, etc.), depends on which metrics you are looking for. SQL Server Reporting Services contain reports that run off both the Warehouse database and the OLAP cube that resides in Analysis services. The reports are dependent on which process template the project is based off of (Agile, Scrum, CMMI, etc.). Nonetheless, the reports will give you overview information, release burndowns, sprint burndowns, etc.
Related
My team works in a 2 week timebox and they indicate how many hrs each PBI, Task, or Bug will take via effort (if PBI) and remaining effort (if Task), and both if a bug.
As they progress through the Sprint they update their hrs. to show progress of effort.
For example, it's July 24 and John knows that updating a module will take 20 hrs. To complete and as he progresses through the Sprint he updates that number to 15, 10, 5, and then eventually 0. My goal is to show a report with that trail to verify that the 20 hrs. committed to the task was completed. I did some research and could not find much help, but perhaps I'm not stating my question right. Any advice regarding this issue would be much appreciated.
What you are looking for is more like a time tracker and generated report to verify or reflect it.
We do not have this kind of build-in feature or report in TFS server. However, as a workaround, there is a number of applications/add-on out there that expose TFS time tracking/time sheet capability.
They offer different levels of integration with TFS depending on your specific workflows/requirements. They pick up your TFS data entries and provide dashboards for operational reports as well as API to get data loaded to your systems.
Some 3rd-party extension for your reference：
7pace time tracker
SSW Time Pro
Our TFS database size was growing really quick and I figured out that the issue was with tbl_TestResult table. I am not sure why it is growing that fast. It seems there will be a record for each test case. In my case, we have more than 1000 test cases that will be fired in each check-in. That means we do average 20 check-ins a day. That is around 20,000 records.
My question is can I manually delete the records on that table? Will it make any problems to the TFs other than losing the tests results?
UPDATE:
We have TFS 2015
Deleting data manually or changing the schema in any way would result in your TFS instance no longer being supportable by Microsoft. It effectively invalidates your warranty.
In TFS 2015 you can change the Test Management retention settings in the Team Project admin page. Default is 30 days, but someone may have changed it.
Other than that this is the normal meta data that is collected as part of your ALM/DevOps platform.
**
This was "fixed" in TFS 2017 because they changed the schema for the test results https://www.visualstudio.com/en-us/news/releasenotes/tfs2017-relnotes#test. Brian Harry mentioned a 8X reduction in storage from the new schema https://blogs.msdn.microsoft.com/bharry/2016/09/26/team-foundation-server-15-rc-2-available/
I have started using TFS Integration Tools to migrate work items from one TFS2010 project to another team project within the same collection. After some small trial runs and modifications to the field and value mappings I started a migration on our entire product backlog. Approximately 170000 change groups were discovered and analyse started. However, during the analysis the connection to the TFS server was lost so the migration had to be restarted. After the restart approx 340000 change groups were identified (roughly double) without any significant changes being made to work items in the backlog.
Has anyone experienced a similar problem or are aware of settings or changes that can be made in the tool to limit this increase in change groups? The amount of time taken to analyse so many groups is causing the migration to take much longer that was initially expected.
After several runs, I found out that the count appears to be a running total so logically enough when I experienced a break in connection all change groups had to be re-analysed causing the "doubling" in change groups.
Our company has a small development team in-house but we mostly outsource our customer projects to external consulting firms which we don't manage directly. We only interact with their project manager and maybe a team lead.
I'm implementing TFS 2010 and Scrum for our internal team for Project Management, Version Control and Sharepoint shared documents access.
My problem is how to to manage the external teams.
They won't use our TFS for Version control and I can't forced them to use Scrum and report as such (report on a task level adding remaining hours).
The solution I came with is this:
Use the “MSF for Agile Software Development v5.0” template in Team Foundation Server.
Break the project into user stories and then create a task for each.
The tasks have these fields:
Original Estimate
Since we’ll track percentage of completion, this will always be 100.
Remaining
This is the percentage of remaining work.
Completed
This is the percentage of competed work.
Their team lead will update the remaining work in percentage for each user story (on the task level).
If progress is reported correctly I can print a "Stories Overview" report periodically and see the percentage complete for each user story,
I'm sure it must be a better way out there and I'll appreciate any help on getting to the right direction.
Thanks
We are basically doing the same thing ... I have 10 in-house developers and teams around the world working on their projects. Most of the work we do overlaps between external and external. We are using TFS2010. We break a piece of development into user stories into lots of tasks and eventually bugs. We view the status of the external projects by looking at the breakdown of work on the individual work items.
Part of the development process flow is to get the code into TFS source control; and the control of the logs changes as it comes back into our system.
The external PM's then use the web interface spreadsheet upload update the data on these logs (Including the time spent / work remaining) so we can see the state of the work. You don't need code upload to set a work item to test / complete.
The process flow we have on the external work is; on a given user story item you can then see the state of development for all those tasks.
List item
To Spec
Specified
Spec Agreed
Open For Work
WIP
Development Complete
External Test
Source ADded to TFS
Delivered to Internal Test
Internal Test
Complete
I'm in the process of setting up a backup plan for a Team Foundation Server. I downloaded Power Tools for TFS and I'm using the Backup Plan Wizard that was included in that pack. I am now at the step where I'm supposed to decide how to schedule the backups and I have no idea what to choose for my setup.
I get what everything means, except Transactional Backup Interval.
I would appreciate suggestions for a good schedule. What I would like to achieve is being able to restore and still look back a few versions, if possible. The minimum backup I would like to have is the latest version.
It might be important to add that I got to choose "Backup retention days" earlier and set that to 30.
The transactional backup interval likely refers to how often transaction logs for your TFS databases are backed up. The schedule you choose will probably depend on how busy your repository is.
At my current client there are six developers, and we share some of the load for source control between VSS and TFS (we're transitioning). Corporate policy says we must backup transaction logs every hour during business hours, and an additional one at midnight. Our local backups are on a four-day retention cycle with off-site backups lasting years.
I would make a decision based on how much work you'd want to lose if your repository was lost and your working copy was destroyed simultaneously (natural disaster?).