VSTS backlog items - adding tasks without a project and cross project views - azure-devops

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.

Related

I am looking for a way in Azure DevOps to have a good overview of the status of my A/B tests

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.

Is it possible to have multiple backlogs for a single team in Azure Devops?

Sorry if this isn't the right place for this, but all the devops question I see on stack exchange seem to be in stackoverflow.
I've begun working with Azure DevOps, and something I'm noticing is that managing items becomes more cumbersome as I add in more bugs, stories, etc... I'm searching for a way to be able to manage and prioritize these items more easily, and I was wondering if it's possible to have multiple backlogs. Say one for bugs, then one for enhancements, one for support tickets. The issue I'm running into is that we only have one team of developers, so ideally this would all be housed under one team so all these items can be dealt with in a single team's sprint instead of a sprint for each team.
Initially I thought that queries might be a viable option, but when creating them I quickly learned that I cannot reorder items. So that ended that idea.
I also considered just viewing the backlog with a filter to only show what I'm looking for, but that too does not allow me to reorder items easily. It looks like I can drag n drop them, but that doesn't work. I can open the ellipsis menu and choose "move to position", but that's far too clunky of a solution when you have many work items. I also sometimes get conflict errors when trying to move them in that manner.
So I keep coming back to the idea of multiple backlogs for a single team. Is this possible? I don't really see anything in the documentation, and I don't even know if this is considered best practice? Any insights are greatly appreciated.
Sounds like you have tried the out the most obvious ways of filtering and searching for workitems in the backlog and on the boards.
What you can setup is an hierarchy of area paths and (sub)teams to allow for filtered view of the backlog.
Consider the following structure of area paths
ProjectName
- Bugs
- Enhancements
- Tickets
Then you create 4 teams, each corresponding to one node in the Area Path tree (make sure to tick the box include children for all of them). As you now have 4 teams you also get 4 backlogs. The top level team that maps to ProjectName will contain the full backlog (equivalent to what you have now). The other three will only show workitems under their respective area path. You can now use those 3 teams to view filtered versions of the backlog (or boards), but still maintain a single backlog on top level.
As Iterations are defined per project, and are shared across teams, you can continue with one set of iterations and add them to all teams, making them shared.
By this setup any team member can jump between the different subteams to view their preferred filtered version of the backlog (or the complete backlog on the root team)
This feels kinda hackish, setting up new "Teams" just to filter the backlog and whether this is considered best practice or not isn't straightforward to answer. Generally an Agile team should have one backlog and prioritize it as a whole but one could argue that the top level combined backlog fills that purpose and the sub backlogs are used for easier management and for visualizing only parts of the backlog. After all Agile is not about tools it is about being productive.
As danielorn's answer, you can set up multiple iterations. But you don't need to set up multiple teams, you can just use your currently team.
You can try the following steps to see whether this method can fit your requirement.
Step 1. Go to Project Settings -> Boards/Project configuration, create some new child Iterations of your project. In your case, you can leave out the start and end dates of the iteration. Just like this:
Step 2. Go to Boards/Backlogs -> View Options (top right corner) -> Choose "Planning".
Step 3. Click "New Sprint" in the Planning Side Pane, add the Iterations you have created in step1 to the Planning. (Of course, you can skip step 1 and directly create new iterations here, but the iterations you create here must have start and end dates.)
Step 4. Drag the work item to the corresponding Iteration. Then click the iteration, you will see a "new" Backlog that only has work items of this iteration.

Creation of a custom board

I want to create a custom kanban board based on a new query for my team.
The ones you get by default seem to be an all or nothing thing, we would like to break down our work outside of sprint planning in to "feature boards" that contain items that may span multiple sprints but are towards a common sub goal of our project.
Is this possible?
That's not the common scenario which TFS/Azure-Devops designed for.
Based on your requirement, you can try creating multiple teams and areas. Area paths allow you to group work items by team, product, or feature area. Then set team default to select the areas the specific team owns below. The selected area paths will determine what shows up on your team's backlog/board and what work items your team is responsible for.
Please see below articles for more information:
Kanban basics
Set team defaults
About area and iteration paths (aka sprints)
Besides, you can also try this extension: Kanban Board Tools, it provides a set of tools to enhance Kanban board usage within TFS and VSTS.
You might want to take a look at this free extension: https://marketplace.visualstudio.com/items?itemName=realdolmen.querybasedboards, that allows you to display a query result into columns, based on work item states configuration.

VSTS terminology and structure

New to VSTS, but not Git. Our small team has the usual mix of web apps, windows apps, other misc applications/services and we keep our database objects in visual studio sql server projects as well. So there are 15-20 or so different sets of code to deal with. Currently, each would have its own Git repo.
Was reading this post regarding single vs multiple "Team Projects".
Then, I posted this earlier but was specific to backlog items, but I suppose my real question was about the bigger picture regarding the idea of a "team project"
What would be a good structure for a small team with this number of applications. Assuming each application generally is worked on independently, but you might want to build 2 or more of these applications together.
How about one team project. Multiple "teams", one per "application".
Its the terminology that is throwing me off.
Can different teams each use a different repo?
Can each team have a different set of build definitions? eg. dev/prod etc
A team project is a container for a portfolio of related applications. A team project can contain one or more source code repos (Git/TFVC), builds, releases, test cases, work items, etc. All of these entities have ways of defining security around who can view/modify them.
A team is just an organizational structure within a team project. You can use security permissions to limit certain repos, builds (or build folders), etc to a certain team.
The generally accepted guidance is to keep everything in a single team project. There are lots of things that don't cross team project boundaries, such as repos. Work-arounds usually exist, but they are typically awkward.
The one requirement you gave ([we] might want to build 2 or more of these applications together) is actually slightly tricky regardless of whether the repos are in one or in multiple team projects -- a build definition can be hooked up to a single repo. If you need to bring in additional repos, you'll need to use submodules or add an extra build step to clone the second repo. I can almost guarantee it'll be easier if everything is in the same team project, though.
The one-word answer to the two direct questions you asked is "Yes."
How you set up your structure is really depending. There are many ways to organize it. Single repo, multiple repos.
If you are using CI builds, have in mind that the get sources task in your build will download your full repo. So if you have a single repo strategy your build could take longer to run. In this scenario you would also have more work to setup your builds and specify path filters to trigger only the correct build on your CI process.
Can different teams each use a different repo?
Yes they can.
You can create a security group for each team.
Then, on you team you can remove it from Contributos and add your new group as part of Member of:
After that, in your version control settings, add your new security group and remove or deny access to Contributos security group. This way, only your team security group will have access to the repo.
This is optional. You only need to do it if you want to isolate access to your repos.
Can each team have a different set of build definitions? eg. dev/prod
etc
You can setup a build for each of your repos.
If you need to isolate who has access, you can do it by changing the security on each build, removing contributos and adding your security group.

VSTS: Sharing Stories/Feature & Epic between Teams

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