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:
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.
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:
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.
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:
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.
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!