Feb 21, 2018
Organising your work with Visual Studio Team Services using scrum process type
When I first started using it, it annoyed me for not being super simple. Soon I realised it is not complicated at all — if you know what you are doing. Offering much while being free for small teams, it is a tool I stuck with.
Visual Studio Team Services offers much more than just project management tools; however, in this blog post, I am only focusing on that part.
So far, I have used other project management tools: Trello, KanbanFlow, Jira and Pivotal Tracker. Visual Studio Team Services is, by far, my favourite. Read on if you want to learn how to use it to plan and track your project’s work.
Setting up the environment
Go to https://www.visualstudio.com/team-services/.
In order to use it, you only need to have a Microsoft account.
Use your existing account to sign in or create a new one.
Pick a name (whatever makes sense for you. It will be used by projects’ team members). The name needs to be unique: validation will let you know if that is not the case.
Visual Studio Team Services (VSTS) uses agile as a default process type to organise your work. To change that for your first project, now is the moment: choose Change details before clicking Continue. In this blog post, I am covering the Scrum process, so this is where I change it:
Yaay — the fun begins now! The project is ready.
Team settings
Before starting adding your first tasks, I would suggest you first define your team settings. In order to do that, you need to go to your Team page (you are by default placed in your Project page). To get there, I used top gear icon and clicked Default team settings.
Note how the url now changed, in my case from https://andreasvaglictestprojects.visualstudio.com/AndreasProject1 to https://andreasvaglictestprojects.visualstudio.com/AndreasProject1/AndreasProject1%20Team/_admin.
This is the “home page” of your team profile. Click Work in the upper tab to set the work settings:
This is where you get to define the backlog navigation levels. I am using all three levels in my projects: Epics, Features and Backlog items. Once you start managing your project, each Backlog item has a chance to be estimated (in relative points) and can have as many tasks as you need to have, in order to accomplish that backlog item.
In my team, we use Epics for things like “App version 1.0”, Features for things like “Authorisation” or “List filters”, Backlog items to break down features (or part of features) into things doable in one sprint, and Tasks to describe how those items will actually be done. Our tasks look like “Add an endpoint for deleting a player” or “Add Select All functionality on players list”. Each task has a chance to be estimated in time (called Remaining work in VSTS). We use this, because it allows the Burndown chart to depict how the sprint is going and because VSTS then manages the sprint capacities for us. More on that later.
In the same Work section of the Team settings, tab General, you can also define working days of the week. Later, when using iterations, you will have the chance to specify how much hours per day each team member wants or can dedicate to the specific project, and specify the days off, if applicable to the sprint. This data is useful to have always up to date, because the Burndown chart and sprint capacities calculation depend on it.
In order to start planning and tracking work, in scrum we need iterations. Stay in Work section, but switch the tab to Iterations. By default, I got first 6 iterations defined by VSTS, named “Sprint 1” to “Sprint 6”. Click on three dots icon → Edit to set up details for each iteration.
You want to do this if you want VSTS to automatically switch iterations for you, based on the current date.
We use one-week iterations so I will set up my iterations accordingly. Also, I like to make them last from Monday to Sunday, along with having all the week days set as working days, but then later, in sprint planning, make 1 or 2 days off. This gives me freedom to take any 1 or 2 days in a week off. Of course, most commonly, for companies, is to work Mondays to Fridays, so sprints should be set like that in those cases.
It is a good practice to give each sprint a name, if possible, to indicate the sprint goal and by that, maybe, limit the feature diversity inside one sprint to keep the focus on one of two things per iteration. This really depends on the team size and the state the project is in.
VSTS is smart: after setting the dates for the first iteration, it preselects the dates for your next iterations when you go and edit them.
To add a new iteration, simply go to New and fill in the necessary data.
Regarding team settings, these are the most common ones to set up.
Planning the work
Go back to your project, by clicking the project/team name indicator in the upper left corner and choose your project home page (that is the one you landed on after creating the project):
Notice how the link changes back to initial one, in my case https://andreasvaglictestprojects.visualstudio.com/AndreasProject1.
Now let’s plan some work. Click the Work section in the upper menu. By default, it leads to Backlog items section of the page. Since this is a fresh project, I will start with defining some epics. Note that, in this view, you will only see the backlog navigation levels you chose in the team settings (epics / features / backlog items).
Let’s define some epics.
After entering the first epic, you will see it sets the Value Area to “Business”. You can change that by clicking three dots icon and then Edit.
Also, you will notice a diagram forming in the upper right corner. It is a Cumulative flow diagram. If you are not familiar with the term, I found a thorough explanation of it here: http://brodzinski.com/2013/07/cumulative-flow-diagram.html.
After defining 2 test epics, I move to Features section. I always use the Mapping: “On” option, because it allows for easy drag-and-drop of features into epics. Also, having Parents set to “Show” makes it a nice overview of features paired to their epics. You can find both toggle buttons in the upper right menu of the Features section. Go on and create couple of features and drag them to their corresponding epics. By default, every feature is marked as “Unparented Features”, so all you need to do is drag and drop it to the right, under the epic it belongs to (if you enabled Mapping flag).
One VSTS minus is that it sometimes doesn’t refresh partial views correctly, so it might happen that you see your feature under the correct epic, but “Unparented Features” is still visible as a parent, even though it doesn’t have any features in it. This is only fixable by hitting refresh. It happens on other views too, but so far, it is the only bad thing I noticed about the project management features of the tool.
After pairing the first one, all the following features will fall under the same parent. If it doesn’t match, simply drag and drop it to another epic.
If you need to delete anything, by the way, there is a recycle bin icon in the bottom left corner, and you can drag and drop anything to it. Very handy feature.
We have some features defined, it is time to add backlog items. Click Backlog Items in the left menu — it is the view you get opened by default when clicking Work in the upper website menu.
If you enabled Mapping and Parents flag in Features view, they will both be enabled in Backlog items view for you. Only now, in the right section, you will see your features list. Mapping backlog items to features works the same way as mapping features to epics: by simply drag-and-dropping it. If you don’t do it, every backlog item will, by default, be under “Unparented Backlog items”.
How you form the backlog items titles really depends on your team preferences. However, the titles should be short enough so you don’t have to resize the title column too much and hide other useful columns.
Regarding columns, in Backlog items view, you can also see the following columns: Effort, Iteration path and Tags. In our workflow, we usually estimate the Effort on our planning session, just before starting the sprint. Iteration path is the same for all of them, because we haven’t yet put the items into sprints. You can use tags to later make queries and find all the tasks, backlog items or features with the same tag. I will not write about queries in this blog post, as it is a topic for itself.
By the way, you can always access your team settings by clicking the gear icon which is next to the Mapping toggle button. Remember, in team settings we defined our working days and backlog navigation levels.
We are now ready to plan our first sprint. In my team, we usually do it first thing in the morning, on the first day of the sprint, which is Monday. We start from the Backlog items view, and simply drag-and-drop the backlog items into the sprint we are planning. All the available sprints are visible in the menu on the left side of the screen. If the previous iteration was unsuccessful, we usually drag unfinished tasks from that iteration to the current one.
After drag-and-dropping them, you see how the Iteration path column now has the specific sprint name for each backlog item:
My “Sprint 1” iteration now has two backlog items planned in it. Click the sprint name in the left menu. If the dates are set correctly, the sprint you are in now, should be under Current. If there is no sprint that lasts right now, under Current you will see the iteration that starts first. This happens in my case, as I set the first iteration to start on February 26th, and today is February 21st.
Before starting to estimate and break down the backlog items, go to Capacity section.
Here you can specify the type of activity each team member does and their capacity per day. This is a moment to specify the days off in that sprint too. Capacity per day is a number of hours the team member can dedicate to this project in this sprint. Specify this if you want your Burndown chart to make sense. Make sure to click the save icon before leaving this section.
Now go to the Backlog section.
In this view, you will see the backlog items you drag-and-dropped into the sprint. We use the sprint planning session to estimate backlog items. To to that, click the backlog item title.
An overlay will open:
If the whole backlog item can be assigned to one person, you can click on Unassigned below the title, and choose a team member.
To estimate the backlog item, use the Effort input field. How you estimate is a topic for itself. We use relative points: 1, 2, 3, 5, 8, 13. For us, each number represents a mixture of complexity, level of unknown and possible time effort. If the effort is 13, it usually means we need to break down that backlog item into multiple ones because it is too big.
Managing tasks
When you are done with estimations, you can go to the Board section. This is the most visited view once you start working on your tasks. For us, it is used on the daily standup session, and during the working days, to reflect what tasks are in which state.
In the Board view, use the plus icon in each row to define tasks that need to be done to accomplish each backlog item. Clicking on Unassigned lets you assign the task to a team member. Clicking on an empty input next to it, lets you estimate the task in hours. Use these options, and VSTS will connect it with the data you provided on the team members capacities earlier, to show how much of capacity is being used in the sprint. You can see this information in the Backlog view, once team members get some tasks assigned.
Once you start working, simply drag and drop tasks depending on their status. Once all the tasks related to a backlog item are done, you can change the State of the backlog item to Done.
Reading the charts
Note how my Burndown chart (top right corner) is empty right now — this is because the sprint has not yet started. Once it starts, the chart will depict how your sprint is going. Here is a real world example, from one of my projects:
Of course, the more discipline and as less unplanned work, the curve is closer to the ideal trend. If the blue area never reaches the bottom, it means there are unfinished tasks at the end of the sprint. If the blue area climbs up at any point, it means you have been adding tasks during the sprint, which is not ideal. If the blue area starts from a lower point than the green line, it means you have not used all the capacities you had.
Once the tasks and backlog items start being moved on the board, by returning to the Backlog items section, you will notice another chart: Velocity. Click on it and VSTS gives you an overview of your project’s velocity during time.
The numbers stated in the velocity graph come from the efforts you defined per each backlog item. Only when the backlog item is set to Done, its effort gets calculated into the velocity sum for that sprint.
This is a real world example of a velocity chart, taken from one of my projects:
Of course, as a project manager, you need to have additional knowledge of past sprints, in order to get useful information out of this chart. It makes sense to map things like capacities, features developed etc. to the velocity chart, to extract some knowledge about the team and about the project.
Summary
Visual Studio Team Services is a very powerful tool, not just for a project management. In this blog post I only covered one small piece of it, which is planning and tracking work using Scrum process type. I started using it for managing my projects only couple of months ago, so there is still so much to learn about this versatile tool. Compared to other tools I have used so far, it gives way more possibilities, it is not annoying to use and it is completely free for small teams. Do you have experiences with it, and if yes, do they differ from mine? Please share, I would like to hear other opinions!
