This is part 2 of a multipart series on getting started with Azure DevOps. Please refer to the below links to access other notes in this series.
Part 1: Getting started with Azure DevOps
Part 2: Getting started with Azure DevOps -work items (this note)
Part 3: Getting started with Azure DevOps -add a repo
Part 4: Getting started with Azure DevOps -create a build agent
Part 5: Getting started with Azure DevOps -create a build pipeline -Part 1 (YAML pipeline)
Part 6: Getting started with Azure DevOps -create a build pipeline -Part 2 (Classic Editor)
Part 7: Getting started with Azure DevOps -create a deployment group
Part 8: Getting started with Azure DevOps -create a release definition
In my earlier post, I explored the option of creating an organization and a new project. In this post, I will explore a project.
I’d like to start my project with a new feature (work item) and since we’re still setting things up, I’m going to call it ‘Initial Setup’. I will then create a few child user stories inside this feature to:
-link a GIT repo
-add a demo project to the repo
-create a build using Azure pipeline
-create a release
Each of these user stories can have child task workitem/s associated that provide granularity about the user story. You can start at whatever parent level work item that makes sense to you and then break that into multiple child work items. (At work I use a full-blown visual studio professional license to perform my regular day to day DevOps engineer job and the free Azure DevOps portal seems to have quite a few nice features already; haven’t explored in detail yet). Getting back to our Azure DevOps project portal and on the left-hand pane, navigate into Boards -> Work items
This should take us to work items page where we may decide the type of work item we intend on creating… in this case a Feature
…and then we can fill in more details of the Feature work item.
However, I found that the Area and Iteration were not exactly as I’d want them to be. And on navigating a little around the tool, I figured out where to set that. Since this is initial setup work, I’d want to call the Area as Initial Setup and the Iteration as Iteration 1. These options are available by clicking on the gear on the bottom left corner of the page. Gear -> Project configuration -> Iterations/Areas -> New child.
You may also set your iteration if you want and assign dates against them for better visibility. I created an iteration as Initial Setup and inside that have 4 iterations, each 1 week long.
Also please note, that this project was created on the Agile process template and hence we are seeing these options being made available at the project level. Navigating back to the project portal, I can now create a few additional child work items to this feature.
… and these work items can be associated with the same or different iterations as the plan may be. Once these individual work items are created, there are multiple views available -board, backlogs, sprints, and queries.
Boards: This is a Kanban board that gives us a top-level view of how the project is looking, who is working on what user stories and what is the status of the work items. There are a lot of options available like moving cards around (drag and drop), assigning them to people to work on, clicking on them to read more details… however, a quick option that I liked was the ease at which a child work item (like a task, bug or a test) could be added; just click on the ellipsis next to the work item to list the options.
Backlogs: You can toggle between the board and backlogs (as can be seen above -View as Backlog link). The backlog view allows us to prioritize all the work that we have -again drag and drop. I also could see that a sprint view was inserted on the right-hand side (I had Side Pane option checked). Via the backlog view I noticed that when I added two user stories, I missed associating them with the parent Feature: Initial Setup.
On the whole, I can see that the view offered a lot of value along with the Board view mentioned above.
Sprints: This is the view where we schedule the task that needs to be done as part of user stories. The image I have below is of the current sprint and as can be seen, we’ve got two user stories scheduled in this sprint. The + sign under the New column allows me to add a task (or bug) work items under the user story to further break that down. Each sprint view also has a Backlog view, which lists work items that are inside of the current sprint.
Queries: A neat area to generate and save specific queries to identify work items across the project. Say, I want to view, what are all the work items that are assigned to me and have a state of new. This can be across multiple sprints or just one sprint. Queries allow us this flexibility.
Going forward, I will work on each of these user stories and document the steps involved. As with any new tool, the more you work with it, the more you find cool new features.
The following link provides in a lot of detail about Azure DevOps: https://docs.microsoft.com/en-us/azure/devops/boards/index?view=azure-devops
My Devops Journal 