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.
I’ve been mulling over the same issue of work that’s too big to fit in a Sprint. I think your interpretation of features solves it for us too…
Can we have this ‘feature’ in for TFS 2012 template?
Not out-of-the-box I am afraid, but it is quite possible to create custom work items in TFS 2012 to accomplish this, although it requires a lot more work of course…
Hello,
Can a Feature WIT have a sub Feature nested ? For e.g.
FEAT-Main
FEAT-Sub Feature
I am using VS online 2013 with Scrum
Thanks in advance ?
Regards,
Mumshad
Yes you can nest Features (and User Stories) by going into the “All Links” tab on a Feature and clicking on “Link To…”, you need to know the Feature’s ID, add it as a “child”. But beware they will become grouped in the backlog display. This means you cannot have the children placed at different levels in the Feature backlog which generally causes issues with prioritisation… So usually grouping is not practical, I find adding tags better. Give related features/stories a descriptive tag, that way you can track which Features are included in the “Main” Feature and still allow moving items individually up and down in the backlog.