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

  • The answer to this question really depends on the kind of work you do & how you go about doing it. Can you elaborate on your workflow?
    – RubberDuck
    Oct 18, 2016 at 11:19
  • @RubberDuck I have edited the question to explain how we currently use it Oct 18, 2016 at 11:50

3 Answers 3


Simplicity--the art of maximizing the amount of work not done--is essential.

Ask why is is necessary to use this extra level of hierarchy. If the benefit can be defined, then the answer to your question will reveal itself.

Often this becomes a way to answer "When will feature XYZ be complete?" Since the Product Backlog is often evolving, it may not make sense to look at it in such a way.

When forced to use additional hierarchies, such as features or epics, Scrum Teams often leave items outside of this system when it makes sense. It all comes down to the purpose of adding the additional.

  • Thanks. I think your last paragraph is really what I was looking for. Oct 20, 2016 at 7:22

Are you at a high-enough level in the organization, or is your project big enough, to warrant the use of features? If features help you track and deliver work better, use them. But if they just add more clicks to your work flow and make it more complicated to report on progress, don't use them.


Strictly speaking, a Story is for that which is the smallest amount of work which still provides direct business value. This could be any number of things, such as (for software) 'improve how fast it runs', 'protect against DDS attacks', 'create of user documentation', or even 'create that report the CEO asked for'.

At that point, it becomes clear that there exist some stories which might not make sense being called 'features'.

  • Thanks, but were not using Stories yet. We basically have a bunch of backlog items, and decided we should group them under features. We are just not sure whether all PBIs should be grouped under a feature or if we can leave some parent-less Oct 17, 2016 at 14:36
  • My point still stands. If you're doing work, it should be in the backlog (never do invisible work). Not all work can feasibly be considered a 'feature'.
    – Sarov
    Oct 17, 2016 at 15:26
  • 1
    @Sarov their work is in the backlog. They're just trying to figure out if their all of their use cases should be attached to a feature.
    – RubberDuck
    Oct 29, 2016 at 10:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.