Using Visual Studio Team Services (Online version), I would like to have a simple display for my "Backlog" and "Board" :
Features
Tasks
Bugs
That's pretty much it. I don't want to do anything with, iterations, sprints, user stories, etc.
This is just a one man project and I'm just wanting to see all thing on the backlog/board so I can better manage the project.
EDIT:
Biggest issue I had with this...
My project was setup to use the "Agile" process. I decided to try Scrum process instead and found this to be the deciding factor.
Once a project is set as Agile/Scrum, it cannot be cahnged... So, I Made a copy of "Scrum" process, named it "Scrum_custom", created a new project using this method, then just git pushed my existing project code to the new one.
I marked Daniel Mann's answer as correct seeing as it's what I ended up doing after changing to Scrum and it seems to be working just as I'd hoped!
Just in case anyone else reads this and is looking to do something similar, I would recommend this route...
Under your team configuration, you can change the backlog levels you use. In your case, you want to turn off PBI/User Story.
https://www.visualstudio.com/en-us/docs/work/customize/select-backlog-navigation-levels
Alternately, you could just use PBI/user story instead of Feature. They're the same basic thing except with different names; it's purely a hierarchy thing:
Epic -1 to many-> Features -1 to many-> PBIs -1 to many-> Tasks
Bug behavior is configurable; they can either be treated as requirements (at the same level as a PBI) or as tasks.
If you link Task and Bug to Feature as child, you can manage them in Feature Backlog, but not Kanban board.
To link them as child, you can open a work item > Links> Add link>New Item>Select Child link type.
Related
We are using TFS 2015 together with the CMMI process template and I have just found out that Issues do appear on the backlog if they are a child of a Feature or a Requirement work item type. If the Issue is standalone (has not link to one of the two mentioned work item types) it is not visible on the backlog.
I guess that someone has made some hacks here in order to make this possible. Originally, only Epics, Features, Requirements, Tasks, and Bugs should appear on the backlog.
I have checked the Issue work item type definition as well as the processconfiguration.xml and the categories.xml which look quite ok from my point of view.
Are there any another places where one could define which work item types should be visible on the backlog?
Thanks a lot for giving support.
To add a WIT on backlog, the three files below need to updated:
WIT Definition
Categories Definition
ProcessConfiguration Definition
You can check the required changes on this link: Add work item types to backlogs and boards to see if these changes had been applied on your project. If yes, revert these changes, then the Issue should disappear from the backlog.
You should not use the "child" link to associate with Issues.
The Parent/Child link is used for the backlog and I would think that the Issues are appearing because of this.
Try changing the Parent/Child link to Related.
My team is just now starting to use TFS 2015 Update 1 on premise to manage their development process. I have set up the server and defined some custom states and transitions for work items to better map to our process. To start with, we will only be taking advantage of the Kanban board and are not attempting to use iterations for a variety of reasons I won't get into here.
My problem currently is using TFS to plan releases. Specifically, I don't see any way to group Features and User Stories into a specific release. All of my googling has turned up many articles involving Microsoft Release Management, so I installed and configured it, but it is absolutely overkill for what my team is trying to do right now. I'm not trying to automate deployments to different environments at the moment, I just need a way to group work items into a something that encapsulates the concept of a release in TFS. Is there no way to do this? The best I can come up with right now is to further modify the work item templates to either provide a simple "Release" field with a pick list, or define another type of work item that I can group the others into. This seems like a glaring oversight by MS from my perspective, so I'm hoping I'm just missing something.
Grouping work into releases can be done in a couple of ways, just remember that the concept of a "Release Plan" doesn't explicitly exist in TFS. Release management covers the "Release to Production", but doesn't cover any planning.
Ways to plan releases:
One way is to create a Release Iteration, this works when you're not working on multiple releases in parallel and truly finish one release before working on the next. The Release iteration used to be default, but has been removed from the product in favor of teams delivering sprints and teams doing continuous delivery.
Project Root
+ Release 1.2
+ Sprint 1
+ Sprint 2
Another option is to use Tags. You could tag work items with a tag that signifies it's targeted for a specific sprint.
Use a Marker workitem, on the backlog place one work item which clearly stands out ### END OF RELEASE 1 ### Any workitem below it is not part of that release. This technique fits a more agile way of working and more clearly shows that the contents of a release are a floating thing.
Create a custom Release Workitem, link your other workitems to this work item to target it for that release.
And your option to create a picklist on a *Custom workitem field** is another option.
Alternatively you could also use the Area Path in much the same way as Iteration Path. By using the Area Path you have the benefit of not having a sprint tied to one specific release.
It is not the best solution but could be the solution in some cases.
Answering solely based on your question around planning releases, then:
Create a custom work item template, called 'Deployment'.
When planning of a release begins, create a new 'Deployment', let's say, called 'MyProduct v1.1'.
In your planning meeting, create Features and User Stories appropriately, and create a relation to the 'MyProduct v1.1' Deployment, by opening the User Story and adding a Link (using the Deployment Work Item number) as 'Related'.
To monitor Deployments, create a custom Work Item query targeting the new 'Deployment' Work Item template. You can configure this to display on your dashboard.
Follow whatever release procedure you like based on the 'Deployment' and its' relations.
You should follow a naming convention when creating 'Deployments' for consistency.
p.s. I recommend using the extension 'Work Item Visualization' in this instance. It'll nicely map out the 'Deployment' related Work Items.
If you want to use TFS to actually build an and create a Release, then Release Manager is worth considering.
TFS 2015 Update 2.1 now includes a built-in version of Release Manager. It's much more user-friendly and simple to configure when compared to Release Manager standalone installations.
To group work items into a 'release', you can do the following:
Create a build definition for the repository you're working with - see Build Def creation docs
Create a Release definition - see Release Def creation docs
Once you have these definitions created, the working process would be:
Developers work against work items
Commits are made against the WI number (or tasks)
When it's time to create a release, start a build on the definition you created. In doing so, WIs will then be associated with a Build Number.
When the build succeeds, start a new Release from the definition you created.
You have have a set of work items associated with a release, see screenshot:
Note: You can enable CI builds and releases, although the above is based on manual triggers.
You can also directly call the Release API to locate WIs associated with Releases, however you'll need to obtain the actual Id of the release first.
You are currently limited however to viewing these relationships based on knowing the Release. In a real world scenario, it's more realistic to look at a Work Item to see when it was release. To do that, there's no built-in functionality at present, however my own-answered question will guide you - see here.
Additional to the methods explained by jessehouwing there exists also several 3rd party tools which can integrate with TFS/VSTS and provide advanced planning features. See VSTS Marketplace for an overview.
In our current project we have four different TFS2010 Team Projects in the same Team Project Collection. The reason for this is that different parts of the project wanted to use different team project templates (CMMI vs Agile).
All projects now use the same template. Therefore we have now reached the conclusion that it would be better to merge the projects into a single team project. This raises several questions:
Is it possible / feasible to use one of the existing projects as the target project for the other three?
How do we move our existing work items into the new project whilst maintaining our area tree? We hope to create one root area for each of our existing team projects, and move all work items / areas underneath this root node.
Today we have work item links from one team projects into another - how do we keep these links when merging?
What is the best practice when moving the source code? One clear approach is to simply copy it to the new location, and locking and keeping the old team projects in case we need to access older versions of the code. But is it feasible to use branching for this, e.g. branching all existing code to the new team project? What kind of problems might this approach cause?
Thanks for your help!
Unfortunately, TFS 2010 doesn't allow you to merge team projects.
Stucturing Team Projects and Team Project Collections is one of the most important strategy decisions to make before starting to use TFS. Unfortunately, a lot of the customers we help don't make the up-front planning necessary and don't understand some of the limitations in TFS around merging, moving, splitting, etc. team projects before they start diving in to using TFS :(
When we have consulting engagements where customers want to consolidate their team projects, we end up having to do a lot of manual work to migrate the artifacts. We have built some tools to help us with this process for work items but for the most part it's a lot of tedious consulting work. The migration utilities always end up needing to be customized for each customer as well since they usually have different business rules for how they want to migrate.
Ultimately, a "migration" doesn't end up bringing over all of the information and you end up with some other problems like date/time stamps being different from what they were originally. (I have heard it referred to as a time compression issue with migrations.)
Some additional thoughts for each of your original questions:
Sure, you could theoretically use one of the existing team projects as the target for the migration of the other three. As long as you like the team project name and don't want to rename the team project. :)
This is where we have built custom work item migration utilities to assist our consulting customers. You would likely need to do the same.
This is possible as well with a custom work item migration utility. You can just keep track of the mappings between old work item IDs and new work item IDs and then add the links later once all of the new work items are created in the target team project.
That's ultimately up to you. I would do a "move" version control operation on the source code from the old team project to the new team project. This maintains everything. However, I would not delete any of the old team projects because that will cause the version control history to be destroyed as well.
It's not the best story for you but hopefully it will help your planning out some!
What is the best way to create a completely new project in TFS by copying an existing one?
I have an ASP.NET project that will have 50+ "releases" per year. Each release is a distinct entity that needs to remain independent of all others. Once created, I want to make sure that any change to one (the source project or the copy) does not affect the other.
This is for source control only. I do not need to copy any work items.
In the pre-TFS world I would do this by simply copying the folder that contained all of the project files. This had me 90% of the way to the new app, which I could then tailor for the new release. It is very rare that I need to actually add functionality to the base application, and even when I do it never affects existing apps. Is this still possible using TFS, by copying my local folders and then adding the copy into TFS as a new project?
Any suggestions? One branch per release looks like the "standard" way of doing this but I will quickly end up with dozens of branches that really aren't related, and I'd rather keep each new project as it's own distinct project, with no chance of changes in one affecting the other.
Thanks!
Thanks for the responses. I think you've all given me enough insight to get started. Richard, thanks for the detail. I was a bit concerned that it might be too easy to accidentally merge the branches.
There are really two questions here:
1) Is it better to copy/paste or branch?
I'd venture to say that copy/paste is never appropriate. Unless you are very careful (at minimum, run 'tfpt treeclean' immediately before copying), it's likely you'll end up checking in some inappropriate files to the new location. In addition, you will be using up FAR more disk space on the server, since it must store 50+ full copies instead of just diffs.
There is virtually no danger that branches will "accidentally" become comingled down the line. Merging branches back together involves at least 3 deliberate steps: pend the merge (itself a 4-page wizard), then resolve all conflicts, then checkin.
Nor are you likely to get confused as to your place in the tree. TFS uses "path space" branching. That means branches appear to the user as separate physical locations in the source tree, rather than mere version-tags on top of the same path. Since branches look like folders, you can do all the normal folder operations on them: Cloak (don't download them to your local workspace), Permission (in particular, removing someone's Read permission will ensure they can't even see it), Delete or Destroy (when you're truly done with them).
2) When is it appropriate to create a new Team Project?
This is a more complex topic in general. Official guidance. My opinion.
However, I'd say your case is easy: don't do it. Team Projects have a lot of overhead. There is a finite number you can create on a server...ever. Don't forget about other forms of overhead too, like the time it takes for the project admin to port over all your settings, and the time every developer on your team spends reconnecting his Team Explorer.
All for what? The links above go into great detail about the forms of sub-structure that can be created inside a single Team Project. In short, almost anything is possible. The only areas that are somewhat lacking are Team Queries and Build Definitions, which are restricted to a single container folder, and a few settings like Exclusive Checkout which are all-or-nothing. Unless you have a very large or very diverse team, the benefits of separate team projects per release are very unlikely to outweigh the drawbacks.
Of course, if a "release" is a major event that signals a change in your SCM practices , that's a whole other story. New SCM => new process template => new team project. But I doubt you do that 50+ times a year :)
I would recommend using branching. Create a branch for each release from the main branch. As long as you do not merge the branches they will remain independent. Changes to the main branch will only affect releases created after the those changes were made.
You could copy the files and create a new project, but you may run into a couple of problems:
The projects "remember" that they were in TFS, there is a bit of manual work to clean up special files etc.
TFS may slow down when you have many projects, compared with a single project with branches
This might sound obvious but you should only create a new project for a "new project". It sounds like what you are talking about are different versions of the same project.
If you want to maintain separate codebases for previous releases then as the other answerers have said, branching the code is your best option. This works nicely when you want to merge bug fixes from your latest version into older releases too.
However if you really really must have new projects, you still use branching in the same manner.
In Team Foundation Server is there a way to have work items in one project linked to other projects so they show up in the reports in both. We are thinking about keeping release engineering items in their own project and want them linked to the project they are actaully for as well. Is this possible? So for instance I would create the item under release engineering assign it to an engineer and then link it to Product X so it showed up as a work item for Project X as well.
This is possible in TFS 2010 at least: link tfs work item to different project
Not sure on the effects on reporting though.
Not out of the box as projects are discrete. However there is nothing to stop you from writing against the API to fulfill this need, although this would take some considerable work.
Now for the good news. If you keep your eyes here, you may find the answer in time. As I see cross project reports are planned in Rosario