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.
Related
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.
I'm trying to configure and customize the Azure DevOps tool as per the requirement for my application development team. In the boards setting, I have selected the option "Bugs are managed with Tasks" to get a good view of my sprint items. However, my team reports post production issues as Bugs in the tool and enabling the above mentioned setting doesn't allow me to view these Bugs in the Kanban Boad. Reason is they are not linked with any User Story.
I have been exploring the options in Backlog levels options available in the Processes settings and found that the Backlog level "Stories" is tagged only for User Story.
My query here is can i try linking Bug and Task to the already existing "Stories" backlog level. Azure DevOps does gives option to create a custom backlog level and custom Work item type. I would like to customize the existing functionality to best fit my team. Please let me know if there is a work around.
Query regarding Backlog Levels in Azure Devops
This behavior is by designed and there is no way to fix it at present for the exists Work item type Bug.
Because there is only one requirement backlog and it cannot be removed, but can be renamed and edited:
There is an user voice about this request on the Developer Community.
As workaround, we could create a custom the Work item type and add it to backlog level, for example, I create a custom Work item type BugWithoutTask, then add it portfolio backlog:
Then go to backlog settings and enable new backlog:
Now, we could these BugwithoutTask in the Kanban Boad:
You could check this document for some more deails.
Hope this helps.
Within our software, we want to implement a grid-style "Editor" for filling in information for various components. This Editor is itself a feature, and is expected to do several things out-of-the box. Most of these of these behaviors are simple and work well as Work Items.
However, one feature of the Editor that we want to implement is an auto-fill button for a particular column. This auto-fill feature is fairly involved and will really require multiple work items of its own. So it's essentially a feature within a feature.
However, from what I can tell, DevOps doesn't play very nice with features within features. You can do it, by creating a Work Item under a feature and then converting it to a feature. But then you can't drag to re-order those sub-features like you can sub-Work Items.
So, what's the "proper", best-practice, officially-supported way to handle "features of other features"? Just create the sub-features at the same level as the main feature? This seems very unorganized... but I don't know of a better fully-supported way...
EDIT: To clarify, one of the reasons we'd like to have "sub-Features" at the same level as "sub-Work Items" (in addition to just grouping everything relating to the parent feature together) is so that we can re-order and prioritize sub-Features amid the rest of the sub-Work Items for the parent feature.
Agree with Daniel,creating a new backlog level between Epics and Features is a solution.
To do it , first，your project needs to use a inherited process . You can create inherited process in the Process of Boards in Organization Setting.
Then in the inherited process, you can create a new work item type as a backlog level between Epics and Feature.
I am working as a Product Owner for a development team using scrum, we are using VSTS for our backlog.
So far I have been organizing my backlog using Epics and Features, I am mainly using features.
I use Features both to group work items but also for keeping control of delivering stuff. If I for instance know that I need to deliver a certain functionality a certain day then I create a Feature for that and include the needed work items. I need to do that because I manage many projects simultaneously.
So far, so good.
But now Product Management want to start creating Epics and Features for them to organize work. I can live without the Epics, and it is fine that they create the features and I add work items. But when I start executing I need some way to organize into deliverables.
Any idea how I can do that, basically I need a group like features but in between feature and work item
You can add tags for your and other Epics to distinguish them...
basically I need a group like features but in between feature and work item
Alternatively you can create a new work item type like features. Please see Customize a project using an inherited process for details.
Create an inherited process
Custom the process
Add a new work item type
...
Apply the customized process to your project
UPDATE:
You need to add a new Portfolio backlog level, but in Azure DevOps (VSTS) the new Portfolio backlogs can only be added as the top level, that means the hierarchy should be Deliverable > Epic > Feature > Backlog Item.
So, in this case you can rename them to match your requirements, for example rename Feature to Deliverable, Epic to Feature, Deliverable to Epic...
Please see Customize your backlogs or boards for details.
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.