Review and Baseline

A Baseline is simply a snapshot of any list of work items.

Why is this useful? 

A Baseline allows you to identify and manage the changes in requirements.
You can use Baselines to roll back a full set of work items if necessary. This allows you to capture all of your Release or Iteration work items and roll them back if the requirements go awry. 

You can also send a Baseline of work items to a new Server, Collection, and Project which means you can now reuse requirements from one project to another. We also support the ability to create repositories or libraries of reusable requirements!

Baselines can also be compared to each other.
This means you can easily capture requirements between two separate releases and compare how the requirements have changed over the course of two releases. 

Baselines are powerful tools, and by keeping them easy to make, your team can have all of these benefits with very little added effort!

There are many great times to create a Baseline. 

From a workflow perspective there are a few great times where creating a Baseline can be very effective. 

The goal of a Baseline is to capture change.
This means that if you are creating a review (facilitating change) you may choose to make a Baseline before you send requirements for approval, and then after to capture how requirements changed during that process.

You can also use the Baseline tool to compare how requirements have changed over larger courses of time. This might be identifying how requirements have changed over the course of an iteration, or how requirements changed between two releases. 

Missed a Baseline?
No worries!

When you create a Baseline you not only choose the work items you would like to capture, but you can also choose on which date from the past you would like to capture them at. 

This means if you forgot to make a Baseline for the starting point of iteration one, you can easily capture those requirements from the day iteration one started easily. 

You absolutely can.

Baselines typically store a group of requirements. This makes a Baseline a perfect way to group the requirements you want to reuse in another project together. We have included the ability to “Copy Baseline” directly into our Baseline module for this very reason. This feature lets you take your Baseline and send it to another project. 

The Reuse tool has several great functions.

Primarily, the Reuse tool allows you to select any group of requirements and reuse them in another project.

This tool supports: 
– pulling in Baselines from another project into your current project
– sending requirements from your current project to another project
– building up repositories and/or libraries of requirements

No. 

There is a process you can employ which allows your team to change the source work item, aka the work item you have been pulling into your projects from a repository, and have those changes be reflected everywhere you have pulled that requirement into. 

Azure DevOps at its core works by explicitly linking work items to each other.

This means that if you Reuse a work item, you can tick “Link with Source work item” and you will be able to see an explicit link back to your Source work item. You can see this in the Traceability Matrix, or simply open up the work item to see a link to its Source. 

Reviews can be initiated in many different places throughout the application. 

The main places people tend to build Reviews from are:

1. Native Azure DevOps – you can create reviews from the backlog, sprints, or query views
2. Smart Docs module – you can create document reviews from the Smart Docs module
3. Review Module – you can create a review from scratch directly from the module itself.

There are different reasons you might want to invoke a review from these places and as you use Modern Requirements you will find times where one is more effective than another. 

Reviews are stored within the Review module itself. 

As a review is completed, closed, or cancelled, it will be archived in its appropriate folder, but it never leaves the Review module itself. 

Reviews are free to participate in, even for Stakeholders! 

Anyone with an account that can access your team’s project can participate in a review. This means you can have anyone with an account participate as a Reviewer or Approver provided they have project access.

While participating in a review, comments are the driving force of the review. 

When you set someone as a “Reviewer” in your review, they will only be able to provide comments that direct how that work item should change. 

Everyone in the review will be able to see everyone’s comments. This means a conversation is needed to facilitate the changes to requirements. After enough comments, an “Approver” will mark a requirement as “Approved” or “Rejected”, and they will be able to say why using comments of their own. 

After this, the person who sent the review knows exactly which requirements need to change and how. They can then open up a requirement and make the necessary changes. 

In the case of an Approver needing to change how they have marked a requirement, they can easily mark a rejected work item as approved and vice versa. This action is no different that marking that requirement as such originally. 

Our Review module is CFR 21 Part 11 Compliant. 

We offer the option to require e-signatures for people to be able to approve or reject any given work item.

We even allow your team to create Single-Click Audit Reports that show, with timestamps, all of the actions that have been taken during the Approval process.