>> Hi, I'm Donovan Brown,
Principal DevOps Manager from Microsoft.
I'm a firm believer that to be good at DevOps,
you first have to be good at Agile.
Both Visual Studio Team
services and Team Foundation Server offer
features that you need to manage
your work from backlogs and boards,
to a powerful query language and delivery plans.
Let's jump right into the product
and let me show you how it works.
Here I am on the landing page of
my Visual Studio Team services
account where I list all my projects,
and I can actually just click on the "Work" link
here and it's going to take me to my product backlog.
A product backlog is a prioritized list of all the items
your team wants to accomplish
in developing this piece of software.
What's really nice is it's really easy
to add items to your backlog.
I can simply come in here and type in
a title and then simply click on "Add".
Once the item has been added to my backlog,
I can simply drag and drop it to
determine where it belongs on my backlog.
I can double click on it and I can see more details.
For example, I can apply
a story point value if you want to use this for velocity.
I can control who this is
assigned to on my particular team.
I can go back in and give it a description,
and acceptance criteria, and even link other items to it.
Saving it, puts all that stuff
back inside of VSTS for me.
What's really nice is I can actually have
backlogs at different levels.
This one is currently at the story level
but if I go up to the feature,
I have one there as well,
and I can go all the way up to an epic.
Then when I'm at the higher levels,
I can use this "Plus" button here to actually see how
my entire project is made
up all the way down to the task level.
If I go back down to my story level,
I actually have some more features on
this backlog that I don't have on the other two.
For example, I can turn on forecasting.
Forecasting uses our velocity
estimated in story points here on
each item and our team's known velocity,
which you would get after working together for a while.
Now, the tool has helped me determine
which iterations I will be able
to deliver these particular items in.
If I agree with them, I can
simply take an item and drag and
drop it to that particular iteration
to assign it to that iteration.
As you can see, I can only do
these first two items because I
would need two more story points
to be able to get all of them in there,
and this is the most that I can actually fit.
So forecasting is a really cool tool
to allow you to help plan
what you believe that your team is going to be able to do
based on your historic velocity.
Not only can I see the backlog at these levels,
I can actually go down to the actual iteration itself.
When I do that, I get to see
some really cool stuff start to light up.
For example, I can start to see
capacity planning on the left-hand side.
As my team comes into
these items and starts to break them down,
we can actually give estimates on these particular items.
For example, I want to say work remaining is three,
and I can even decide what type
of activity this is going to be.
If this is going to be deployment, design,
or development, I'll say this
is going to be a development task.
When I do that, you'll start to see
the development numbers over here starting to change.
In doing so, I'm able to
determine if I have enough capacity in
each discipline as I start to estimate
my work so that my team doesn't
overcommit to delivering something.
I can see it by activity type,
I can see it by which individual
is currently assigned to,
and I have enough resources of each type and
each person to get the work actually done.
So capacity planning can also
be modified here on the "Capacity" tab;
this allows me to identify
all the team members in my team,
and identify what activity
they play on that particular team.
If a person, for example myself,
was more more than one head on your team,
you can actually add an additional activity and then give
them a capacity per day of that particular activity.
So I'm going to be spending some of my time on
deployment and some of my time on development.
If I needed to have days off,
I can actually apply days off
here as well to make sure I have
an accurate record of what my team is
capable of in each individual sprint.
Not only can you view this as a backlog,
you can also view these as boards.
Here, at the sprint level or the interation level,
we're looking at a task board.
This shows me the work item on
the left-hand side which is the parent,
and all the task underneath that have to be accomplished
for this to be complete or done.
To update my status, I can simply drag and drop.
If I'm done with it, what I
really like about this as well is that I
can come here and quickly adjust
the number of hours remaining.
I might not complete this task in a day,
but it's important for me to update how much work is
remaining so that my burn downs burn down correctly.
Too many developers wait till they're
done to adjust this value,
and they're not giving their scrum
master the information and
the ammunition to make sure
that we're going to deliver on our sprint goal.
But this is very simple.
I simply say there's an hour left here,
there is two hours left here,
and my burn down now is going to burn down correctly.
Anywhere that you see this gear is
an opportunity for you to
customize what it is that you're viewing.
I can customize how task look, how bugs look,
and even how the user stories appear on my task board.
I can determine which backlogs I want at which levels.
So if you don't use epic or features,
you don't have to go that high.
How many days we actually work?
If you work seven days a week, you can adjust that.
If I want my bugs to show up
on my backlogs and my task board,
just like other work, some teams prefer that,
some teams do not and you can customize that right here.
A task board is great,
but when you go to a higher level
like a story or feature,
you're more looking at a Kanban board.
This is where the overarching item
is actually going to move across the board.
You also can apply things like WIP limits,
which is a work in progress,
and this let's us know that we have too much work in
the active state and
before we pull anything else over there,
we have to get something out of
there and move it into the resolve state,
and this makes sure that you get stuff done.
You can adjust those WIP limits and
your definition of done if you need to.
Just like before, I simply drag
and drop to update my particular status.
Another thing I like about the Kanban board is
the ability for me to quickly
see how many task are underneath,
and I can even mark them as
"Complete" right here on the Kanban board.
I can also see which task have test on them,
and this is going to find the acceptance criteria
for this particular item.
If your team is using Git as your source control,
directly from this board you can actually create
a new branch for this particular piece of work.
This is going to make an association,
as you can see down at the bottom,
between this branch and that particular work item.
If you're like me, you've created
more branches and you know what
to do with and you don't even
remember why you created them.
But when you create a branch from the Kanban board,
that branch and that work item are immediately
associated together. But it gets even better.
If we commit to this branch,
every CI build that is
triggered and every release that is
deployed is automatically associated to this work item.
You're going to get into entraceability
all from simply creating a branch.
So having your work item tracking, your source control,
your build and your release all in one product,
gives you this unparalleled traceability
for making a very simple gesture like that one.
So here we've been able to look at our capacity planning,
we've also been able to look at how we
would set up our iterations and our sprints.
We just want to show you that getting started with Agile
is very simple inside of
the Visual Studio Team Services family.
But there's two other places
I want to show you before we leave.
One of them is the query language.
Once you have lots and lots of
work items inside of your backlog,
it can sometimes be difficult to find
the one that you're interested in.
Thanks to our query language,
you can come in here with this really nice WYSIWYG editor
add new criteria and
pinpoint the item that you're looking for.
Then you simply run the criteria and then you'll get back
the results down here at the bottom and
quickly find the item that you're looking for.
There's also a "Work Items" tab here which
is focused for the individual who's viewing this screen.
So now, I'm not cluttered up with
all the information of other people;
I get to see all the work that's currently assigned to
me so that I know exactly what I can focus on.
Now this, I'm drilling into
a specific project and I'm
seeing the work that is assigned
to me at the project level.
But if we back all the way back up to where we were at
the beginning when we came into
this particular application in the landing page,
I don't even have to choose a project;
there's a new work item
here that allows me to see all my work
across all the projects inside of
this particular Visual Studio Team Services account.
So, regardless if you're using Kanban, Agile or scrum,
you're going to be able to find
the tools that you need inside of
Visual Studio Team Services to
manage your work and manage your sprints.
Before I go, I want to encourage you to visit
docs.microsoft.com to learn more about Agile planning.