- [Instructor] In this section,
we will explore an essential aspect of Azure DevOps,
which is project management hierarchies.
The hierarchy typically looks like this.
At the very top level, you have your organization,
and for me, that's called emma0772.
For you, it will be called
whatever your Azure account named it as,
whatever your Azure account name is.
So if you are accessing ADO through work,
this could be the name of your company,
if you've only got one account across a whole company,
or it could be the name of a division or a department.
Next along in the breadcrumb bar,
you have your project name.
Within your organization,
you can create one or many projects.
Our project here is called LIL for LinkedIn Learning.
Each project should represent a specific initiative
or product or development effort.
So really I think of it as one project per application.
Next in the breadcrumb bar,
we have boards and then work items
and that's just giving you the position
within the left navigation hierarchy.
So if you look on the left, we have boards and work items,
and if we were to change that to boards and backlogs,
you would see the top breadcrumb bar changes as well.
So we have organization and project shown at the top,
but really you can continue to slice and dice the work
that ADO holds in lots of other ways
that are not shown here at the moment.
And one of these ways is by team.
If you see on the very bottom left of the screen,
there's project settings.
And if we go in there, you can see some of the team details.
There's a whole new menu that's cropped up now.
And you can create lots of different projects.
Don't forget, this is just one of them.
So within the project called LIL,
you can give it a description
and you can also check out teams,
which is what we're going to do right now.
So inside each project you can define teams.
Teams are groups of people
with specific roles and responsibilities.
So in another area of my work within ADO,
which is not shown here,
I'm working on an application that's so large,
it's got multiple teams who are focused
on very different parts of the application.
So you'll have one team looking at the sales aspect,
and you'll have one team looking
at the personnel aspect, for example,
and they build those parts of the application
completely separately from each other.
Now what I've done by clicking on the new team button
that you can see
in the sort of top right of this little window,
I've added to the default team,
which was LIL Team, which is a team of coders
and I've created a new team called LIL Testers.
And you can add new teams yourself by clicking new team
and pulling in different developers into that team.
So you can give it a new name,
you can add some members,
and you can see at the moment, it only knows about me.
You can give it a description,
and then if you scroll down,
and don't forget to scroll down,
it says create an area path with the name of the team
and that's checked because I find that useful.
That means we'll be able to see it in the breadcrumb bar.
Now I'm going to cancel out of that
because I've already created my team.
But it's useful when you are learning about ADO
to have more than one team
because this flows through to all of your work items.
Now that we have our hierarchy sorted,
we can start to add bits of work into the framework.
These are called work items as we've seen before,
and they can be of different types.
So if we just come back here.
You might have heard of user stories,
I've mentioned them before.
You've also got epics, features and bugs.
Now we have our hierarchy sorted,
we can start to add bits of work into our project.
These bits of work are called work items,
and they can be of different types.
So you see here that we have one epic,
we have a user story, a feature, a task, and a bug.
Okay, those are the different types of work item
that we will be looking at,
and we are going to look at that
within the context of a fictitious new app
called Style My Yard.