Should all backlog items exist inside a feature?

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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'.