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.
Related
When checking in TFS under Work\Backlogs\Backlog items, any Sprint, I can see PBIs and linked tasks under them. However bugs I noticed are treated at the same level as PBIs, meaning I can never see a Bug under a PBI, but I can see a task under a Bug.
Is this because the understanding is that Bugs are an occurrence after PBIs are marked as "Done" in a future sprint (since all PBIs should have gone through testing until completely reviewed and accepted).
I'm thinking if this is the logic then Bugs in their own right are like a PBI - a new "Problem" Backlog Item lol.
We are getting confused because we at first wanted to see Bugs under PBIs or Tasks to see what the bug is associated with, but because a bug may occur from an assortment of development done in the future, it's treated as independent on the same level as a PBI. Am I understanding this correctly or is there a way to put bug under a PBI\Task in the backlog when viewing (I know you can link it as so, but I mean for viewing purposes in the backlog). Thanks.
You can configure team settings to set your team's preferences for tracking bugs.
To see Bugs under PBIs, you can select the option Bugs are managed with tasks under Working with bugs tab. See Show bugs on backlogs and boards for details.
On the board settings page, you can configure bugs display behavior.
They can be treated as Tasks, in which case they show as children of PBIs, at the same level as Tasks, and are displayed on the sprint board.
Or, they can be treated as Requirements, in which case they are shown at the same level as PBIs and can have Tasks created underneath them.
It sounds like you currently have the latter behavior enabled, but would prefer the former.
This is configurable at the Team level. You can configure one behavior or the other, but not both. This means that for a given team, bugs can either be Requirements, or they can be Tasks. They cannot be Requirements in some situations and Tasks in some others.
Also note that if you've upgraded from an earlier version of TFS, you may have to manually enable the feature, since it required some changes to the process templates that you or your TFS administrator may not have made.
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.
So we recently upgraded to TFS 2013 Update 3 from TFS 2010 SP1 and my product owners do NOT like it at all. This is because of the sparcification logic that was added (I think in Update 2). Now their backlog priorities are all messed up and they have this huge number in the billions as a priority.
To compound this, there are multiple product owners, so if product owner A prioritizes something and then product owner B prioritizes something, the backlog items get re-ordered and chaos ensues.
I was thinking maybe the answer is to use the Features work item and then a po could just map work items they care about in the order they want, but I'm not convinced this is the right answer.
I want to do well by my user base (POs, devs, etc.), but I do not know a best practice solution for this. What would you guys recommend?
After meeting with the POs, this is the solution that I have come up with. I'm going to remove the backlog priority field from the work item form (this is coming in a future update anyway). Then I'm going to add a new custom field to represent a priority which is meaningful to us. Tagging will be used in scenarios where a PO may want to call out something specific about the work item.
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.
I have setup Jira and Greenhopper and set up an initial sprint. I have mostly done scrum during my years via a whiteboard and face-to-face communication. I wonder how I should handle unplanned items using greenhopper? I don't just want to add a New Card and have it screw up the statistics. Would be nice to be able to get a figure of the ammount of unplanned work when the sprint is done. My initial guess was to add a New Card on the Task Board and tag it as an unplanned. But I don't seem to find any unplanned tag for a Card.
I've been using Greenhopper for about 1 1/2 years. It works pretty well and is invaluable to our team but isn't a substitute for post-its on the well for the daily stand-up. Over the 1.5 years, we've ended up collecting a lot of tasks, bugs, and other items in Jira that aren't immediate backlog items. Managing them is the most difficult in Greenhopper. These are the Unscheduled items.
I have these versions set up in Greenhopper:
Unscheduled: this is a holding pen for a few hundred items that we may or may not ever get around to. Some are ideas, some are bugs that we can't fix at the moment.
Unscrubbed bugs: as we find new bugs that aren't related to the current sprint's work, they go in here. Every week or so, we go through them and place them in one of the other versions.
Short Term Roadmap: stuff we'll get to soon but not in this or the next sprint.
Sprint Planning: this is the backlog we work from during planning. It's the higher priority items.
v2.3 - Sprint 2 (or whatever version/sprint we are currently working): This is the sprint backlog.
During the current sprint and before our sprint planning session, I organize the backlog and place the high priority items in Sprint Planning so we will get to them next. After the meeting, we place the items we sign up todo into the v2.3 - Sprint 2 and them manage it on a daily basis.
I think when you say 'unplanned items' you are referring to critical 'hot fix' tasks that need to be done ASAP. In my group we use a split team. We have one team that commits to the sprint. The Core Team. They are the only resource we calculate on to determine the amount of work we can do in a sprint. Another, much smaller team called the Firefighter Team is set aside to work on unplanned, critical items that, for example, might be needed in the next release.
We track these side-by-side. The Core Team is NEVER permitted to work on a hotfix item. However, the Firefighter Team is permitted to lend their skills as 'servants' to the Core Team if they do not have any critical items at the moment. Our split on one project is typically 4Core/2Firefighter. We rotate the Firefighter members each sprint, taking care not to remove someone from the next sprint that is in the middle of a big project spanning multiple sprints. So far so good. The only issue I have right now is tracking what amounts to parallel sprints in a meaningful way. I'll tackle that when it becomes a real issue.
See my feature request to Atlassian and Vote for it.
"As a Product Owner, I want new PBIs quarantined from the Backlog until I rank them"
https://jira.atlassian.com/i#browse/GHS-11139