I'd like to avoid for the stakeholders to view the name of developers working on tasks (Assigned To columns).
Is there a way to hide it?
Unfortunately, there isn't a permission model for fields in a Process Template, so it isn't possible to hide the field only for certain users.
There are a few places in the user-interface where you can customize the view. For example, you can customize the settings for the Kanban Board to pick and choose which fields are displayed:
And while you can remove Columns from lists, this is only a band-aid workaround as the information is still available and columns can easily be added back in for personal views.
In an agile world, we want our stakeholders to have visibility. Microsoft's view of DevOps is "people and process working with tools to deliver value to customers". Stakeholders have a role in your project, but their contributions aren't the same as those that are doing the work. The classic example is Ham and Eggs
If your concerns are truly about privacy - don't give Stakeholders access! Consider finding an alternate method of keeping them in the loop. For example, Azure DevOps allows you to query their system via an Excel Plugin.
Related
I'm fairly new to the different work items available in Azure Devops Server 2020 (TFS) and wonder if I could get some advice on what to select.
I am the only developer in a project and have direct contact with the stakeholder. When the stakeholder report an issue should I then create an Issue/impediment that describes whats is wrong or needs to be changed. And then create a task or bug that I link to that issue/impediment?
You can use Agile Glossary to get some information.
Issues/Impediments:
A type of work item that helps track unplanned activities. Resolving
an issue or impediment requires more work beyond what was scheduled
based on actual requirements.
Bugs:
A type of work item that records a potential source of dissatisfaction
with the product.
You can use Bugs to report issues from your stakeholders and here you also use two ways:
Use bugs on the requirements level and create tasks under it.
Use bugs on tasks level and link them to affected user story or product backlog item.
Show bugs on backlogs and boards
Or you can use user stories/product backlog items as a record to enhance your product.
Yes I can see what is currently in the sprint, but how can I tell what was originally planned in a sprint?
I would like to be able to query this for a chart on my dashboard. Additionally, I want to be able to pass this information over to Power Bi via Analytics View.
Usually, we create product backlog to correspond to your project plan, the roadmap for what your team plans to deliver. You create your product backlog by adding Issues (Basic process), User Stories (Agile), Product Backlog Items (Scrum), Requirements (CMMI).
Your backlog consists of a list of work items. You use work items to share information, assign work to team members, track dependencies, organize work, and more.
If you want to track your project plan, you should query your product backlog.
https://learn.microsoft.com/en-us/azure/devops/report/powerbi/create-quick-report?view=azure-devops
(Posting the question here as this is the 'community' that Microsoft redirects to with a 'Need advice? Ask community' button. Hope it won't get closed as 'primarily opinion based' or 'too broad')
Hello,
I want to start using AzureDevops in my department for organizing code & work. We're a small team who creates a large number of applications & plugins.
Some of these applications have a very short lifecycle, i.e. we deliver them, and they work for years without changes. Other apps are larger and are updated/fixed across several months or years.
These applications are completely separate from each other in all aspects.
As far as I understand Azure DevOps structure, my department should become an 'Organization' (we can/need to be separate from the rest of the corporation).
I am a bit puzzled about the 'Project' part. Documentation says
In general, we recommend that you use a single project to support your organization or enterprise.
So, let's say we do have one project called Our Apps - where do we then put all the individual application-projects?
As far as I understand, each product (application) that we deliver should have it's own repository (or a set of applications, if they are logically connected).
This is in order to allow a developer to simply clone the repo on their machine and contribute to that product only - without downloading other projects etc.
I need to be able to:
easily navigate/see all the tens/(hundreds?) of applications that we create,
view their separate kanban boards (for those project that do have it, not all of them will)
to see their repositories (Git or TFS), commits etc
see & manage their pipelines
At the moment it seems to me that the only place where I can see a 'list' of what products do we have is the drop down below:
And the only way to see what is going on in the big-enough-to-get-own-board products is by creating a new separate 'SomeApp Team' in the Project (even though same people are in it), so that I can have a board for the SomeApp - and view the boards from here:
Is that the intended way to organize the structure?
Any alternative approaches?
Is there any way to have a 'cross-reposistory' or 'cross-team' overview?
What about creating documentation for each 'product'?
The "one project to rule them all" was coined by Martin Hinshelwood and his blog post from way-back-when explains the reasons and limitations.
With the introduction of Tagging and filtering on the backlog there is an alternative approach within the one-project setup.
Create team for the real teams you have in your organisation.
Create an area path for each major project/product in the org.
Assign the area paths of the projects to the teams who are working on them. This can change over time.
Optionally tag work items with the major project/product for additional filtering.
This way each team sees a complete view of all the work they can pull from. And they can quickly filter the work by tags to remove items from view when discussing specific projects/products.
Also, when teams change their focus from one product/project to another, you can simply change the assigned areas for that team to update their view.
The Plan View extension provides an additional cross-team view across over all the work. And the Dependency Tracker extension can visualize dependencies over time.
You can also use the Epic/Feature/PBI|UserStory tree structure to create additional grouping in your work items. You can customize the process template to introduce a Product level, though for the planning features to work, that would also mean that you'd also have to create full traceability from Product down to PBI|UserStory.
The main recommendation is to try a few of these approaches in a light-weight manner to see how they work and find your own ideal setup.
Another option for cross project visualization is to enable the Analytics Extension and connect it to PowerBI.
As you'll soon figure out, naming guidelines for your Tags, Repositories, Pipelines is going to be very important. Being able to quickly filter to the right level requires this.
In Microsoft's VSTS, is there a way to have User Story as a child of Epic in the Agile process template, eg including when performing "mapping", without creating a VSTS custom process template? In the image below in the main content area, hide / remove Feature, and in the "Mapping" panel on the right, have Epics for mapping User Stories.
I'm asking because in my org's agile practice we have epics and user stories but we don't see the need / benefit to the extra layer of Feature WIT.
OOTB Agile process template has Epic > Feature > User Story and when you view Product Backlog (aka user stories) you can map them to Features and when you view Feature portfolio backlog you can map them to Epics, but you can't (that I know of) turn off the Feature WIT so that User Stories can be mapped directly to Epics in the GUI.
Btw, it isn't possible to rename OOTB WITs otherwise I would simply turn off Epic WIT and rename it to "Epic OOTB", and rename Feature WIT to "Epic My Org".
UPDATE: Per Add a portfolio backlog level it is possible to add a portfolio backlog level with a new WIT:
You'll first export your process, add or update definition files, and
then import that process to either update existing team projects or
use it to create a team project.
but I want to remove one. I may try the reverse using this procedure but first I'd like some reassurance that it likely works for removing an OOTB level.
Some of the docs I've consulted include:
Agile process work item types and workflow - Microsoft Docs
Define features and epics - Microsoft Docs
There isn’t such feature in VSTS, also you can’t custom too: Modify the backlog and boards
Why don't you use tools like Jira or Rally to map in your agile practices? It will be immensely beneficial in long run.
Agile, by its very definition, means that you should be flexible. As such, ignoring the User Story as a sub-class of feature can be done. However, I think that if the focus of your delivery has a strong user-component to it, then marrying that up in deliverables will give a better indicator to your product owners.
If you're scrumming it, then you'd generally be working on a feature-task loop anyway, so I wouldn't worry, VSTS seems to cope well with both.
VSTS doesn't really concentrate heavy on Workflows OOTB like JIRA pushes (I've seen some crazy JIRA workflows in my time), although it is quite extensible, I believe the VSTS Team have gone Zen Agile in terms of offering a service that helps teams develop code first and foremost, and consigns the machinations of the upper tier management of software delivery and work tracking second.
See the process guidelines for more info: https://learn.microsoft.com/en-us/vsts/boards/work-items/guidance/choose-process?view=vsts
I'm currently using Team Services with multiple teams but am having an issue with displaying tasks on the specific team's backlog.
I have created two teams (Portal & Core) with there own area.
I have created a story and have set it to the root area.
To complete this story requires effort by both teams. I have created a task for the Portal team and set it to their area and another task for the Core team and have set it to their area.
If I look at the teams backlog I cannot see the task for them (I have set Show Parents).
Should I be able to split tasks of a story across multiple teams?
Thanks
No, there isn't any way to achieve this directly. But there is an alternative method for this, refer to the steps below for details:
Go to the "Work\Area" settings of the root project and add a new child area for example "TwoTeams".
Go to the "Work\Area" settings of the child projects(Portal & Core) and add "CrossTeam\TwoTeams" area to them.
Assign the user story to "CrossTeam\TwoTeams" area.
Now you will see the User Story and Tasks on the teams backlog like following:
Whether you should be able to is one thing, which is a broader topic. Whether you can is a different question, one with an exact, factual answer: You can't.
A user story is intended to be a discrete unit of work that is completed by a single cross-functional team. If you have multiple teams working on one user story, chances are good that the user story is too large and should be decomposed further.