We have recently started to use TFS and are using the MSF for Agile v5.0 Template. Tasks that I have created seem to only have 2 states. Active and Closed. In reading the documentation that I have found ... it shows that there should also be a "Resolved" state so that when developers are finished they can mark it Resolved and then once the task is tested it can be marked Closed.
Can somebody help me understand what I'm missing? Is there a step I'm missing in the process?
You didn't use the right Process Template, only MSF Agile for CMMI Improvement has the resolved state, MSF Agile Software Development only has Active and Closed in the version 5.0.
You did have the Resolved state in the version 4.0 though.
Assaf Stone's answer is an accurate solution for part of the question I asked, but I understand now that I really was "Missing" something.
After spending time with TFS, I figured out why they removed the "Resolved" state from Task. A task should be linked to a user story and As a user story is where the testing or next step would be. A task does not need a "Resolved" state.
Now if you wanted to add an additional step for a task such as "Code Review" that would be valid but there is not a need for "Resolved" on the Task itself.
It's true, but you can easily copy the workflow from the user story WIT definition. just export the two with witadmin, and copy the workflow from the user story to the task.
Related
Currently the links tab of a PBI (or BUG) shows the commits as well as the pull requests but I would like to see the build in which those commits were included as well as the releases of that build (when it was released and to which Server)
In short, is there any way to configure TFS to see the build and release details from within the PBI/BUG Details page?
Currently our approach to find out whether a specific PBI has already been deployed, is to start from the Build and Release menu and to click through all recent releases and their builds until we find the PBI we are interested in. That is not an efficient Approach.
I found this and consider it as the answer to my question.
https://blogs.msdn.microsoft.com/devops/2017/08/25/automatic-linking-work-items-to-builds/
I have created a new project in VSTS (Visual Studio Online) using the Agile Template.
I have created a sprint, and added a user-story. Within the user-story I have some tasks.
On the sprint Kanban board there are 4 columns;
New
Active
Resolved
Closed
I can move tasks from New to Active, but cannot move them from Active to Resolved.
How do I do this?
This confusing behavior is because the Agile Template shows both Bugs and Tasks on the same board view. While Tasks have a New -> Active -> Closed workflow, bugs have an additional Resolved step.
Your task should transition directly from Active to Closed.
You bugs will be able to rest a bit in the Resolved column before being dragged all the way to Closed.
To recall your question:
I can move tasks from New to Active, but cannot move them from Active to Resolved.
This is also not a problem in Azure DevOps but the standard process (Agile workflow states). The following are the steps that can be used for the workflow in the standard process:
User Story (New, Active, Removed, Resolved, Closed)
Bug (New, Active, Resolved, Closed)
Task (New, Active, Removed, Closed)
In Azure DevOps, however, this workflow can be adapted. For this the process must be modified. Here you can also add Resolved for a task within the workflow. Role "Collection administrator" is needed.
via Organization settings / Boards / Process / Agile (default) ... Create inherited process
Further information and picture source under https://learn.microsoft.com/en-us/azure/devops/boards/work-items/guidance/agile-process-workflow?view=vsts
and https://learn.microsoft.com/de-de/azure/devops/organizations/settings/work/manage-process?view=vsts&tabs=new-nav#create-inherited-process
You need to first create an inherited Process from Agile template as explained here:
https://www.visualstudio.com/en-us/docs/work/process/manage-process#create-inherited-process
Then , you can simple Hide the "Resolved" state for Bugs from your workflow as shown here:
https://www.visualstudio.com/en-us/docs/work/process/customize-process-workflow
That's it! the column is gone from your Task Board!
Moreover: you can now add your own States and Columns.
Good luck!
Michael
We started using TFS 2013 as bug tracker some time ago (about 3 months). Before this we used TFS only as source control (bug tracking was performed in another software). For now we have developed some processes. We would greatly appreciate any comments, that would help us to understand, whether this processes are right, or not. So, here they are:
General info:
We are developing one big product.
Our team has 5 developers and 2 QA's.
Often we release new versions each 1-2 months.
We have 1-week sprints.
This is how we use TFS:
We have one team project and a number of areas in it. Each area represents some part of the product.
Our team project uses Scrum 2.2 template.
In the team project we create a "big" iteration for each release (e.g. "Release 01.2014", "Release 03.2014"), which starts from the end of previous iteration and lasts 1-2 months.
We use 2 standard work item types: Tasks and Bugs
All bugs and tasks belong to the appropriate "big" iteration and area.
We use tasks in 2 ways: as a standalone work item for any improvements and new features, and as the child of a bug when fixing a bug.
To monitor current situation we created a bunch of queries for TWA. Some of them are shared (Such as "Bugs new","Bugs for testing", "Tasks in progress" and others), and some of them are created by each dev/QA (e.g. "My tasks in progress", "My bugs done" and others).
Here goes work process description for Bug:
-->QA (or dev) creates a bug (State: New)
-->QA (or dev) assigns this bug to some dev (State: Approved)
-->When dev starts to fix a bug, he does the following:
---->changes state of bug to Committed
---->creates child task and changes its state to InProgress
-->When dev commits some code, that should fix the bug, he bounds checkin to task (created on previous step)
-->QA understands, that bug is fixed and ready for testing, when bug is in Committed state and EACH child task is in Done state
-->QA tests fixing of bug:
---->if bug is not fixed he changes state of bug to Approved
---->if bug is fixed he changes state of bug to Done
This process looks not bad, and somehow works. But there is a problem with standalone tasks, which is created for improvements and new features.
And here goes process description for standalone Task:
-->QA (or dev) creates a task (State: ToDo)
-->QA (or dev) assigns this task to some dev (State: ToDo)
-->When dev starts working on this task, he changes its state to InProgress
-->When dev has finished working on task, he changes its state to Done
-->QA tests this task:
---->if new features work fine ?
---->if new features work with errors ?
Here is the main problem: how can QA mark Task as passed or not passed the tests?
How we resolved it for now: QA's marks tested tasks with tag "Closed", if all is ok, and creates child bugs for task if there are some errors.
But working with tags this way seems not to be good.
EDIT One more question: Which state of Bug/PBI is most suitable for state, when bug was assigned to developer, but he did not started working on this bug yet?
Any comments and suggestions will be greatly appreciated.
You are not using the Scrum template as intended.
The typical approach is to use Product Backlog Items to represent features, and child Tasks to represent the work necessary for PBI's or Bugs.
Teams will often have one (or more) tasks that represent the testing work that needs to be performed for each PBI/Bug. Then you can track if testing is done or not by looking at the status of the tasks.
Maybe more work/overhead than you're interested in investing, but have you looked in to using the "Test Case" workitem type? A couple fancy things about Test Cases:
They can be attached to a Task to specify the task is "Tested by" that test case
They can have results, making the definition of the test reusable across iterations
There's a bunch of built-in reporting for showing what the current status of testing is (passed vs failed vs not run, etc)
There's even UI for entering test results and managing test cases in the TFS web interface
Tests don't have to be automated, but it's nice if they are. You'd get all the above benefits even if you're only using "Manual" tests
More info here: http://msdn.microsoft.com/en-us/library/dd380763.aspx
We want to create a defect/task in Jira automatically for a failed build in Bamboo. And need to assign this defect to the person who broke the build.
How to do these two things?
Thanks.
There is an open JIRA issue regarding this -- BAM-2537 -- watch it, vote for it - maybe they'll add it to the product.
The comments from Top 5 Reasons Creating JIRA Issues from Bamboo Makes Your Team Awesome-r also discuss what you're after.
Have a look at Atlassian CLI. There's already a good answer on StackOverflow.
Can Bamboo change status of tickets in JIRA
This is not "out of the box" solution, of course, and requires some additional work.
Spent a while trying to figure this one out as our old Scrum for Team systems template did this in previous version of TFS, however I can't find a way to make a PBI automatically change its state to Done when all the associated tasks are done in TFS 2012.
Thanks
I haven't seen an out-of-the-box solution, but TFS Aggregator is a plugin that is designed to handle this scenario.