Sprint Planning in Visual Studio Team Services

Sprint Planning in VSTS

Derived from photo by Dafne Cholet / flickr.com, CC BY

Getting started in Visual Studio Team Services (VSTS) eventually leads to planning a sprint. This post discusses how to configure a sprint in VSTS and schedule work for this iteration.

This is one of a series of posts detailing the process of building an application with Angular, Visual Studio, ASP.NET Core, and Azure. See the complete list of posts here.

This is a summary of decisions made and lessons learned while creating this project in Visual Studio Team Services (VSTS):

  • Chose two weeks for the initial sprint duration and because I am a team of one, I may have varying sprint durations in the future to fit my schedule. While VSTS supports varying sprint durations, teams generally operate better with a consistent schedule.
  • Set the sprint capacity to later compare to scheduled work. Although VSTS capacity is set per day in hours, this number can be calculated from week-based or sprint-based capacity estimations.
  • Estimated backlog items using a modified Fibonacci sequence, roughly based on hours to start but will be used to comparatively size future product backlog items.
  • Estimated tasks in hours and added the Original estimate and Completed work fields to the task work item template for tracking this information as well.
  • Verified the scheduled work against the configured capacity and adjusted the scheduled work to fit the sprint capacity.

Configure the Sprint

The first thing to determine is the duration of sprints. If working on a large team, predictable sprint durations are helpful to keep everyone on the same page. However, for a project with one developer, I am going to determine sprints more on my own availability. I have been working recently in two-week increments, but alternating these iterations between code-related projects and other personal projects. So, while I may have a sprint that lasts two weeks, I may not schedule the next sprint until two weeks after the end of the previous. Also, I try to squeeze in a "week off" to my schedule occasionally where I try not to focus on achievement but rather rest and spend time with friends and family. The point is that while large teams may benefit from predictable sprint durations, Visual Studio Team Services allows for flexible durations if that works better for you and your team.

To set the dates, go to the Work section of the team project. VSTS provides a default list of iterations named Sprint 1, Sprint 2, etc. Choose Sprint 1 to view the page for that iteration. Look towards the top right of the screen and you will see a link to Set dates. Click that link and this dialog appears:

Edit iteration dialog

Set the start and end date for the sprint. Optionally, change the sprint name. I decided to go with sprint names that correspond to famous jazz musicians of the bebop era. Press Save and close to save the sprint.

Tip: The Iteration settings are also available from the Settings menu in the top navigation. Select Work, then Iterations to modify the full iteration list.

Full iteration list

Set Capacity

Capacity is another tool for scheduling work. By setting the capacity for people working on the project (even if only yourself), it helps determine if the team is committing to too much or too little work for the sprint. The VSTS sprint burndown chart also uses this number to visualize progress.

The first step is to determine how many hours per day or week everyone can commit to the project. I have roughly 14 hours per week to devote during this sprint. On the page for the current sprint, select the Capacity tab:

Capacity tab

Enter the capacity per day. Since I can do 14 hours per week, I entered in 2 hours per day. This field allows for decimals to accommodate the daily number for any week-based or sprint-based capacity estimations. For instance, if a teammate could only work 20 hours for the entire sprint, divide 20 hours by the number of days in the sprint (14) to arrive at a daily capacity of 1.43.

By default, VSTS does not count weekends as working days. Being a personal project, the weekends are prime time for getting things done so I wanted them to count towards the capacity. To enable them, click on the gear/settings icon in the top right of the team's work page and then find the settings for Working days. Enable the checkboxes for those days to include them in the capacity.

Working days settings

Estimate Product Backlog Items and Tasks

To improve my estimation skills, I'm estimating my work in VSTS. This isn't entirely necessary but I find tracking this over time leads to a better understanding of what can be accomplished in each sprint. I use two different estimation systems for product backlog items and tasks.

For product backlog items, I like using a modified Fibonacci sequence like what's found on a planning poker deck. The modified sequence progresses as 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100, etc. The product backlog item estimates do not reflect hours, but are sized relative to each other. I happen to use hours as a baseline when starting out. For instance, because this is my first sprint and first estimates, the three backlog items estimated equal 24 (8 each). This is roughly equivalent to my sprint capacity which is 28. This can be confusing for some because the units of measure are close (sizing versus hours) but not the same. I like having that loose association but I must remember that when estimating backlog items, I'm thinking about how they compare to other backlog items, not how many hours they will take. For instance, if I start thinking that a backlog item is 10 hours, I would force myself to estimate it as either an 8 meaning that it is roughly equivalent to the amount of work done for a complete product backlog item or I would decide that it is indeed larger and estimate at 13 which is the next largest number in the modified Fibonacci sequence.

Once the backlog items have been estimated, choose one or more for the sprint backlog by setting the sprint property in the product backlog item itself. I decided to take one product backlog item off my product backlog and added two new ones to the sprint and estimated them. The two new backlog items represent blog posts discussing the project work.

Once I have the backlog items that I think I can accomplish during the sprint, I start to break them down into tasks. These tasks are estimated in hours which will be matched to the sprint capacity. By default, the scrum process template in VSTS gives one field for task estimation, Remaining Work. This field is used to calculate the burndown chart as the sprint progresses. I decided to also add the Original estimate and Completed work fields to my task work items to get a better understanding of how well (or not) I estimate a task. These fields already exist in VSTS and simply need to be added to the work item template. This documentation provides details on customizing work items. Be sure to assign each task to yourself or the person scheduled to implement the work during the sprint. Look at the board view for the sprint and this is how each backlog item appears:

Product Backlog Item on Kanban board

One final thing to do before finalizing the sprint plan is to check the capacity screen one more time. On the right-hand side, there are bullet graphs representing each team member's capacity and the amount of work scheduled for them. If the bars are green, you are good to go. If they are red, it means an individual has more estimated work than capacity and you should consider adjusting the workload.

Capacity Screen

Get to Work

Now it's time to get started working through the sprint backlog. Use the Kanban board to easily visualize the sprint work. As work is accomplished, update each task with the time remaining and time completed.

Finally, refer to the sprint burndown chart to see if you are on track to reach your goals. Happy coding!

Creating a Project in Visual Studio Team Services

Starting a Personal Project in Visual Studio Team Services

Derived from photo by Ignacio Palomo Duarte / flickr.com, CC BY

This is one of a series of posts detailing the process of building an application with Angular, Visual Studio, ASP.NET Core, and Azure. See the complete listing of posts here.

This is a summary of decisions made and lessons learned while creating this project in Visual Studio Team Services (VSTS):

  • VSTS is free for teams up to 5 users
  • Started with a backlog to outline ideas for the application
  • Only entered items related to the first milestone which is a minimum prototype to validate the application's usefulness
  • Chose Git source control for my VSTS project because of personal preference and because it will be easier to publish the source code publicly to GitHub while maintaining day-to-day work in VSTS
  • Chose the Scrum process template for the VSTS project because the work item flow is slightly simpler given that I am both the developer and the user
  • Created Feature work items for items that, when complete, demonstrate value to the user
  • Created Backlog Item work items for items that benefit the engineering or design process

Creating the Project in Visual Studio Team Services

First, understand that Visual Studio Team Services (VSTS) is free for teams of up to five developers (and unlimited for work item access). This includes free private source control repositories, agile work management, build credits, and more. Check out all the free stuff here.

In VSTS, I created a new project named Bebop. There are two main decisions to make when starting the project, the type of source control to use and the work item template. I chose Git source control because I have grown to really like the ease at which I can create branches and work with multiple repositories. For instance, even though the source code will primarily live privately in VSTS, I will post it publicly to GitHub and Git makes it easy to distribute in this way.

For the process template, I chose the Scrum template. The work item status flow requires slightly less steps which is preferable given that I am the developer and customer at this point. Also, I prefer the terminology of Backlog Item over User Story for organizing work. As a developer, there are many times where system changes are made for performance or security reasons and I find writing user stories such as "As a 'user', I expect my software to be secure…" unnecessary. There are dozens of different ways to approach this configuration so do what's best for your team and project. Here is more information regarding the various process templates built-in to VSTS.

Creating the Backlog

Upon developing the backlog, I started the list in OneNote and then later moved it to Visual Studio Team Services (VSTS). It doesn't really matter the tool when starting, the initial backlog is simply a list of items that need to get done. I also thought of a couple milestones and only added items related to the first. The first milestone is to deliver the minimum feature set that can prove whether my idea for the app will even work in real-world usage. The initial list of backlog items is specific to this goal.

When brainstorming the items, there were two large categories in mind. The first category relates to which items I need to put in place to deliver the demo application. These are things like source control, deployments, etc. I also included in the list to create a prototype design. Before writing any code, it helps to take the initial bucket of features and mock out the user interface and interaction design to help avoid designing into a corner during coding. For these items, I created a Product Backlog Item work item.

The second category of backlog items were the actual features themselves. For these items, I create a Feature work item. Don't worry if you decide to use the work item types differently later as you can change the type if needed. I like to be granular when breaking down features and functionality on the backlog. While there are no deadlines, per se, estimating and tracking these work items is valuable for developing estimation skills and smaller backlog items help enable better estimations. There are other insights that VSTS will give based off these estimations such as a burndown chart for each sprint.

For now, I focused on getting the work into the system which amounts to nothing more than filling out the title of the work item. It will be an ongoing process to refine the list and further schedule it for implementation. This is what the initial list looks like in VSTS:

Backlog Screenshot

In the next post, I'll look at how I'm going to schedule this work in VSTS and organize it into sprints. The process of creating a backlog in VSTS is simple yet there are subtle decisions to make in organizing the work. What are your preferences for creating a backlog in VSTS?