Azure DevOps provides 4 processes as standard. When creating a project, the default process is Agile. However, by browsing to Advanced, you will be prompted to choose between the available processes.
Basic: This is the simplest process provided by Azure DevOps. The basic process tracks tasks from not started, doing and done and only tracks three types of work items. These are epics, issues and tasks. In part two of this blog, we will review the differences between these work items.
CMMI: The Capability Maturity Model index closely relates to a standard waterfall methodology. It includes work items which allows a formal change management process. Work items which allows the project team access to Risks, Issues and Decisions from within Azure DevOps.
Agile: The agile process is, as you’d expect it to be, a process which adheres to Agile principles. So, the terminology used to define work items as well as the functionality available makes this process quite popular for projects running an agile methodology.
Scrum: Scrum is a variation of agile with different terminology. Azure DevOps, similarly with the agile process has terminology specific to the Scrum process.
You may question having both Agile and Scrum processes and be confused about the differences. One of the main differences that you’ll encounter is that within the Agile process, tasks can be tracked by there original estimate, remaining work as well as completed work. However, if using the scrum process, tasks can only be tracked by the task’s remaining work.
Overview of the Basic Process
First, each standard process provides different work items which allows users to track work in different ways.
Epics
Now, epics are considered the top of the hierarchy within Azure DevOps. As such this work item really defines the process at a high level and what features this may include.
Issues
So, epics can have one or more associated issues. Issues, when using the basic process is not meant in the context of a problem. Instead it is to group at a high level what needs to be accomplished in order to achieve the epic.
Task
Now, a task is meant to be associated to Issues to define at a low level. A task needs to be done in order to close the defined issues.
Also, each work item has a list of available attributes/fields. Interestingly enough, not all fields which are available are added to the work item form. Therefore, it’s definitely advisable to check that a field exists for what you need before creating another one. Here are the defined lists of fields available for the epic, issue and task work items: Basic Process Available Fields.
Useful fields
History
Each work item has a discussion area to allow comments related to the work item. The discussion area contains timestamped records of each comment made by each user. The comments are saved in the history field and can be used in queries in Azure DevOps.
Board Column and Board Column Done
A feature available within the Azure DevOps Kanban boards is the ability to split columns. This allows greater flexibility in team members. Specifying, the work has been completed or that work has begun in the next stage of the process.
Therefore, the Board Column attribute allows us to view work items within the specified board column. However, the Board Column Done attribute shows us work items which have been moved to the done column. This happens when split columns has been activated.
As each work item progresses, they go through different states. The states available by default differ based on the process selected. The basic process has only three states – To Do, Doing and Done.
Each state also has a reason which adds some more clarity about the state of the work item. For e.g a task that has just been added will default to a stage of To Do but will have a reason of Added to Backlog, when the Task is moved to Doing, the reason changes to started. If the task is moved back to a state of to do, the reason will not revert to added to backlog but will instead be moved to the backlog.
The states and workflows, like the work item attributes and forms can be customised. This will be covered in a later blog where we detail how work items can be customised.
Overview of the CMMI Process
The CMMI ( Capability Maturity Model Index) process closely aligns to the waterfall methodology. The CMMI process within Azure DevOps is based on a guide published by the Software Engineering Institute called CMMI for Development: Guidelines for Process Integration and Product Improvement (SEI Series in Software Engineering).
The below image displays the typical stages and outputs within a standard waterfall project. As you read further into the blog, you will notice that the stages are similar to the states available within key work items in the CMMI process and that the terminology used to describe work items are also a close match to the standard waterfall methodology.
The work items available within the CMMI process are shown in the image below and described further on:
Epics
Now, epics within the CMMI process are the same as Epics within the Basic process. They contain the high level process of what is to be delivered. An example of this would be the delivery of different channels e.g phone or chat within a call centre.
Features
I explain how epics contain one or more features. Features allows the definition of different focus points which must be delivered in order for the epic to be delivered. E.g telephony integration and call verification features would be required in order to deliver an epic related to the delivery of a telephone channel in a call centre.
Requirements
Requirements describe the needs of the business and also defines what is required for the feature to be completed. They can be associated to one or more Features. It should be noted that a requirement is not a feature and should contain enough information for both testers and developers to understand the business need and what the system is expected to do to satisfy the need.
Requirements which define how the system will satisfy the need reduces the flexibility of designing the system and may create issues later in the project as technically and strictly speaking, changing how the requirement is implemented would mean that a change request should be generated.
Tasks
Tasks provide a breakdown of what needs to be completed in order to complete a requirement. An example of a task which could be associated with the above requirement could be to create the credit limit field on the contact record. (Assuming you’re using a CDS database the name, address and date of birth fields should already exist).
Change Requests
Deviations from the agreed scope, should be logged as a change request. The CMMI process provides a work item which can be associated to the original requirement/s or feature/s being affected by the change and also allows the impact of the change to be documented. The below image shows an example of the change request work item.
Review
The review work item allows users to document meetings within Azure DevOps. These could be review meetings, design meetings or even team meetings. Attendees who are also Azure DevOps users can be selected and other work items which was discussed within the meeting associated for reference. This work item is only available by default with the CMMI process template.
Issue
The issue work item available within the CMMI process template relates to project related problems and is not the same issue work item used within the Basic process template.
The CMMI issue work item allows users to describe the issue as well as detail the corrective actions needed to resolve the issue.
Risk
No project is without risks. Within the CMMI process, these risks can be logged and tracked associated if necessary to the work items it relates to. Within the risk work item users are able to describe the risk, specify the probability as well as make contingency plans that allows everyone (with access) to know what to do in the event that this risk becomes an issue.
Each of these work items have defined standard fields. However, there are also fields available which may not be on the form. The list of available fields which are available within the CMMI process template can be accessed via Microsoft’s Work Item field index page. Additional information related to specified work items can also be found on the:
- Review Meeting Field Reference page
- Change Request Field Reference page
- Requirement Field Reference page
Useful fields
There are some fields which tend to be under the radar but which are really useful during a project if used correctly.
Activity
The activity field is available on the Task work item and dictates the type of work being completed. E.g. the activity could relate to design, testing, documentation or development. This field ties closely to assessing the capacity of team members as team members can be assigned an amount of time for each activity. Populating the activity field on the task provides visibility of how much time has is needed for each type of activity. Previously, the activity field could not be modified in Azure DevOps. However, this is no longer the case. Values can be added/removed from this field without affecting the ability to view the capacity as previously described.
Triage
The triage field is available on the Bug, Change Request, Epic, Feature, Issue, Requirement and Task work item. When the work item is in a state of proposed, this field provides directions on what needs to be done. For e.g. A list of requirements which have been created during analysis may need to be reviewed before the analysis stage is complete. This field allows the team to have visibility of which requirements are pending information or has not yet been reviewed.
Committed
Requirements are often created in Azure DevOps before a decision is made on whether the business wishes to include them or not as this aids collaboration and allows an informed decision which can be looked back on if necessary. The committed field specifies if the requirement is within the scope of the project.
Blocked
Blocked is a standard field available on the Bug, Change Request, Requirement, Risk and Task work item and states that no progress can be made on the work item. An issue could be created and associated to the work item at this point. However, this is a suggested business process and not enforced by Azure DevOps.
Subject Matter Expert
Who are the subject matter experts to refer to in the business if there are questions related to a requirement? The Subject Matter Expert fields allows users to specify one or more team members to be consulted if necessary about the associated requirement. The team members specified must exist as users within Azure DevOps.
Task Type
The task type field is available on both the task and bug work item. It allows users to track work which was planned within the project vs work which has been added retrospectively to correct or mitigate issues.
There are two additional work item templates available within Azure DevOps. The Agile Process and the Scrum Process.
Overview of the Agile Process
There are two process which are based on the agile methodology within Azure DevOps. The Agile and Scrum processes are similar but there are key differences which I’ve mentioned in my previous blog introducing the Azure DevOps processes. This blog specifically aims to provide an overview of the agile process.
The agile process is based on agile principles and allows users to track user stories and tasks at a more granular level than the Scrum process.
The work items of note which are available as a part of the agile process are.
Epics
Epics within the Agile process are the same as Epics within the Basic and CMMI process. They contain the high level process of what is to be delivered. An example of this would be the delivery of different channels e.g phone or chat within a call centre.
Feature
Features are a grouping of functionality that provides business value when delivered. The Feature work item is the same as when used in a CMMI process. E.g telephony integration and call verification features would be required in order to deliver an epic related to the delivery of a telephone channel in a call centre.
User Story
First, user Stories work items are meant to capture the description of what is expected from the end user. User stories are typically captured in the format: As a [user role], I want [goal] so that [defined reason]. The user story work item also prompts for the acceptance criteria to be defined. The acceptance criteria documented in the user story is extremely important, as testers and developers rely on what is documented here to create test cases and solution designs.
Task
As with the CMMI process, a task defines what needs to be completed in order to complete the user story. An example of a task which could be associated with the above requirement could be to create the credit limit field on the contact record. (Assuming you’re using a CDS database the name, address and date of birth fields should already exist).
Issue
The Issue work item in the agile process has the same purpose as the work item in the CMMI process. It relates to project related problems, allowing a resolution and plan to be available and visible to those within the project that need to have access to the information.
Useful fields
Some of the key fields to be aware of within the agile process are:
Story Points
Story Points are associated to user stories to indicates the effort needed to complete the user story. Populating this field allows the velocity to be tracked and enables the standard forecasting functionality.
Acceptance Criteria
The acceptance criteria attribute available on the user story work item allows users to define what conditions must be met in order for the user story to be accepted.
Priority
Setting the priority allows product owners to share what is important for the business and ensures that the user stories with the highest priorities are delivered quicker than those with a lower priority.
If you have been following this series of blogs, you may notice that the Agile process shares many work items with the CMMI process. The image below shows how work items are different between the two processes.
Overview of the Scrum Process
The final process left to cover in this series of blogs is the Scrum process. In my previous blogs, I’ve detailed the differences between the Scrum and Agile process. This blog will provide an overview of the scrum process template.
The Scrum process in Azure DevOps closely resembles the agile process. However, there are key differences. The Scrum process aligns to the Scrum framework and allows:
- Product Owners to manage their Product Backlog. This includes setting the priority, order and business importance for each product backlog item.
- The Development team to review work to be completed using tools such as the Sprint and Kanban board as well as the Sprint Backlog.
- Having sprint planning and retrospectives using third party add-ons. I find this useful for teams which are not co-located
Information about the scrum framework can be found on the scrum.org website.
To manage scrum projects, users are able to create different work items provided in the scrum process template. The work items available in the scrum process are.
Epic
These are meant to contain details of the high level process being delivered. An example of a typical epic could be “Warranty Management”. The development team would be aware that warranty management may be needed but will require detailed requirements (created as product backlog items) in order to estimate and ultimately deliver the epic.
Feature
Features are a groupings of functionality that provide business value when delivered. Product Backlog Items which are focused on delivering the same functionality would likely belong to a feature. Creating and using available warranties could each by features associated to the epic described previously.
Product Backlog Item
Product Backlog Items define the detailed needs of a customer. These are typically written using the format: As a [user role], I want [goal] so that [defined reason] and should have clear and unambiguous acceptance criteria defined. These work items should be created and owned by the product owner.
Task
A task defines what needs to be completed in order to complete the product backlog item. An example of a task which could be associated with the above product backlog could be to create the create a warranty entity/table.
Impediment
Impediments in the scrum process allows the team to keep track of anything that is affecting their productivity or efficiency.
Useful fields
The work items described above contain fields which should be noted. Some of the key fields to be aware of within the Scrum process are:
Priority
Setting the priority allows product owners to share what is important for the business and ensures that the product backlog items with the highest priorities are delivered quicker than those with a lower priority.
Effort
The effort of a product backlog item can be defined to allow the scrum team to analyse if an item can be delivered within a sprint or even if the backlog item needs to be broken down further. The effort defined does not tend to relate to time. Instead, other strategies such as planning poker using the Fibonacci sequence can be used to populate the effort field. When the effort is populated, the product backlog will use the velocity, the requested order and the effort to show product backlog items which can naturally fit into the sprint.
Business Value
The business value field allows the product owner to define how much value the item has to the company. An item that is assigned a higher number should be considered as having more business value than an item that is assigned a lower number.
Acceptance Criteria
The acceptance criteria attribute available on the product backlog item work item allows users to define what conditions must be met in order for the product backlog item to be accepted.
Remaining Work
This field displays the timed effort remaining to complete a task. If using the scrum process, the user will not have access to the original estimate and completed work fields. The remaining work field is used on the task board to track progress made by each team member.
