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.
Related
In TFS 2018, There's a need to manage versions for application that is managed as a team under a team project.
Normally such versions could be managed as iterations, each of which having its sprint children. However, it so happens that there are cases where there's an overlapping between Start Date / End Date of these versions. In such cases, while working on a current version, part of the team already works on the next version in parallel, and TFS shows only one iteration as current in the backlog screen, although in this case there are two current versions...
A solution can be to add dedicated field for VersionNo, in which the team will assign work item to version. However, since version number can be arbitrary number, it will not be reasonably possible to bind it to some predefined manageable list.
Another solution might be to use AreaPath to manage these versions, because area path is based on manageable tree definition, but that could mean using AreaPath for a purpose not intended to in TFS. Since we would like to keep compatibility with future TFS updates, is this solution ok in this manner ? Can u suggest another solution ? Kindly note TFS Release mng mechanism seems to apply to the distribution of the code but not to the versioning of it as needed above.
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.
HI i need some advice on how to set up JIRA for our team.
We have multiple Projects that have multiple items that will need to be released on their own. For example if we have project A it will have 6 items that will be developed but each item needs to be released individually. Then there can be other projects with items that also need to be released individually.
If I want to use Bamboo to release the items and create the release notes etc what is the best way to set up JIRA?
Is it possible if I used 1 project but used components with 1 item to release just 1 component?
what other options do i have?
Releases in JIRA are driven by Versions which belong to a project. This means that you can manage multiple releasable 'components' from a single project.
So for example, you could have the following versions;
COMPONENT_A-1.0
COMPONENT_A-2.0
COMPONENT_B-1.0
COMPONENT_B-2.0
Then when you allocate issues, select one of these as the fix version. When you generate release notes, or trigger a release in Bamboo you would use one of these versions for the release and it will track the issues that were assigned to it.
You can additionally use JIRA Components to pre-allocate issues to certain components if you don't like the idea of assigning them to a specific version in advance. There isn't however any way to add validation to enforce that issues from specific Components can only be allocated to certain Versions.
Note, there is also a JIRA plug-in available that adds support of component-based versioning; https://marketplace.atlassian.com/plugins/com.deniz.jira.versioning
We have recently transitioned from Gemini to TFS for application change control. There is one aspect of TFS I can't get my head around - the lack of a built-in concept of the application version that each work item will be addressed in.
In Gemini every feature request, enhancement, bug etc can be tagged with a version number. If the field was left blank, the item was "unscheduled", i.e. on the backlog. Each version could be flagged as either released or not. Reports could be then created listing the issues addressed in each released version, i.e. release notes, and the issues to be addressed in future versions, i.e. a roadmap. I was completely happy with this!
Now in TFS I can't find any built-in concept of version. It seems like there are 2 ways to represent version:
As a parent item in the iteration tree, e.g.
Version 1.0.0
Sprint 1
Sprint 2
etc
Version 1.1.0
Sprint 3
Sprint 4
etc
As a parent item in the work items tree, e.g.
Version 1.0.0
Requirement 1
Requirement 2
etc
Version 1.1.0
Requirement 3
Bug 4
etc
The latter approach looks better because it allows versions to be worked on simultaneously (e.g. a major release will be worked on at the same time as bug-fix release).
So what is the recommended approach to managing work by version?
Finally, with the version property not actually being present in the work item itself, is it possible to make reports on issues addressed in each version?
For now I am going to use iteration path to capture the version number. This doesn't lend itself so well to managing development on different versions concurrently, but we are trying to get away from that practise (i.e. be working on the next release while simultaneously working on multiple bug fixes to past releases) and adopt short release cycles, i.e. a more linear path, so maybe that is a good thing.
Earlier I though Area Path might be a good place to put Version, but its too valuable as a way to split up a huge application into parts to sacrifice for versioning.
1. Tags (TFS 2013+) are the easiest way to append metadata such as build#. (same as mentioned above.)
2. The CMMI Process Template > Requirement and Bug Work Item Types have an "Integrated In" field that links to TFS Builds for direct correlation from requirement to build# [to related code changes] [to related test cases [to related test results]]. Note you must select from retained TFS Build system builds (that have not been deleted). This hard reference drop-down limits this field significantly over time or if you use a different build system. (That and build versioning are entirely different discussions :-).) The Build CMMI template fields have been there since TFS2010.
3. Create a custom field in your User Story and Bug work items. BuildImplementedIn or similarly named field would do. Creating custom fields is not hard in TFS. You will need a Team Project Admin or possibly a TPC Admin to make the customization if you aren't already an admin.
p.s.: Sorry for the late reply. I posted this answer in case others still have the same or similar question.
You could use the area field.
We use that one for product name (we maintain multiple products) and then version goes into the description of the story, but you could use the area field for versions.
Another possibility is to use tags at the top of the Product Backlog Item.
Btw, I agree that TFS is lacking a few important fields (custom fields)
I'm a bit confussed as to the best way to handle our projects in TFS.
We are a CMMI level 3 (working on level 4) compliant organization. As such we are currently using the MSF CMMI process template in TFS, which I'm working on customizing to beter suite the needs of our organization.
With each new release (whether that be a major or point release) we have to follow a standard process that includes multiple qualtiy gates and required documentation (project plan addendums, deployment plans, qualtity gate presentation materials, requirement review documents, etc). My problem is that from what I can see, TFS only requires process to be met with each project not release (we have been trying to use iterations to identify the releases).
The question is, is there a way to have a process indicate the documents required for each release or do I need to start a new TFS project with each release.
As a potential follow on question. If you need to create a new project each for each release, how do you handle source control and work item history.
You are right that opening a new TFS project for each release is probably overkill.
Instead, I recommend creating a release plan for each release, and associating each needed document with a Work Item.
Here are some details on one way to create a release plan, and here is an example template with helpful types built in.
If you have a bunch of spare time lying around, you can customize Work Item fields to create tasks that fit your documentation requirements.
To manage multiple releases in a single TFS project, I recommend simply creating multiple folders, and adding Work Items associated with each release to each folder.