【原文：http://www.nsilverbullet.net/2013/06/04/features-help-us-plan-work-better-in-team-foundation-service-scrum-process/】
Recently a new work item type named “Feature” popped up in the web UI for Team Foundation Service in both the Scrum and generic Agile process templates. Unfortunately it was not included in any of the backlogs or standard queries by default and I have been experimenting with using it for solving some issues we have been having with longer term planning and the Scrum process template and I believe I have found a good way to use them.
Looking for guidelines on how Microsoft have intended it to be used has not uncovered anything… there is no information available about it in the TFS (server) Scrum process guidance. Yesterday a new post was published on Microsofts TFS site detailing that it exists and that a new backlog has been added to display and manage features but no guidance.
This is my own guidance for when to use Features and Product Backlog Items.
Product Backlog Items represent work that can be completed within one sprint (like user stories) they are broken down into the tasks that need to be done to complete the work. PBIs are estimated to enable planning & forecasting using our velocity.
If you think that the work can be completed in a single sprint it is a Product Backlog Item.
Features represent work that cannot be completed within one sprint and instead will run over a longer period of time before it is complete (like epics). They are broken down into Product Backlog Items that we hope will fit into a single sprint. Features are not estimated as they are by definition large and unwieldily, instead they have a target date to help prioritise and plan releases over time. Features are not used in sprint planning as they are too big – only the Features children in the form of Product Backlog Items are used for sprint planning and forecasting.
If you think or know that the work cannot be completed in a single sprint then it is a Feature.
Tags – There is one more tool that has been crucial for us while working with our backlog in Team Foundation Service. Tags! Tags can be used for cross-cutting feature categorisation (like themes) or for just general indications as to what a Product Backlog Item or Feature relates to. We have been experimenting with Tags to indicate all kinds of different things but have generally landed in the following:
- Epics (before Features became available) we tagged anything that was big and should be broken down
- Skill-set required to work on an item (UX, UI, DB etc)
- General categorisation to illustrate what in the mobile app the item will affect (Map, Contact, Start screen etc)
Update: I have also answered a question on StackOverflow about this read it here.