I have user stories on my User Story board. Can I group them by Feature? Please help.
As an alternative, you can add tag for the User Story, then set the tag colour to emphasize selected tags.
Another way is to add swimlanes. When you add swimlanes, you can visualize the status of work that supports different service-level classes. You can create a swimlane to represent any other dimension that supports your tracking needs.
In TFS 2015, you should be able to group your User Stories underneath Epics.
If you are not sure how Epics, features, user stories and PBIs relate to each other, I found this helpful:
https://stackoverflow.com/a/30579669/9046539
The general consensus is that:
Product backlog Item is something that can be delivered in a single sprint.
Feature is something that can't be delivered in a single sprint, but that can be delivered in a single release.
Epic is something that transcends releases.
Theme is a cross cutting concern.
Theme is generally implemented as a tag in TFS and VSTS.
Related
On my Kanban board project I have the option to add swimlanes on the Features where all the product backlog items are and another option on the Stories side.
Which would be the approach of each of them and why should be their separate use.
For example, I have on my Feature option an Expedited lane, does it make sense to leave it there or that options is more a swimlane that belongs to the Stories option?
As you can see I can set as many swimlanes I need, I found useful to have for example one swimlane per project on the Features option if I suppose to work with more than one at the same time, but in the other hand it gets me confused because I have the same option on Stories
Usually we use Product Backlog items(PBIs) to represent the work you want to develop and ship. You track bugs, tasks, and blocking issues using the bug, task, and issue WITs. To support portfolio management, teams create features and epics to view a roll up of user stories within or across teams. We usually map some PBIs under feature. The Feature could be the Parent of PBIs.
The Expedited Swinlanes could be used to both at Feature board or Stories Board to track those workitems which are urgent. For more details, you could read this document: https://www.visualstudio.com/en-us/docs/work/kanban/expedite-work#types-of-swimlanes
You create Swimlanes for each project also makes sense. In the Stories board, you could also create swimlanes the same like the Feature board to divided those workitems. But I suggest that you could create a team for each project, move those corresponding workitems to each team. Or you could create Areas for each project, using Area to distinguish them
This blog has a definition of epics in JIRA:
Epics are significantly larger bodies of work. Epics are feature-level work that encompasses many user stories. Using the above example, an epic might be the entire account management feature and the ability to see previous purchases.
So if (as a product owner) I have a large feature I want delivered that will comprise many smaller tasks and likely span sprints, then an epic is a good choice.
However, I could just as easily create a (using the example from the blog) "Account Management" component, and any task related to that feature have that component assigned.
Similarly I could also just as easily use a label of "Account_Management", and any stories/tickets that are a part of the Account Management feature simply get tagged with that label.
So my question: why/what circumstances would you use an epic? why/what circumstances would you use a component? Why/what circumstances would you use a label? Ie - all three (epics, labels, components) seem to serve very similar purposes (grouping a collection of issues), what's the difference?
With labels and components if you want to select a group of them you need to use issue search. If you are using epics you can use issue search as well, but you also get built-in functionality in JIRA Agile.
In the backlog view of a JIRA Agile board you have an Epic tab. This tab allows you to select the issues associated with individual epics. Plus it has functionality that makes it simple to add new issues to an epic. The final advantage is that the epic name is displayed brightly coloured alongside the issues in the list. This can be very useful when viewing the backlog and getting a feel for what work is coming up next.
You can see more about epics on the Atlassian Working with Epics page.
Components are useful for the technical team as they can span across many epics. A typical component might be 'database' or 'UI'. JIRA offers the option to assign work for a particular component to a particular JIRA user. For example, all issues created with a component of 'database' could be assigned to Jill Smith.
Labels are much more adaptable and they have the advantage of allowing multiple assignments (so more than one label can be associated with an issue). With labels it is very much up to you how you use them.
Epics by definition are short-lived issues when compared to the project as a whole. Components and Labels on the other hand are forever. And, you should stick to use them by their true meanings however tempting it may be otherwise.
Create Epics for features, or as mentioned by #Sateesh, for bigger stories. They should solve their purpose, and once the business need is done for, they should then be closed/done.
Components are not features. They are the technical parts of the system. They can also be used for categorizing your parts or... well, components :P... of your product.
Labels can be anything, as mentioned by #barnaby. Typically, they are keywords, catch-phrases, words people may want a task to relate to, etc. I use it mainly to make issues better searchable from a long-term perspective. There is a JIRA plugin which gives you a JIRA label cloud (for purely fancy purposes, I feel :D) that might interest you, too.
Addition:
Atlasian now have created a new article explaining this from their perspective.
https://www.atlassian.com/agile/delivery-vehicles
My opinion / usage.
Labels and Components are almost straightforward and well answered already.
Components examples
Android client app
Server API
Database
etc.....
Labels examples.
Business logic sectors (ex Orders,Invoices,Users, Products)
Code Quality Improvement
Refactor
Usability
User request/complain
Generally whatever helps categorize things.
But let me give my two cents about Epics because i find this phrase way too generic.
Epics are significantly larger bodies of work
Larger? 10 Sprints? 10 Stories? 20 Stories? or what?
Personally i would classify Epics as Goals or Major Releases.
At a Yearly / Quarter Retrospective your company holds a meeting with all members and stakeholders , and concludes to the following
We need to target more platforms (epic = Platform Expanding)
Our support personnel needs more tools to handle issues. (Enrich Support tools)
The software is too hard to use! ( Redesign UI UX)
This would mean 3 epics with set of stories to cover each of those generic requirements
Epics are bigger stories which require more than one sprint to complete. One Epic may involve several user stories. Each user story may belong to one or more Component. Say, you have an epic airline availability search. This may have multiple User stories like OW search, RT search etc., Some or all of them may involve components like cache, travel policy & booking engine.
Labels are just for convenience. It may not have physical significance.
I am filling the product backlog for a new product with user story PBIs. As I write, I realise that some PBIs are dependent on others being completed first. I cannot use the order of the backlog because it gets changed by others depending on client requirements. I want it to be obvious that one PBI depends upon another being completed first. Inter-PBI links are possible but it's not clear what a link between PBIs represents.
What is the best way to get TFS 2012 (in the cloud) using the SCRUM template to represent PBI dependencies?
Does anyone use hierarchical PBIs or tags for this purpose?
Thanks in advance.
There is a WI link type for Predecessor/Successor. This is how I typically do it. It doesn't make it super-obvious, but the information is captured somebody just has to go to the WI Links tab to see it.
I would recommend that you get all of the people competing for priority in the backlog to appoint a single Backlog Owner who understand the dependencies ( sounds like you). That person can then order the backlog taking into account both customer priority and dependency.
I have in the past added a Customer priority field to the PBI & Bug to allow the Sales\Customer Services guys to order that field to their hearts content in excel.
That way they are not interfering with your order but still providing the influential and valuable customer order.
I have a question about Microsoft Team Foundation. In Visual Studio, Team Explorer, I can create a new work item. Work item types here are dictated by your team's chosen process template; I'm not sure which process template we're using. In any case, in Team Explorer, when I want to create a new work item, I'm given a list of work item types to select from, among which are "Product Backlog Item" and "Feature".
I noticed a difference between the two types related to the target resolution date. For a Product Backlog Item, this would seem to be dictated by the iteration end date. For a Feature, it's not as clear. A Feature is also associated with an iteration (and iteration end date), however Feature also has a separate field called "Target Date". The mouse hover text for target date is "The target date for completing the feature".
Should I choose "Product Backlog Item" or "Feature" as the work item type for my new work items? What's the difference between the two?
It looks like you are using the Scrum process template. The TFS site has published some very brief information about Product Backlog Items and Features and the idea behind creating a new work item type. http://www.visualstudio.com/en-us/news/2013-jun-3-vso.aspx
The difference between the two comes down to what granularity you want to work with your work items at:
Product Backlog Items are composed of Tasks and have estimated effort.
Features are composed of Product Backlog Items and have target dates.
I have not been able to find any official guidance on when to use Features vs Product Backlog Items but I have created my own guidance which I am basing this answer on... http://www.nsilverbullet.net/2013/06/04/features-help-us-plan-work-better-in-team-foundation-service-scrum-process/
Should you create a Feature or a Product Backlog Item?
If you think/hope that the new work item that you are going to create will fit into a single sprint you should create a Product Backlog Item and then break it down into tasks for your sprint.
If you think/know that the new work item won't fit into a single sprint you should create a Feature and identify all the value-providing sprint sized items (Product Backlog Items) that the Feature can be broken down into and use these when planning future sprints.
[Update 2014-05-19]
Microsoft have published more information on how to use Features and the agile portfolio concept that has been implemented in TFS https://msdn.microsoft.com/en-us/library/dn306083(v=vs.120).aspx
As TFS applies an agile development strategy I think we can say:
Feature = Epic,
Backlog item = Story
The epic contents similar stories.
I had the same doubts as OP and my thoughts has been aligned with #josant answer, which is very reasonable to me.
On the other side I'm using the Hundhausen book[1] as a reference for adopting TFS+Scrum.
He said things like:
A feature is a discrete unit of functionality that delivers value to the user or business. A PBI may be large enough to have several features.
and then:
A feature may break down into multiple scenarios. A scenario is a narrative that describes a workflow or sequence of steps through the feature that exercises one path toward achieving an expected result.
and continues developing these ideas.
To me, Hundhausen seems to be talking about use cases[2], but still I feel his proposal some counterintuitive, neither seems TFS would be guiding to this analysis method orb I found it referenced in the scrum literature I read.
Probably it's just a matter of choosing a convention you feel more confortable with and adhere to it.
[1] http://www.amazon.es/dp/073565798X
[2] https://en.wikipedia.org/wiki/Use_case
A Feature is a Product Backlog Portfolio.
http://tfs.visualstudio.com/en-us/learn/create-your-backlog.aspx
Feature is a level up to 'backlog items'. team defines work as high-level initiatives and breaks them down into features. which further break down and define the work to be done as 'Backlog'.
ref http://msdn.microsoft.com/en-us/library/dn306083.aspx?
As others said here:
Features: Top Level
Backlogs: One Level below Features (a feature is made of backlog items)
Keep in mind that you can LINK work items and you can display them as a Tree List.
So, you can link a backlog item to a feature, and later, you can link a task to a backlog item. Thus, you get a nice hierarchical tree list.
This is how I use it. Under the tool items "Work" -> "Backlogs" both "Features" and "Backlog Items" are listed. I start with features so there are no backlog items at that point. I add the features by selecting Features under the Backlog header and adding the Feature name in the form then saving and closing. To the left of each newly added Feature there is a green + sign. Click on the plus sign and selection options appears. Choose "Product Backlog Items". When it opens type the name of the backlog item in the top field just like in Features. You are creating these backlog items, there is no pop-up. Fill in the other information as required then save and close. After creating the Backlog items click the green + on the newly created Backlog Items. Enter the name of the work item like you did for the Backlog Items and the Features. When adding the work items include the sprint in the iteration field and they will be in the sprint when you open it. None of this is documented anywhere that I could find. I hope it is in sufficient detail.
To manage the scrum development process of a big community website, we decided to move to JIRA/Greenhopper/Bonfire.
I have created elaborate Epic, Stories and Tasks, all well linked to each other.
I would like to develop the "Product Story" in more detail all the time by adding new Epics, new Stories to (new or existing) Epics, etc.
To be able to do this properly, I want to have a hierarchical overview of all issues: Epics, Stories, Tasks, etc.
Question: How do we set this up in JIRA?
Why?
=> My approach is from the point of view of project management: getting everybody aligned around the same vision. However, I think it is part for everyone in the team -especially for the ones who are actually building the product- to have a quick view of how their current or planned work fits into the big picture.
Stories have sub-tasks, which will be shown hierarchically in the Sprint, but all sub-tasks have to be completed in the sprint of the user story. I also think when you create a story you can specify an epic, which will create a hard-link ( the same as story -> sub-task). Is there a reason you want to use a Jira task? To me it looks that in a SCRUM environment you only need Epics, stories and sub-tasks. Maybe some spikes and support tickets from time to time.
Coming from a tool like Rally, I can appreciate you wanting to see the big picture. We transitioned from Rally to Greenhopper over a year ago mainly because of costs. Lets just say you get what your pay for. I haven't found the feature you're looking for in Greenhopper, it only has a single threaded view for things like Epics to Stories (on the planning page) or Stories to tasks on the (on the work page)