Is it possible in TFS that workitem can have two state options when created. For e.g
I have a requirement in which when bug is created it can either be DEV state or CCB state.
But I am not able to figure out the way how to do this. All I was able to do is to put one redundant initial state as "New" to start with. And from New state I can either go to DEV or I choose CCB.
Any inputs will be really appreciated.
Thanks,
Mayur
Mayur - it's not possible. You can choose a different Reason at the time of creation (eg: Build Failure, Regression, etc), but a work item only has one initial state.
Related
Is there a FREE way in JIRA to require that a parent issue can't be
advanced to a state until the children (sub-tasks) are advanced to an
equal or greater state?
FOR EXAMPLE: Suppose an issue has 4 sub-tasks: 3 in PROD state and 1 sub-task is in UAT state. I shouldn't be able to advance the main issue to PROD until that 1 sub-task is advanced to PROD first so all my sub-tasks are in PROD state. Same thing with CLOSING an issue when sub-tasks are OPEN.
There is no such specific post function out of the box from Jira but you can surely write your own plugin or Groovy script(this needs script runner plugin) which can do this job.
Simple condition like, you cannot close parent issue unless sub tasks are closed can be achieved as simple as this: https://confluence.atlassian.com/jirakb/preventing-issues-from-being-closed-while-their-sub-task-are-still-open-724928276.html
Other helpful discussions can be referred here:
https://answers.atlassian.com/questions/142131/parent-issue-needs-to-close-once-sub-task-are-closed
https://answers.atlassian.com/questions/262497/close-subtask-when-parent-is-closed
https://jamieechlin.atlassian.net/wiki/display/GRV/Post+Functions#PostFunctions-Autocloseallsubtasks
Thank you,
Yes, under the transition Conditions. Add a condition Called "Sub-Task Blocking Condition.
Then, select the statuses the sub-task requires before the parent tasks can move forward. You can select more than one, so select the statuses that are equal to or greater state. Heads up though: the selection page shows all existing statuses, not just the statuses used for that workflow.
Do this for each step you want restricted.
Is there a way to set up custom alerts on TFS? I already use the web interface to create alerts, but I need to create custom ones that are not based on work item fields only, but also on the current and past iterations. I know that Power Tools used to have an Alert Explorer in previous versions of Visual Studio, but I don't know if it would have supported what I am trying to do.
Essentially, this is what I need:
An alert that notifies users of unfinished work items assigned to them when the current iteration (sprint in my case) ends.
I know some of you might be concerned about TFS not knowing what the current sprint is, but I have used this workaround http://intellitect.com/transitioning-between-sprintsiterations-with-tfs/ so I don't believe it's an issue.
I know I could simply query for unfinished items and move them to another iteration (sprint) in Excel, but we are trying to get into the habit of getting everyone to finish their work on time, and if not, as quickly as possible, and the notifications would go a long way in helping with that.
Would there even be a way to do this via the TFS API or through the TeamFoundation PowerShell modules? I have searched extensively but I can't seem to find an answer to this question. Any help even with a work-around solution would be appreciated.
If you are trying to get people into the habit of updating their work items then this will cause you more issue than it fixes. They are not doing it because they do not see the value.
However you could write a TfsJob that sends the emails. It would need to be Scheduled job that checks to see if there is outstanding work...
This should get you started: http://blogs.msdn.com/b/chrisid/archive/2010/02/15/introducing-the-tfs-background-job-agent-and-service.aspx
However what you have is a people problem that cant be solved by tooling.
what I like is getting a job thing, whether a SQL server one or a windows service, running, then manipulate workitems by myself.
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.
I am trying to understand how to operate Team Foundation Service with scrum methodology. A problem of mine is:
I have a Product Backlog Item and five Work Items. Three Work Items are assigned to the backlog item and are displayed on the "board", so I can move them in between to do, in progress and done. Two other ones are not being displayed on board. Why? How can I assign them to the backlog to be able to see them on board?
This is not supported by the board, unfortunately. For the tasks to show up on the board, they must be a child of either a PBI or a Bug (or any work item that is in the Requirements category).
I was able to accomplish this by creating a new task, then link the backlog item to the task using the ID# as a Parent item (it also works by adding as a Child item as stated by #JamesTupper). After saving, the item showed up on my board. Hope this helps!
I have accomplished this by creating a "Project Tasks" spike to get these types of tasks to show up on the board in their own lane. You can also estimate this SPIKE, if you want to make sure this work is counted in your velocity, but I tend to treat these as "overhead" tasks that don't deliver value, so I don't report on them in our velocity.
If the tasks are related directly to the value you are delivering (for example, you are performing an investigation spike to determine how to estimate a user story) you should definitely estimate that PBI, give it points, and then add those tasks to that PBI.
Either way, adding the tasks as children of a PBI is the way to get them on the board.
If I understand your question correctly, search for the work items that you want to assign to a backlog item. Right click on the task task and then choose 'Link to an Existing Work Item'. Choose parent for the link type and make sure that you know the work item ID of the back log item and enter that in the work item ID. Press ok and then save the task item in the lower part of the web page.
That worked for me.
We are using Team Foundation Server 2010 at work and all of our assignments come from TFS tasks.
Right now I have 2 tasks that relate to the same source file. They are two separate feature requests, but I will end up writing common methods for both. I check in the code changes and link the task when I am finished with the task.
There's an issue right now though with the test database that is prohibiting me from actually finishing off on the first task and checking it in. Well the next task is on the same file.
I am curious how other people handle this issue. I know I could shelve the change and work on the other, but I kind of need some of the other methods I wrote in the first task. The body in some of these methods will be changing a little bit to handle the next feature.
Do I shelve my changes, copy my methods over and modify them for the new task? If I do that, how would the merge process work when I un-shelve my changes? How do any of you handle this issue? Am I better off just doing both tasks in the same changeset? However, now the 2nd task has a dependency on the 1st. If for some reason the database doesn't get fixed, that first task is now holding up the 2nd task from being deployed.
Thanks for your input in advance.
If both tasks are destined for the same release, work on them in the same branch, and just associate both task workitems with the checkin. If they are fundamentally separate changes, and my move to the production codebase separately, then you should have two separate branches for the code.