Skip to main content
Clarification on how we use VSO currently
Source Link

I work in a small development team, and we have recently started using TFS and visual studio online.

Up until now, we have only been using Product Backlog Items, Bugs and Tasks. We would like to start making proper use of Features.

Should all PBIs exist inside a feature, or is it okay to keep some of them "stand alone"?

I know that a lot of it is down to what works best for the individual team, but are there any guidelines or official suggestions on the topic?

Edit to clarify how we use VSO currently

We currently use visual studio online in a simple manner, up until now we have only used PBI, bugs and tasks. The primary purpose right now for us is a work log for the developers so we know what we have to do and can track our progress. We do not use it for reporting to higher management.

For example, "create a new widget" would go in as a PBI, and would have some tasks under it such as "create DB tables", "create HTML form" etc.

Similarly with bugs, "pressing this button raises an error" would go in as a bug with tasks underneath it.

This effectively gives us a pretty long list of PBIs and Bugs each sprint, and we would like to start grouping the PBIs by features. For example, we would create a feature called "Create a user account area" and put PBIs underneath it such as "Create reset password function", "Create notification settings page" etc.

The question then boils down to, is the "proper" way of using VSO to have all PBIs under such a feature, or whether its okay to keep some unparented. For example, if we had a PBI called "Log users out after 1 hour of inactivity" and we have no logical feature to put this under, should we create a new feature specifically for this (such as "Session Functionality"), create a generic feature (such as "Miscellaneous Changes") or just leave the PBI unparented.

Note these are all just examples

I work in a small development team, and we have recently started using TFS and visual studio online.

Up until now, we have only been using Product Backlog Items, Bugs and Tasks. We would like to start making proper use of Features.

Should all PBIs exist inside a feature, or is it okay to keep some of them "stand alone"?

I know that a lot of it is down to what works best for the individual team, but are there any guidelines or official suggestions on the topic?

I work in a small development team, and we have recently started using TFS and visual studio online.

Up until now, we have only been using Product Backlog Items, Bugs and Tasks. We would like to start making proper use of Features.

Should all PBIs exist inside a feature, or is it okay to keep some of them "stand alone"?

I know that a lot of it is down to what works best for the individual team, but are there any guidelines or official suggestions on the topic?

Edit to clarify how we use VSO currently

We currently use visual studio online in a simple manner, up until now we have only used PBI, bugs and tasks. The primary purpose right now for us is a work log for the developers so we know what we have to do and can track our progress. We do not use it for reporting to higher management.

For example, "create a new widget" would go in as a PBI, and would have some tasks under it such as "create DB tables", "create HTML form" etc.

Similarly with bugs, "pressing this button raises an error" would go in as a bug with tasks underneath it.

This effectively gives us a pretty long list of PBIs and Bugs each sprint, and we would like to start grouping the PBIs by features. For example, we would create a feature called "Create a user account area" and put PBIs underneath it such as "Create reset password function", "Create notification settings page" etc.

The question then boils down to, is the "proper" way of using VSO to have all PBIs under such a feature, or whether its okay to keep some unparented. For example, if we had a PBI called "Log users out after 1 hour of inactivity" and we have no logical feature to put this under, should we create a new feature specifically for this (such as "Session Functionality"), create a generic feature (such as "Miscellaneous Changes") or just leave the PBI unparented.

Note these are all just examples

Tweeted twitter.com/StackProjects/status/788151523272486912

I work in a small development team, and we have recently started using TFS and visual studio online.

Up until now, we have only been using Product Backlog Items, Bugs and Tasks. We would like to start making proper use of Features.

Should all PBIs exist inside a feature, or is it okay to keep some of them "stand alone"?

I know that a lot of it is down to what works best for the individual team, but are there any guidelines or official suggestions on the topic?

I work in a small development team, and we have recently started using TFS and visual studio online.

Up until now, we have only been using Product Backlog Items, Bugs and Tasks. We would like to start making proper use of Features.

Should all PBIs exist inside a feature, or is it okay to keep some of them "stand alone"?

I know that a lot of is down what works best for the individual team, but are there any guidelines or official suggestions on the topic?

I work in a small development team, and we have recently started using TFS and visual studio online.

Up until now, we have only been using Product Backlog Items, Bugs and Tasks. We would like to start making proper use of Features.

Should all PBIs exist inside a feature, or is it okay to keep some of them "stand alone"?

I know that a lot of it is down to what works best for the individual team, but are there any guidelines or official suggestions on the topic?

Source Link

Should all backlog items exist inside a feature?

I work in a small development team, and we have recently started using TFS and visual studio online.

Up until now, we have only been using Product Backlog Items, Bugs and Tasks. We would like to start making proper use of Features.

Should all PBIs exist inside a feature, or is it okay to keep some of them "stand alone"?

I know that a lot of is down what works best for the individual team, but are there any guidelines or official suggestions on the topic?