Before we start slinging code around it would probably be a good idea to map out a few concepts and requirements. I’m going to use the VSTS work section to do this. I will create requirements for each idea that I have and then later as I’m working on my code I can link these requirements with the code commits.
If you have never worked with Agile, Scrum, Waterfall or Kanban before the idea behind it is that each indivisible piece of work is laid out in what is known as a User Story. A developer can then take that story, write the code to make that story work and fulfil the acceptance criteria without having to worry about what anybody else on the team is doing. I’m not going to go in to any details on a full Agile methodology but I do want to show you creating and using User Stories in VSTS.
In VSTS go to the Work section and make sure that you are looking at the User Stories / Board view. The screenshot above shows the basic layout and this can then be further customized for your needs. In our corporate environment we have added ‘Ready’ and ‘Accepted’ columns as well as a ‘High Priority’ swimlane as follows.
Now I can start creating my User Stories. Clicking on New Item in the New column will create a new card in the New column where you can type in a title. You can create a bunch of these in quick succession as you jot down your ideas and then come back and start fleshing them out with more details.
Now that we have our main ideas in place you can open those cards and start adding the details and acceptance criteria. You can also set priorities and story points and other info that can help with the prioritization and planning of stories but I won’t be getting in to that for this application.
If you look at the user story you can see that it is written in a very specific manner. As a [WHO] I would like [WHAT] so that I can [WHY]. Even if you are writing your own user stories you should try and use this methodology as it helps you get inside the mind of the users of the application need. The acceptance criteria is written is the form of what the user does and what the expected result is. In a large organization it will probably be the product owners and not the developers who write thee user stories.
In this case the product owner has finished writing the user story and has dropped it in to the ‘Ready’ column. This indicates to the development team that the story is ready to start work on so as the developer I can then drag that story from the ‘Ready’ column to the ‘Active’ column. This will assign the story to me and tell any other developers on the team that I am working on it.
Now I can start writing code…