To add a field in TFS Agile Template or live with Defaults?

Question

What we know: Tfs allows us to manage bugs. We can add bugs and move it through different states.

What we need: We need to have different states in bug, which TFS 2015 doesn't allow out of the box, particularly

• "Not a Bug" (which is after NEW > ACTIVE and then if Developer says, its not a bug)
• "RE-Opened" (where a bug has traversed from NEW > ACTIVE > RESOLVED > CLOSED and then Re-Opened in another Release / Sprint).

Which approach mentioned below we could use ?

A- We are currently on TFS 2015. We do the customization through WITAdmin approach (https://www.visualstudio.com/en-us/docs/work/customize/add-modify-field ) and it's impact on Database, Reporting and going forward, towards migration would be another effort.

B- We migrate our TFS 2015 to TFS 2017 and get the new feature of adding our new states out of the box as per (https://www.visualstudio.com/en-us/docs/work/process/customize-process-field#add-a-custom-field)

C- We need to change our practice of logging bugs, and we need to study proper Agile Implementation through TFS, since AGILE process does have this scenario of What We need mentioned above.

---

A,B,C are the approaches, I have thought about. I would appreciate if the experts could share their experiences, thoughts and / or new approaches.

Answer 1

Approach B only exists in Visual Studio Team Service, TFS 2017 doesn't have this feature currently.

Approach A will be a good option. But you might need to modify your custom process for the wizard to run, or you might have to update your team project manually after a TFS upgrade.

Check more information of Maintenance and upgrade implications (TFS) on the website below, which tell us what should we avoid during customizations:

https://www.visualstudio.com/en-us/docs/work/customize/customize-work#maintenance-and-upgrade-implications-tfs

Answer 2

The "States" that you want to add should not be States, but at most "Reasons". You will find default reasons set that are close to what you want out of the box.

Since for the Agile Planning tools to work you need to have the same states for Bug as either User Story or Task depending on your configuration there are much wider ramifications to adding additional states. Try and avoid it.

Use A to add additional Reasons for specific transitions, and focus on C for the long term.