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.
Related
My team is asking me to add all these states in the PBI workflow.
New,
Prioritization,
Design,
Business Review,
IT Review,
Approved,
Committed,
In Development,
Development Done,
QA Testing,
Ready for UAT,
Released to UAT,
UAT Testing,
Available in UAT,
Ready for Production,
Released,
Reopen,
Resolved.
I know that we can accomplish the same by using Tasks or Reason field and we have to keep the workflow "Simple" but my team is insisting to track that using a single field (State) so that it is clear. I would like to know if it is a good idea.
I appreciate your thoughts and feedback.
We can't say how many states are reasonable or best. TFS is extensible and customizable, it is designed for customers will be able to meet the needs of the organization.
But as we know, the more states you define, the more transitions you must define. The maintenance and further upgrades will be more complex. Changing the workflow states of work items, specifically those in the task and requirement category can cause unexpected challenges in existing functionality as well as future upgrades. Changing to requirement types (Product Backlog Items and Bugs for Scrum, User Stories for Agile and Requirements for CMMI) will require modification of the Agile or Kanban board. They will also most certainly prevent an automatic easy template upgrade.
Customization should be well-thought out, instead of changing the existing State field, you may consider add a new "customStatus" field which won't impact existing reports and upgrades.
A good blog for your reference: http://blog.nwcadence.com/tfs-customization-pitfalls-payoffs/
This is another option for you to think about but you don't necessarily need to amend the states. You could use Board Columns which can be set on the Kanban board. With each column, you can optionally choose to split containing a Doing and a Done which could mean you require less states.
You can then query on Board Column instead of State
I was in a similar scenario to you when setting up our TFS (although not with as many states requested!) and I ended up going with Board Columns. Here is ours, it seems to work for us:
All of these have no split with the exception of In Development because when development is done it is not necessarily ready for test.
This functionality came with TFS 2015 Update 1 so you would need to upgrade if you're not on that version.
Here is how we use each state:
New - New PBI or Bug
Approved - Confirmed the work will be done and complies with the DOR (Definition of Ready)... (Contains enough info, priority assigned, tasks created, test plan created etc)
Committed - Assigned to a future sprint
In Development - Contains a Doing and a Done
In Test - QA
Ready for Release - Signed off and ready for release
Done - Released and DOD (Definition of Done) has been completed.
We're still fine-tuning our ALM process using TFS 2015 Update 1 On-Prem. We are using the standard SCRUM template and we display bugs on the backlog, along with requirements. Bugs are reported by the business and go through the same level of analysis as PBIs in that they will contain child tasks:
Now for PBIs, when a tester is testing the PBI and discovers a bug with it (which needs to be fixed as part of this sprint), they will create a bug as a child to the PBI. This keeps them together on the task board. 1 PBI may have many bugs and these may be worked on by different people. These child bugs will have child tasks.
The process mostly works but on the Kanban board, the child bugs are shown, the parent PBIs are not. Why not? and how can I work-around this? I can link them differently but we want them to stay together on the boards.
Thanks
It feels like you're really mixing and matching the two supported scenarios here.
Personally I prefer not to create Bugs as part of the sprint (to me they're not really bugs if they haven't made it out of the iteration) and often it's used as a communication mechanism instead of dev & test working closely together.
If you want something on the board under the PBI/Bug, you could use a Task Work Item (or a custom type) and then use the funky card colouring on the board to look for a tag to signify that it's an in-sprint bug/issue.
Highlight work items based on custom criteria
We are using the scrum template for TFS 2013. Product Backlog Items and Bugs are at the same 'level', so they are both viewed on the backlog and tasks are created as children underneath. Why do PBIs have the states: New, Approved, Committed, Done, Removed, while Bugs have the states: New, In Progress, Done, Closed (which is the same as tasks)?
By treating PBIs and Bugs essentially the same, I would expect that they should have the same states. I'm not sure what 'Done' is supposed to mean as opposed to 'Closed'. I find it confusing that tasks and bugs can be marked 'Done', which is not the same as a PBI marked 'Done'.
I want to change the names of the states for the the PBIs, bugs, and/or tasks to use more consistent naming conventions, but I think I may be misunderstanding what the terms mean.
As Cece mentioned, the out of the box states in Scrum between PBI and Bug are similar. You can use witadmin to change the states of your Bug work item type to match PBIs.
Another option is to use the Kanban board, where you can create a set of columns and map each column to a state of each work item type.
I'm afraid your Scrum Process Template has been customized before. In the default Scrum process template of TFS 2013, PBI and Bug do have the same states: New, Approved, Committed, Done, Removed, while Task has the states: To Do, In Progress, Done, Removed.
The following diagrams show the typical forward progression of PBI, Bug, and Task work items used to track work and code defects for TFS default Scrum process templates:
PBI:
Bug:
Task:
In TFS 2013, for every work item (product backlog item, bug etc.) a task has to be created. So every time a bug is created or a backlog item is added, at least one additional linked task needs to be created.
This makes it quite cumbersome to maintain the system. Is there a way to just create one work item that goes from the backlog to being developed to being tested without having to create additional tasks?
Maybe this could be done via a different process template? I’ve tried both scrum and agile build in templates from Microsoft.
There is a new article on MSDN that addresses this, at least for bugs. It shows how to make bugs act as tasks in TFS. You could theoretically expand it for any work item (although I'm not sure this is advisable).
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