Is there a way to share Epic/Feature/Stores between Team.
We have the Following Teams
1) PM, BA, DEV, Testing for most of the projects.
For a given userStory that might be tasks that are done by BA and only visible to them. But when their work is completed for that user Stories DEV team will pick up and create their own Task for that same user Story that BA team worked upon.
Similarly, when the Dev Task is completed Testing team will create other Task under that story.
How do i organize such a setup in VSTS so that I don't have to duplicate user stories/epic and features between team ?
In VSTS, you probably want to define your own workflow stages, which will be the columns on the Kanban board view. Your stages sounds something like Analysis, Dev, Test, etc.
This way, as each team member wants to progress the task, they will update the work item to the next work stage and likely reassign the task to a new team member.
See these articles for more details (which provide an example workflow very similar to yours):
https://www.visualstudio.com/en-us/docs/work/kanban/add-columns
https://www.visualstudio.com/en-us/docs/work/kanban/kanban-basics
The simple way is that you can change work items’ area to the corresponding area of other team.
If you want to achieve other teams can see the related work items too, you can create a new area (e.g. SharedArea1) and assign to these teams. After that, you can change related work items’ area to that area (SharedArea1)
Team admin page (add another area):
This article may benefit you: Multiple teams
Related
I am very new in DevOps, and I need to add a parent to parentless tasks in DevOps. I used a third-party tool to upload the user stories and tasks, and I think this is were it went wrong. When I click on a user story, I can see the tasks linked as children - but my coworkers keeps getting them on their boards as parentless. Any good fixes for this?
Looked online, didnt find any suitable solution.
You likely have Teams set up in ADO, and your coworkers aren't part of the team the parent story is set to (its iteration path). I would check with Team(s) your coworkers are members of, and check which iterations they are able to see on their backlog & boards.
You can easily bulk-update the iteration path on the tasks and stories from a query, or from the backlog view under which they are set.
Since the process of one A/B test usually takes multiple sprints I would like to add another board in which I can add the A/B tests (as F.E. features). User stories for one sprint can then be added to a specific sprint for my team (which consists of a few specialists and a developer). This way I am able to overview the status (research phase, test , code writing, running, analysis, etc.) of all tests in one overview. I have not been able to find out how this is possiblie within Azure Devops, or if there is a work around. Can anyone help me?
My team also works in projects other than A/B tests, which means we cannot use the boards section.
Unless there is a hidden way to add another board to a team?
You could Copy or clone a work item to add the user stories or tests to a new boards. Open the user story you want to clone, then click Create copy of work item and choose whether to include exist links, attachments and child work items. After creating, change the Area and Iteration to your target boards.
Update
In Azure DevOps you can only create boards by creating a team. The team board is created as a side-effect of creating the team. Please refer to Manage and configure team tools and Configure and customize Azure Boardsfor details.
After creating and configuring a new team, you could see the boards in the dropdown list.
After reading through the End-to-End traceability documentation our team is finding it difficult to accomplish the final step in this list:
Developers create a branch or PR on a work item (in this case, a Task)
When the PR is completed and the branch merged, the work item shows the build
When the build artifact is released, the work item shows the deployment environments
All of that works great, but the final step is:
Show the builds and deployments on all parent tasks of the work item i.e., the Feature work item and the User Story work item.
Is that not possible? Or is there a rule or template that we could write that would automatically copy development links up the hierarchical chain so that developers and business can see the traceability across all associated work items?
Conversely, are we intended to manually link all development links to all work items?
Based on my understanding, you want parent work items to display builds and deployments tracked by child work items.
Testing on my side, the parent work items will not show the builds and deployments tracked by the child work items. DevOps currently does not support such feature.
We recommend that you could request this feature on: https://developercommunity.visualstudio.com/report?space=21&entry=suggestion. Voting helps increase the priority of the issue by consolidating customer impact under one feedback.
I have problem with configuration of AzureDevOps process.
My goal is simply automate work items - when work item changes state to done or is in state done on certain board I want to transfer it on other board.
I tried to achieve this by applying custom rules in my organization. Example:
I navigate to Organization Settings, select Process then I select process from list (is inherited from Scrum parent). Then I select bug (for example) and go to rules tab.
Here is screen of my configuration
Both Board no.1 and Board no.2 exist as Team Projects. I've added clearing assign to field and this one works properly.
I wondering if there is much easier way to automate moving work items through boards or team projects on status change.
I wondering if there is much easier way to automate moving work items
through boards or team projects on status change.
For this issue, I am afraid there is no easier way to achieve this requirement. Azure Devops has provided a built-in custom rule function to achieve this. This is already a very easy way.
In addition, we can also achieve this through the azure logic app, but this needs to be set in the azure portal. I don’t think it will be more convenient than custom rules.
To move work items to another project, you must be a member of the Project Administrators group or be granted explicit permissions to move work items.
Still new to VSTS. Sometimes work or requests come in and our team needs a way of sorting these into areas that will become projects, but not immediately. Can I create a task without first creating a new team project?
Also, is there a way to see different projects at a higher level than the tasks in one view on a kanban board? Ive seen some delp docs on dashboards etc, but everything including tasks are all scoped to a team project. While this makes sense to have these things for a project, but what about higher level views? At any one time, there might be 4-5 different projects being worked on as well as 2-3 different things that are not part of a project yet. Maybe VSTS isnt the place for these more general items, but a generic kanban board?
The term "team project" is kind of an antiquated name that doesn't do a great job of accurately describing its purpose. Think of a "team project" as a portfolio of related applications rather than something for a single team, or a single project.
The most common way to address is this to keep everything in a single team project. There are a lot of things that don't cross team project boundaries, and trying to force that behavior is a recipe for frustration.
Within a team project, you can create Teams. Each team can have its own backlog, its own iteration schedule, etc. Teams are assigned an area path that they own. If a work item is under their area, it's assigned to that Team.
If you have Team A's area path set to FooProject/Team A, then it belongs to that team. A work item under FooProject/Team A shows up on that Team's backlog.
From there, you can adjust security permissions and such so that if a person isn't a member of a given Team, they don't have access to see or manipulate other teams' work items.