I made a mistake in Team Foundation Server 2013 when trying to clean up our iterations. Our iteration path set up for the longest time was:
TFS PROJECT
Sprint 1
Sprint 2
...
There were discussions within the team, so I changed the Iteration path set up to this:
TFS PROJECT
Iteration Group
Sprint 1
Sprint 2
...
Readied Work
Well, after experimenting, I decided to move all the sprints under their parent Iteration Group back to the main TFS PROJECT parent. Unfortunately (this is where the mistake occurred), I deleted the Iteration Group container, thinking the Iterations would be re-parented. In doing so, all the child iterations were deleted and the work items that had been previously associated with each sprint were reallocated to the top parent, TFS PROJECT. The iteration path structure now looks like this:
TFS PROJECT
Readied Work
I have already recreated the iterations, as we did not have a backup of the project/collection to which I could have rolled back. The DBA team is hands off the TFS database, so they are not available to assist. I know how Areas/Teams/etc work in TFS, but I am not familiar with the database structure.
Given that I am able to see all the work items on the TFS portal, is there a way to show all IterationIDs each Product Backlog Item has been associated with, in a list?
I would prefer to NOT look at the history of each PBI, as there are a lot.
First, I'd strongly recommend against touching the SQL database directly.
Using the TFS API you can query work items, and you can use the 'AsOf' operator to get the state from a historical point in time. Using this it wouldn't take much work to query the area/iteration paths of all your work items from 2 days ago, and then write them back to the current work items.
As you only has a few iterations could use the 'was ever' operator. If you create a query and add a filter of IterationPath was ever '/project/group/iteration 1' you will see the work items that were ever under that node. You can then bulk edit everything you find under the desired path..
Related
We are following Scrum process and I want to calculate how many PBIs were actually considered or added during each iteration of release? For e.g. on day 1 of Iteration1 I have 10 PBIs and added 5 more till last day of Iteration 1. So I should get planned PBIs as 15, no matter how many were removed, Done or moved to backlog / next sprint.
I am able to get work items in my C# application and tried to loop through WI Revisions but I am not getting it correct.
How to achieve this either through TFS WIQL or TFS APIs?
Using TFS Cloud (myproject.visualstudio.com), there are no Estimated, Completed, Remaining fields to add time to a bug. Do we really have to create a TASK work item basically called 'fix - bugname' for every bug, just to log how long each took to fix?
I appreciate on larger bugs this makes sense, but some are spelling mistakes or other minor problems.
This then doubles the number of work items in lists for all?
any suggestions?
Well, having looked into this, the quick answer is yes.
The benefits of doing so are simple. A TASK is the 'smallest' thing you can do in TFS, and it is always assigned to one person.
Given this, by creating tasks to do the 'work', you can at least see who did the work and account for it (without looking at the history of an item).
You can also 'bounce around' the assigned to for the actual BUG, e.g. to get someone else to verify it, or leave it assigned to whoever 'owns' that bug, while fixing it can be assigned to others (the tasks).
If you are using Agile or CMMI template the bugs will not appear on the task board.
Ideally, you need to create tasks to represent the work that you or team members are doing. For instance you need to create development task for fixing the issues and a QA task for testing.
Also you should keep an eye on the statuses of the bug in parallel to the task. i.e. if the developer is working on the fix the bug should be assigned to the Developer and it should be Active and the development task also should be active as well.
Once the development work is completed the the developer can close the underlying task and Resolve the bug and assigned it to QA for testing. If everything goes well the test engineer will close the testing task and at the same time he/she should close the bug as well.
Technically yes. What we've decided to do (purely for simplicity and not to bog us down with even more user stories in TFS) is we create one user story per sprint and name it: "BUGS - SPRINT#". Under that we will have tasks that track the work/time spent on bugs.
We also name the tasks by category. For example, if there is a bug in the UI, we name it (example) UI - arrows not reappearing.
Not sure if this is the best way to do it, but it accomplishes effort tracking and keeps TFS clean.
I take it that you are using the "Microsoft Visual Studio Scrum" template. The fields in the work items vary based on the template you are using.
For bugs in the Scrum template, we usually cover the effort in the "Effort" field.
We are Using Visual Studio 2012.
This is the way we are handling this situation. We have created a user story “ Resolving, Re-testing bugs.” Every iteration developers who have to fix bugs create a ONE task for all bugs. The developer adds comments to each and every bug resolved, and update time accordingly.
QA person also adding a ONE task for the iteration for re-test bugs. QA person update his task accordingly for each and every bug.
All Developers and all QA personal create child tasks for the same user story.
Based on this answer the model for the TFS 11 burndown chart is for tasks that a children to stories.
How can I display a burndown chart of the currently opened bugs during a sprint without having to create subordinate work items for them?
The way it is intended is that you add tasks as children of the bug as soon as the bug is added to a sprint. These tasks will drive the burndown. This is the same for Product Backlog Items and it is very simple through the web ui. The estimation data in the bug itself will be represented in the release burndown.
Should you want the bug itself to function as a task, you can either:
Use a task workitem to log bugs. This is very common for bugs found for work that is ongoing in the current sprint. It's just a bit of extra work to achieve 'done'.
Update the work item definition for bug to have the proper states and fields, and add it to the task category. The process is mostly described in this question.
You should also keep in mind that bugs found for work that was done in a previous sprint should only be picked up in the current sprint during the sprint planning meeting, or when it is critical to fix it as part of the current sprint. In the first case, treat it as just any other PBI and break it down into tasks. In the second case, go fix it immediately, don't bother about the burndown, the bug is critical and should be fixed now.
We recently finished our first couple of sprints and some questions were raised to which we don't quite know the answer.
Both questions are related to: what should we do with backlog items, tasks and bugs which are not completed when the sprint ends? And how will a certain action influence a burndown or velocity chart?
If we have a 20 day sprint, my guess was that we should start on day 1, stop on day 20, leave one day for the next sprint meeting (day 21) and start the next sprint on day 22.
Let's say we have a PBI which has 3 tasks. One task is Done, one is In Progress and one was put back to To Do. The PBI has an effort of 6. If we move items in or out of the sprint during the sprint this has an influence on the Sprint Burndown and the Velocity chart. But once the sprint ended, and we move these items, does it still affect the charts? Or how should we handle such items? Should we close the PBI (set it to Done, even though it's not) or just move it and leave the tasks that were done in the previous sprint? Should we set all tasks to Done, even though some aren't? Each task has been worked on, so hours were used. We need to keep track of those, or at least, the velocity chart should still be OK.
A similar question rose for a bug. We added a Testing state, so instead of setting the state to Done, the developer sets it to Testing, so the test team knows which PBI's or bugs to test, and sets it to Done once it's completed. If a bug arises from a PBI, we close the PBI and open a bug for it. But if it's a bug, and it's not fixed, they reopen it. Either by setting it to Approved or Committed, but what happens with the efforts that were assigned to it? If the bug is not fixed when the sprint ended, should we set it to Done and open a new one, or just move it to the next sprint?
Scrum has been slightly revised and clarified over time; the latest version is more or less specified in The Scrum Guide (2011)
The Sprint Planning Meeting is part of the Sprint and it typically performed on the first day of the sprint (Day 1). Day 20 Will contain Sprint Review and Retrospective. Day 21 is actually Day 1 of the subsequent Sprint.
Regarding your question about the unfinished Product Backlog Item (PBI): Your goal is to establish a velocity for your team over time. CONSISTENCY is key to this. So most importantly, you should establish a way of doing it the same every Sprint. I see teams handle this is different ways; You need to determine if you actually delivered the Sprint Backlog Item based on what got done. If the value wasn't delivered, then you can leave it as not done and optionally update the final work on the tasks. You can also put a note in the history and/or description of the Sprint Backlog item about what was accompished and the acceptance criteria achieved. If the value of the item was delivered to some degree then you might make a similar note and count the item. You need not be exact about the points covered in the Sprint since they will average out over time, so you just need to use your judgement. Whatever is not done can be made a Product Backlog Item and prioritized accordingly. Your Product Owner may decide to put it lower on the Product backlog depending on the value of what was not finished in it. When the PBI representing the unfinished work, you will create a new set of tasks for it (you might copy the ones that were not completed from the Sprint in which they were not completed to save time). What is also important here is to discuss how things went and how you can handle this moving forward during your Sprint Review and Sprint Retrospective so your team can adjust accordingly.
Regarding the Bug, you might consider handling it similarly to the PBI for planning and prioritizing and Done / not done; your team needs a definition of done; if this includes testing, you should consider it Done only after testing. If it is not done then again you should handle that in a consistent way. Out of the box, the Scrum 1.0 version of the Bug work item has a state named Committed that indicates that the Bug is ready for testing, so you shouldn't need that testing state. Once it passes testing, it goes from Committed to the Done state. You can find the Process Guidance for the Scrum 1.0 template on the Microsoft site. It is more or less the instructions for how to work with the template.
I am working on a project that is using the Agile template with TFS 2010 and I'm trying to decide when I should assign an Iteration to a task. At the moment I have a bunch of User Stories and these User Stories have been assigned an Iteration. I've then created Tasks for each User Story and linked them.
So, my question is should I assign an Iteration to the tasks even through the User Stories have already been assigned an Iteration? And what should I do about "general" tasks that are not really associated with a User Story? For example, I could create a task that involves updating references for controls or performing a code review. Should these be assigned an Iteration and is it worthwhile managing two types of tasks, i.e. those assigned to User Stories and those that aren't?
Iteration is to be set when your team is committed to work on these tasks. If after reviewing the tasks you decide to defer some, then set the iteration to a later sprint.
An excerpt from MSF for Agile Software Development v5.0 on MSDN:
You can assign the area and iteration fields to most work items based
on a process template for Microsoft Solutions Framework (MSF). You
specify values for the area and iterations fields when you create a
work item or during a review of the product or iteration backlog. If
you defer a work item to a later time, you should change its iteration
accordingly.
And from the work item definition guide:
In the Area and Iteration lists, click the appropriate area and
iteration, or leave these fields blank to be assigned later during a
planning meeting.
Regarding the general tasks, there are special work item for this such as Issue (Agile) and Impendiment (Scrum).
You should definitely check out this resource, it's a presentation by A.Bjork that presents with a way to deal with what you 're after.We tend to assign UserStories to future Iterations, and before an iteration starts, at the time 'planning poker' takes place - we generate & assign the Tasks to the team.Doing so is vital, for TFS to keep a proper tracking of your efforts: the only Work Item where 'hours' are inserted is the type 'Task' - so this is what feeds the Burndown charts that show how effective you work. If you add another Task to a team-member during the sprint, that would be perceived as 'unplanned work' by TFS (simulating an interruption!) and will mess up the calculations for your Team's velocity.Try breaking your long-running Tasks into smaller ones, that shall fit into each sprint. At worst, for example if you have a huge refactoring Task, you can make several child-Tasks assigned to each sprint and then have the umbrella-Task assigned to the last iteration - where your refactoring is completed.Apart from time-tracking (which is solely based on Tasks) you need to also add into your iteration backlog all other work items that are important for the sprint, so you 'll be able to track in the future when each Issue, User Story etc was considered.