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:
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?