Workflow

The Prioritized Product Backlog is a single requirements document that defines the project scope by providing a prioritized list of features of the product or service to be delivered by the project.
 
The Product Owner develops a Prioritized Product Backlog which contains a prioritized list of business and project requirements written in the form of Epic(s), which are high-level User Stories. The prioritization of items in the Prioritized Product Backlog is based on three primary factors: value, risk or uncertainty, and dependencies. It is also referred to as the Risk-Adjusted Product Backlog since it includes identified and assessed risks related to the project. It also encompasses all approved changes that can be appropriately prioritized in the Prioritized Product Backlog.

Product Owners and Additional Product Owners can prioritize User Stories by clicking on the ‘Prioritize User Stories’ button in the Prioritized Product Backlog and dragging and dropping the User Stories to the appropriate position to change their priority.

The Prioritized Product Backlog has multiple filters that can be used to display a custom view.

 Primary Filters: There are 4 primary filters which are listed below.

1. Search: Type in any keyword to search the Prioritized Product Backlog
2. Priority: Filter by Priority set for User Stories
3. Status: Filter by the Status of the User Stories
4. Relevance: User can select either Show Mine or Show All. Show Mine would filter the Backlog with all the entities that the user is working on

More Filters: Clicking on ‘More Filters’ will open a pop-up where the user can use additional filters to display and save a custom view of the Backlog. The additional filters options:

1. Release: Filter by one or more Releases
2. Epic: Filter by one or more Epics
3. User Story: Filter by one or more User Stories
4. Task: Filter by one or more Tasks
5. Product Owner: Filter by selected Product Owners including Additional Product Owners
6. Scrum Master: Filter by selected Scrum Masters including Additional Scrum Masters
7. Scrum Team member: Filter by selected Scrum Team members
8. Team: Filter by selected Scrum Teams
9. User Story Category: Filter by selected User Story Categories
10. Task Type: Filter by selected Task Types
11. User Story Estimate: Filter by selected User Story Estimates
12. Task Estimate: Filter by selected Task Estimates
13. Start Date: Filter by selected Start Date range

End Date: Filter by selected End Date range

Please refer to the steps below to organize the Prioritized Product Backlog.

• On the top left of the Prioritized Product Backlog, below the primary filters, there is an ‘Organize By’ option where users can organize the Prioritized Product Backlog either by Epics, User Stories, or Tasks. 
• For Product Owners, the default view of the Prioritized Product Backlog is organized by Epics. 
• For Scrum Masters, the default view of the Prioritized Product Backlog is organized by User Stories. 
• For Scrum Team Members, the default view of the Prioritized Product Backlog is organized by Tasks.

• Users can create a custom view of the Prioritized Product Backlog by clicking on ‘More Filters’, entering the filters as required, and then clicking on ‘Save Search’ at the bottom of the page. 
• This way the user preferences can be saved and loaded back later from the ‘More Filters’ section.

• User can click on the ‘+’ button located at the top right corner of the Prioritized Product Backlog to modify columns in the Prioritized Product Backlog. 
• User can also reorder the columns as per their own requirement by holding down a column header and dragging it to the intended position.

Note - Once a user modifies the columns in the Prioritized Product Backlog, the custom view gets saved for that user.

Against a column header in the Prioritized Product Backlog, Users can click on the (<>) icon to sort the Backlog.

Sprint Backlog is a list of the User Stories to be executed by the Scrum Team or the development team in the Sprint. The list of User Stories and their associated tasks to be executed by the Scrum Team in the Sprint is called the Sprint Backlog. 

It is a common practice that the Sprint Backlog is represented on a Scrumboard or task board, which provides a constantly visible depiction of the status of the User Stories and Tasks in the backlog. Also included in the Sprint Backlog are any risks associated with the various tasks. Any mitigating activities to address the identified risks would also be included as tasks in the Sprint Backlog. Once the Sprint Backlog is finalized and committed to, by the Scrum Team, new User Stories should not be added; however, tasks that might have been missed or overlooked from the committed User Stories may need to be added. If new requirements arise during a Sprint, they will be added to the overall Prioritized Product Backlog and implemented in a future Sprint as prioritized by the Product Owner.

• Scrum Masters and in some cases Product Owners (if enabled from the Admin Console) can create a Sprint either by clicking on the Create button in the Prioritized Product Backlog or by selecting the Sprint Backlog option in the left menu inside a Project.
• Fill in all the details in Step 1: Overview section and click ‘Save and Continue’ to create a Sprint.
• Add any files, links, or comments (if required) in Step 2.
• Pull User Stories into a Sprint from the Prioritized Product Backlog in Step 3 of editing the Sprint.

The different Sprint statuses are:

• Scheduled: Once a Sprint Backlog is created for a future date/time, the status of the Sprint is ’Scheduled’ till the Sprint starts.
• Ongoing: A Sprint is ‘Ongoing’ when the Sprint has started but is not yet completed.
• Completed: Once the Scrum Master and in some cases Product Owner (if enabled from the Admin Console) clicks on the ‘Complete Sprint’ button, the status of the Sprint changes to ‘Completed’.

Cancelled: If the Scrum Master or the Additional Scrum Master click on the ‘Cancel Sprint’ button for an ‘Ongoing’ sprint, then the Sprint status changes to ‘Cancelled’.

When a user clicks on the name of a Sprint, it takes them to the Sprint Overview page. Those who have edit access (for example Scrum Master) can edit the Sprint details. Users who do not have edit access can only view the Sprint details.

Note: Once a Sprint is Completed or Cancelled, it cannot be edited.

• User Stories can be added to a Sprint Backlog in Step 3 of editing the Sprint Backlog. User Stories that are not estimated and do not satisfy the Definition of Ready (DoR) cannot be added to a Sprint Backlog 
• The Scrum Master can only pull ‘Not Scheduled’ and ‘Not Completed’ User Stories to the Sprint Backlog in Step 3 of editing a Sprint Backlog
• Selected User Stories can also be removed from the Sprint Backlog by clicking on the ‘Move to Prioritized Product Backlog’ button

• The Scrum Master can only delete a Sprint if a Sprint is ‘Scheduled’
• Once a Sprint is ’Ongoing’, it cannot be deleted. However, there is a provision to cancel an ‘Ongoing’ Sprint

Note - Once a ‘Scheduled’ Sprint is deleted, all User Stories automatically move back to the Prioritized Product Backlog, and the Sprint details are lost forever.

If an ‘Ongoing’ Sprint is cancelled, the User Stories automatically move back to the Prioritized Product Backlog. However, the Sprint status changes to ‘Cancelled’.

A Sprint can be deleted only when the Sprint status is ‘Scheduled’. Once deleted, all Epics/User Stories automatically move back to the Prioritized Product Backlog, but the Sprint details are lost forever and cannot be restored later.

A Sprint is completed only when the Scrum Master clicks on the ‘Complete Sprint’ button.

In case the Sprint is not completed at the planned end date, it becomes overdue, and a notification is sent out to the Scrum Master and Additional Scrum Master(s) of that Team.

The entire Team will get notified of Sprint status changes. However, if a task is moved on the Scrumboard or a User Story is added/removed, only the user(s) who owns or works on it will be notified.

Once the Sprint is ended, all incomplete User Stories move back to the Prioritized Product Backlog with the status ‘Not Completed’. These User Stories can then be available for consideration for future sprints.

The Sprint performance can be checked by clicking on the ‘Reports’ tab in the left menu inside a Project.

A Sprint ends only when the Scrum Master clicks on the ‘Complete Sprint’ button.

A Sprint typically lasts between one-to-six weeks. But different organizations have different working days. The working day's option helps the team plan their work better based on the total time available in the Sprint. In Vabro, 5 working days in a week is considered by default while creating a Sprint Backlog, which can be edited by the Scrum Master depending on holidays or the number of working days in a week for their Scrum Team.

Scrumboard is a tool to plan and track work progress during a Sprint. The Scrumboard generally contains three columns to indicate the progress of the estimated tasks for the Sprint: a ‘To Do’ column, an ‘In Progress’ column, and a ‘Complete’ column for the tasks that have been completed and successfully tested. Some teams may add a fourth column ‘Testing’ for tasks completed but in the process of being tested. By default, three columns are available on the Scrumboard.

At the beginning of a Sprint, all tasks for that Sprint are placed in the ‘To Do’ column and are subsequently moved forward according to their progress. The Scrum Team should change or add to the Scrumboard as required so that the Scrumboard provides visual information and control about the work going on as agreed and committed by the team.

• The Scrum Master, Additional Scrum Masters, and the Scrum Team members can move tasks on the Scrumboard by dragging and dropping them from one column to another.
• Scrum Team members can self-assign Tasks using the assign icon or by moving a Task from the ‘To Do’ to the ‘In Progress’ column on the Scrumboard. A Scrum Team member cannot move a task in the Scrumboard if it is already assigned to another Scrum Team member. 

Note - Once all the tasks of a particular User Story have been moved to the Complete column, then that User Story will be marked as ‘Waiting for approval’. If the User Story is approved by the Product Owner, the tasks of that User Story can no longer be moved from the Complete column.

The Scrum Master and Additional Scrum Masters have the option of adding one extra column to their team’s Scrumboard. In “Step 1: Overview” when creating the Sprint Backlog, select the ‘Add an extra column to the Scrumboard’ option and define a custom column name. 

Note: If an extra column has not been added to the Scrumboard while creating a Sprint Backlog, it cannot be added later.

The Product Owner and Additional Product Owner can approve or reject User Stories within their Epics based on the Acceptance Criteria and Definition of Done (DoD).

• Scrum Team member, Scrum Master, and Additional Scrum Master can add tasks on the Scrumboard by clicking on the ‘Add Task’ button below the corresponding User Story
• Fill in all the details in Step 1: Overview section and click on ‘Save and Continue'
• Add Task Type, Task Estimate, files, links, or comments in Step 2: Details section

To assign Tasks, users can click on the ‘Assign’ icon on the Scrumboard and take responsibility for them. 

Note - The Scrum Master can assign tasks to any Scrum Team member while Scrum Team members can only assign tasks themselves.

• The Scrum Master and the assigned Scrum Team member can delete a Task by clicking on the three dots icon on a Task on the Scrumboard 
• Tasks can be deleted either by clicking on the delete icon in Step 3: Tasks section of editing a User Story or by clicking on the three dots icon while editing a Task
   

Users can filter the Scrumboard by using any of the following filters:

• Search: Type in any keyword to search the Scrumboard
• Team Members: Filter by selected Scrum Team members
• Task Type: Filter by the selected Task Types

A Release is a set of potentially shippable product increments which is made available to users in a production environment. In a typical Scrum Project, releases are planned by a Product Owner in collaboration with the Scrum Master and the Scrum Team which provides information on when releases are to be made and what deliverables are expected to be part of these releases. It is understood that the iterative nature of Scrum may necessitate future adjustments to the planned Releases.

Release Planning Sessions are conducted to plan Releases and create a Release Schedule for the project. A Release Schedule contains information on when various sets of usable functionality or products will be delivered to the customer or what constitutes a releasable increment or Minimum Marketable Feature (MMF). In Scrum, the major objective of Release planning is to enable the Scrum Team to have an overview of the delivery schedule for the product they are developing so that they can align with the expectations of the Product Owner and relevant stakeholders (primarily the Project sponsor).

Many organizations have a strategy regarding the release of products. Some organizations prefer continuous deployment, where there is a release after the creation of specified usable functionality. Other organizations prefer phased deployment, where Releases are made at predefined intervals.

• Product Owner and Additional Product Owner can create a Release either by clicking on the Create button in the Prioritized Product Backlog or by selecting the Release option in the left menu inside a Project.
• Fill in all the details in Step 1: Overview section and click on ‘Save and Continue’
• Add any files, links, or comments in Step 2: Details
• Epics and User Stories can be pulled into a Release in Step 3 of editing a Release

When a user clicks on the Release Name, it takes them to the Release Overview page. The Product Owner and Additional Product Owner can edit the Release details. Once a Release is Completed or Cancelled, it cannot be edited.

• Product Owner and Additional Product Owner can move Epics/User Stories to a Release in Step 3 of editing a Release by clicking the ‘Move to Release’ button
• Selected Epics/User Stories can also be removed from the Release by clicking the ‘Move to Prioritized Product Backlog’ button

The different Release statuses are:

Scheduled: Once a Release is created, the Release status becomes ‘Scheduled’ if the status of all User Stories inside the Release is ‘Scheduled’

Ongoing: A Release is ‘Ongoing’ when the status of at least one User Story changes to ‘Ongoing’

Completed: Once the Product Owner clicks on the ‘Complete Release’ button, the status of the Release changes to ‘Completed’

Cancelled: If the Product Owner clicks on the ‘Cancel Release’ button for an ‘Ongoing’ Release, then the status of that Release changes to ‘Cancelled’

A Release can and most likely will have Epics/User Stories from multiple Sprints.

A Release can only be completed when all User Stories inside the Release are ‘Completed’ and the Product Owner clicks on the ‘Complete Release’ button. In situations, where all User Stories are ‘Completed’ before the Target Release Date, then the Product Owner can end the Release by clicking on the ‘Complete Release’ button.

A Release is completed only when all User Stories inside the Release are ‘Completed’ and the Product Owner clicks on the ‘Complete Release’ button. In case a Release is not manually completed, it becomes overdue, and a notification is sent out to the Product Owner for the same.

The Release dashboard has multiple filter options using which a user can create a custom view for oneself.

• Search: Type in any keyword to search the Release dashboard
• Release Date: Filter by selected date range for the target Release date
• Status: Filter by the status of the Releases

A Release can be deleted only when the Release status is ‘Scheduled’. Once deleted, all Epics/User Stories automatically move back to the Prioritized Product Backlog, but the Release details are lost forever which cannot be restored.

A Project is a collaborative enterprise to either create new products or services or to deliver results as defined in the Project Vision Statement. Projects are usually impacted by constraints of time, cost, scope, quality, people, and organizational capabilities. A Scrum Project involves a collaborative effort to create a new product, service, or another result as defined in the Project Vision Statement.

1. Click the ‘Create Project’ button on the Projects dashboard page or the Projects tab from the top menu to create a Project.
2. Fill in all the details in Step 1: Overview section and click on “Save and Continue”
3. Add Definition of Ready (DoR), files, links, or comments in Step 2
4. Epics and Teams can then be added to the Project in Steps 3 and  4 of editing the Project

The Vabro Tool allows users to choose from various templates to better suit the type of Project being delivered. Currently, you can only use the Scrum framework as a template for creating Projects.

A Project can be either private or public. By default, all Projects are private. A public Project means that anyone who has access to the Workspace can access the Project. A private Project is only accessible to members who are part of the Project and do not show up in search results like public Projects.

Yes, multiple Projects can be created in a Workspace based on the plan opted by you. To know more details, please click here.

• Click on the three dots next to the Project in the Projects Dashboard and select ‘Clone Project’
• You can also clone a Project from the ‘Clone Project From’ dropdown in the Step1 of creating a Project
• Choose ‘Clone Everything’ or ‘Custom Clone’
• Select the artifacts and their properties to be cloned and click ‘Clone’
• A new Project with all the selected artifacts is created.

• Click on the three dots next to the Project in the Project Dashboard and select ‘Edit Project’
• Inside a Project, click on the Project icon or the Project name at the top left corner to edit the Project
• Details like Project name, Visibility, Epics, and Teams can be edited in the corresponding steps respectively

• Click on the three dots next to the Project in the Project Dashboard and select ‘Move to Trash’
• A Project can also be deleted by clicking on the three dots on the top right corner while editing a Project and selecting ‘Move to Trash’

Admin and the person who deleted the Project can restore it by clicking on the user icon at the top right corner and selecting the Trash option. Locate the deleted Project in the Trash folder and click on the ‘Restore’ button.

Note: All items inside the Trash are permanently deleted after 30 days from the date of deletion.

• Click the user icon on the top right corner
• Select ‘Admin Console’
• Select ‘Project Settings’ from the Left menu

An Epic is written by the Product Owner in the initial stages of the project when most requirements are high-level functionalities or product descriptions, and requirements are broadly defined. They are large, unrefined User Stories in the Prioritized Product Backlog.

As the Product Owner gets additional clarity on user requirements, these Epics are then broken down into smaller, more granular User Stories. So, Epics can contain one or more User Stories. These smaller User Stories are generally simple, short, and easy-to-implement functionalities or blocks of tasks to be completed in a Sprint.

1. Product Owner and Additional Product Owners can create Epics either by clicking on the Create button in the Prioritized Product Backlog or by clicking on the ‘Add More’ button in Step 3: Epics section of creating or editing a Project
2. Fill in the Epic title and description in Step 1: Overview section and click on ‘Save and Continue’ to create an Epic
3. Add High-level Estimate (HLE), Epic dependency, files, links, and comments in Step 2: Details section

The Product Owner may create high-Level Estimates for Epics. This will help the Product Owner get an approximate idea of how much time and effort it may take to complete the Epics in the Prioritized Product Backlog. High-Level Estimates may also help the Product Owner plan releases and prioritization of Epics or User Stories.

At times, the development of an Epic or a User Story might be dependent on the development of another Epic. For example, the Login functionality will be dependent on the Signup functionality. This option allows the team to define which Epics are a predecessor to the Epic which is being defined now.

Properly documenting dependencies helps the Product Owner determine the relative order in which Epics should be executed by the Scrum Team. Dependencies also highlight the relationship and interaction between Epics both within the Scrum Team working on a given Sprint and with other Scrum Teams in the project.

There is no limit on the number of Epics that can be created. Users can create multiple Epics as per the Project requirements.

Product Owner and Additional Product Owners can edit their Epics by clicking on the Epic title in the Prioritized Product Backlog.

• Product Owner and Additional Product Owner can clone an Epic from the ‘Clone Epic From’ dropdown in the Step1 of creating an Epic
• Choose ‘Clone Everything’ or ‘Custom Clone’
• Select the artifacts and their properties to be cloned and click ‘Clone’
• A new Epic with all the selected artifacts is created.

1. Product Owner and Additional Product Owner can delete their Epic by clicking on the Delete icon available in Step 3: Epics section while editing a Project and selecting ‘Move to Trash’
2. An Epic can also be deleted by clicking on the three dots at the top right corner while editing an Epic and selecting ‘Move to Trash’

Note: A Project must have a minimum of one Epic so the last Epic cannot be deleted under any circumstances.

1. Admin and Product Owners who have deleted an Epic can restore it by clicking on the user icon on the top right corner and selecting the Trash option
2. From the Trash folder, users can locate the deleted Epic and click on the ‘Restore’ button

The Epic will get restored along with all its User Stories and Tasks which were there at the time of deletion. If the Project to which the Epic belonged is no longer available in the workspace, then the Epic cannot be restored. One must restore the Project first before restoring the Epic.

Note: All items inside the Trash are permanently deleted after 30 days from the date of deletion.

Product Owners can invite Additional Product Owners to an Epic by clicking on the edit icon in Step 3: Epics section of creating or editing a Project.

An Epic needs to have a Product Owner always assigned to it. So, before removing the Product Owner from an Epic, the Admin or Product Owner must invite another user to take over the role. This can be done from the Step 3: Epics section of creating or editing a Project. 

Note: A Product Owner can only be removed from an Epic once the user accepts the invite.

The Product Owner owns an Epic. However, two Additional Product Owners can be added as backup to support the Product Owner in their absence.

User Stories adhere to a specific, predefined structure and are a simplistic way of documenting the requirements and desired end-user functionality. The requirements expressed in User Stories are short, simple, and easy-to-understand statements resulting in enhanced communication among the stakeholders and better estimations by the team.

User Story template and examples.

User stories are often expressed in a simple sentence, structured as follows:

‘As a [persona], I [want to], [so that]’

• ‘As a [persona]’: Who are we building this for? As a team, we must have a clear understanding of the persona of the user. How does the person work, how does he think and what do they care about? We must have empathy for the user
• ‘Wants to’: This covers the intent of the user. What does the user wish to achieve by using this feature? It isn’t about the UI itself, but rather the end goal that the user will accomplish if she uses this feature
• ‘So that’: What is the bigger problem that will get solved if the user is able to successfully implement this feature? It’s the final value that the user derives from this feature

E.g., 1) As a store owner, I want to add items back to inventory when they are returned or exchanged, so that I can track the inventory.

• Product Owner and Additional Product Owner can create User Stories by clicking on the Create button in the Prioritized Product Backlog or by clicking on the ‘Add More’ button in Step 3: User Story section of creating or editing an Epic
• Fill in the User Story Title and Description in Step 1: Overview section and click on ‘Save and Continue’
• Add Estimate, Acceptance Criteria, Definition of Ready (DoR), Priority, Dependency, files, links, and comments in Step 2: Details section

Definition of Ready captures the criteria that a User Story must satisfy before being considered for estimation or inclusion into a Sprint. Definition of Ready puts the onus on the Product Owner to define requirements appropriately before the Sprint Planning Meeting is held.

Definition of Ready is a set of rules applicable to the product backlog items (User Stories). Definition of Ready is a set of criteria that a User Story will have to satisfy before being considered for estimation or inclusion into a Sprint. Definition of Ready puts the onus on the Product Owner to define requirements appropriately before the Sprint Planning Meeting is held. Without well-defined requirements, it will be difficult to get reliable estimates and the Scrum Team will not be able to accurately commit work for a Sprint.

The Definition of Ready should preferably be defined by the Scrum Guidance Body. However, there can be a project or organizational-specific Definition of Ready Criteria that may need to be added or updated by the Product Owner. There may also be additions or updates to the Definition of Ready based on recommendations from the Scrum Team.

During Sprint Planning Meeting, Scrum Team will estimate those User Stories which satisfy the Definition of Ready criteria and commit to the Product Owner the User Stories which they can deliver within the Sprint. Review of product backlog items against the Definition of Ready criteria is a continuous activity as part of the Groom Prioritized Product Backlog process.

Some of the Definition of Ready criteria could be

• User Stories are written in enough detail so that they can be understood by the Scrum Teams and can be used for estimates
• All User Stories should have well-defined Acceptance Criteria
• All related documentation that could provide more clarity about the User Stories should be included
• User Stories should be small enough to be completed within a Sprint.

Each User Story should have its own associated Acceptance Criteria, which are the objective components by which a User Story’s functionality is judged. Acceptance Criteria are developed by the Product Owner according to his or her expert understanding of the customer’s requirements.

The Product Owner communicates the User Stories in the Prioritized Product Backlog to the Scrum Team members and their agreement is sought. Acceptance Criteria should explicitly outline the conditions that User Stories must satisfy for them to be acceptable. Well-defined Acceptance Criteria are crucial for timely and effective delivery of the functionality defined in the User Stories, which ultimately determines the success of the project. At the end of each Sprint, the Product Owner uses these criteria to verify the completed deliverables; and can either accept or reject individual deliverables and their associated User Stories.

Example:

Persona: Janine is a married 36-year-old working professional with a family of three children. She is a busy, successful woman who balances her professional and personal life. She is comfortable with technology and is an early adopter of innovative services and products. She is always connected to the internet through multiple devices and regularly shops on e-commerce portals.

User Story: ‘As an online grocery shopper Janine, I should be able to save and view my draft order from any of my devices so that I can complete the order process at my convenience.’

Acceptance Criteria:

• Every in-progress order must be saved every 5 seconds to the logged-in user account as a draft order
• New draft orders must show up as notifications on any devices the user logs in

Value-based Prioritization places primary importance on the customer represented by the Product Owner and strives to implement User Stories with the highest value first. Such high-value User Stories are identified and moved to the top of the Prioritized Product Backlog.

The Scrum framework is driven by the goal of delivering maximum business value in a minimum time span. One of the most effective tools for delivering the greatest value in the shortest amount of time is prioritization. Prioritization can be defined as determination of the order and separation of what must be done now, from what needs to be done later.

Scrum uses Value-based Prioritization as one of the core principles that drive the structure and functionality of the entire Scrum framework—it helps projects benefit through adaptability and iterative development of the product or service. More significantly, Scrum aims at delivering a valuable product or service to the customer on an early and continuous basis.

Prioritization is done by the Product Owner when he or she prioritizes User Stories in the Prioritized Product Backlog. Once the Product Owner has received the business requirements from the customer and written these down in the form of workable User Stories, he or she works with the customer and sponsor to understand which business requirements provide maximum business value. The Product Owner must understand what the customer wants and values in order to arrange the Prioritized Product Backlog Items (User Stories) by relative importance. Prioritizing a backlog involves determining the criticality of each User Story. High-value requirements are identified and moved to the top of the Prioritized Product Backlog.

Simultaneously, the Product Owner must work with the Scrum Team to understand the project risks and uncertainty as they may have negative consequences associated with them. The Scrum Team also alerts the Product Owner of any dependencies that arise out of implementation.

The Product Owner has to translate the inputs and needs of the project stakeholders to create the Prioritized Product Backlog. Hence, while prioritizing the User Stories in the Prioritized Product Backlog, the following three factors are considered (see Figure 2-7):

1. Value
2. Risk or uncertainty
3. Dependencies

Thus, prioritization results in deliverables that satisfy the requirements of the customer with the objective of delivering the maximum business value in the least amount of time.

User Story Categories help teams organize different parts of the project requirement logically. Some of the User Story categories could be Security, Sign-up, Payment, etc. Vabro allows Admins and Product Owners to define different User Story categories while creating a Project to help organize different types of requirements in the project. Later when User Stories are being created, those could be assigned to different categories.

The Scrum Team estimates the effort required to develop the desired functionality (User Story). The Scrum Master and in some cases Product Owner (if allowed by the Admin in the Admin Console) can then estimate User Stories in Step 2: Details section of creating or editing the User Story.

Estimation Criteria can be expressed in numerous ways, with two common examples being story points and hours. Story point values are used to represent relative, or comparative effort to complete tasks. Hours normally describe the number of hours a Scrum Team member works exclusively on developing the project’s deliverables.

Popular estimation methods that can be used as tools to estimate User Stories are Wideband Delphi, Planning Poker, Fist of Five, and Affinity Estimation.

User Story status is based on the stage of its development cycle. User Story status could be:

• Not Scheduled – User Story has not been moved to any Sprint Backlog
• Scheduled – User Story has been added to a Sprint Backlog
• On-going – User Story is under development as part of a Sprint
• On-hold – User Story was under development but has been put on hold due to some business requirements or changes.
• Completed – All tasks within the User Story have been completed and the User Story has been accepted by the Product Owner
• Not Completed – User Story was part of an earlier Sprint where it was still under development when the Sprint ended. The User Story was then moved back to the Prioritized Product Backlog as Not Completed

At times, the development of a User Story might be dependent on the development of another Epic or User Story. For example, Login functionality will be dependent on the Signup functionality. This option allows the team to define which Epics/User Stories are a predecessor to the Epic/Use Story defined now.

Properly documenting dependencies helps the Scrum Teams determine the relative order in which Tasks should be executed to create the Sprint Deliverables. Dependencies also highlight the relationship and interaction between Tasks both within the Scrum Team working on a given Sprint and with other Scrum Teams in the project.

There are numerous types of dependencies: mandatory and discretionary, internal and external, or some combination of these dependencies. For example, a dependency may be both mandatory and external.

• Mandatory dependencies—Dependencies that are either inherent in the nature of the work, like a physical limitation, or that may be due to contractual obligations or legal requirements. For example, work on the first floor cannot begin until the foundation of the building is complete. Mandatory dependencies are also commonly described as hard logic
• Discretionary dependencies—Dependencies that are placed into the workflow by choice. Typically, discretionary dependencies are determined by the Scrum Team based on past experiences or best practices in a particular field or domain. For example, the team can decide to complete one task before working on another because it is a best practice, but not required. For example, the team may choose to build the door and window frames before the full structure of the wall is in place
• External dependencies—External dependencies are those related to tasks, activities, or products that are outside the scope of the work to be executed by the Scrum Team but are needed to complete a project task or create a project deliverable. External dependencies are usually outside the Scrum Team’s control. For example, if the Scrum Team is not responsible for procuring the materials required for building the walls, then those materials and tasks related to their procurement are considered external dependencies
• Internal dependencies—Internal dependencies are those dependencies between tasks, products, or activities that are under the control of the Scrum Team. For example, installing drywall must be completed before painting the wall can begin. This is an example of an internal dependency because both tasks are part of the project. In this case, it is also mandatory because it is based on a physical limitation. It is not possible to paint the wall before it is dry walled

Product Owner and Additional Product Owner can edit a User Story by clicking on the User Story title in the Prioritized Product Backlog.

• Product Owner and Additional Product Owner can clone a User Story from the ‘Clone User Story From’ dropdown in the Step1 of creating a User Story
• Choose ‘Clone Everything’ or ‘Custom Clone’
• Select the artifacts and their properties to be cloned and click ‘Clone’
• A new User Story with all the selected artifacts is created.

• Product Owner and Additional Product Owner can delete a User Story by clicking on the Delete icon available in Step 3: User Stories section of editing an Epic and selecting ‘Move to Trash’
• A User Story can also be deleted by clicking on the three dots on the top right corner while editing a User Story and selecting ‘Move to Trash’

• Admin and the user who deleted a User Story can restore it by clicking on the user icon on the top right corner and selecting the Trash option
• From the Trash folder, users can locate the deleted User Story and click on the ‘Restore’ button

The User Story will get restored along with all the Tasks that were there at the time of deletion. If the Epic to which the User Story belonged is no longer available in the workspace, then the User Story cannot be restored. A user would have to restore the Epic first before restoring the User Story.

Note: All items inside the Trash are permanently deleted after 30 days from the date of deletion.

Committed User Stories are broken down into specific Tasks by the Scrum Team and compiled into a Task List. This is done as part of the Sprint Planning Meeting.

In Sprint Planning Meetings, the Scrum Team convenes to plan the work to be done in the Sprint. The team reviews each Committed User Story for the Sprint and identifies actionable activities, or Tasks required to implement the deliverables necessary to fulfil the User Story and meet Acceptance Criteria. The Product Owner is present during this meeting in case clarification is required related to the Committed User Stories to help the team make design decisions.

The result of this exercise is a Task List. This is a comprehensive list that contains all the Tasks to which the Scrum Team has committed for the current Sprint. It contains descriptions of each Task. The Task List must include any testing and integration efforts so that the Product Increment from the Sprint can be successfully integrated into the deliverables from previous Sprints. Even though tasks are often activity-based, the level of granularity to which the tasks are decomposed is decided by the Scrum Team.

Committed User Stories are broken down into specific Tasks by the Scrum Team and compiled into a Task List. Tasks can only be assigned to a single person to work on them.

• Scrum Team Member, Scrum Master, and Additional Scrum Master (if allowed by the Admin from the Admin console) can create Tasks either by clicking on the Create button in the Prioritized Product Backlog or by clicking on the ‘Add More’ button in Step 3: Tasks section of creating or editing a User Story
• Fill in the Task title, Description, and Task Type in Step 1: Overview section and click on ‘Save and Continue’

Add Estimate, Files, Links, and Comments in Step 2: Details section

No tasks cannot be broken down into further subtasks. Tasks in Vabro tool are the smallest possible unit of the Vabro Hierarchy.

Task status allows team members to organize Tasks based on the stage of its development cycle. Task status could be:

• To Do – Tasks that have not been worked on by any team member
• In Progress – Tasks that are being worked on by the Scrum Team
• Testing – Tasks that are being tested. This status is defined by the Scrum Master while creating a Sprint Backlog and can be named as per the teams’ requirements
• Complete – Tasks that have been completed by the Scrum Team

Defining different types of Tasks allows for easier management of Tasks in the Scrumboard and the Sprint Backlog. Segregating Tasks under logical categories allows users to easily search and keep track of Tasks. The default Task Types available to users are Create, Design, and Test. Vabro tool also allows users to define their Task Types which are then available to be used for future projects.

Scrum Team Members, Scrum Master, and Additional Scrum Master can edit a Task by clicking on the Task title in the Prioritized Product Backlog.

1. Scrum Team member, Scrum Master, and Additional Scrum Master can clone a Task from the ‘Clone Task From’ dropdown in the Step1 of creating a Task
2. Choose ‘Clone Everything’ or ‘Custom Clone’
3. Select the artifacts and their properties to be cloned and click ‘Clone’

A new Task with all the selected artifacts is created.

• Scrum Team member, Scrum Master, and Additional Scrum Master can delete a Task by clicking on the Delete icon available in Step 3: Tasks section of editing a User Story
• A Task can also be deleted by clicking on the three dots available on the top-right corner while editing the Task.

A deleted Task cannot be restored.

A Workspace enables organizations to define, plan, track, and monitor a project in a single location. You can also review the status, exceptions, and KPIs in the workspace to take further actions for the project.

Workspaces are at the top level of Vabro Hierarchy. Each Workspace is further organized into Projects. One can join or create multiple Workspaces, but it is important to consider that each Workspace is completely independent.

• A Workspace can be created by clicking on the user icon on the top right corner and selecting ‘Switch Workspace’ and clicking ‘Create a Workspace’
• Enter the Workspace Name and Work Email Address
• The Workspace will be available for use after verifying the verification email sent to the Work Email Address

• A user can join a Workspace by clicking on the user icon on the top right corner and selecting ‘Switch Workspace’ and clicking ‘Join a Workspace’
• Enter the Workspace Name, Work Email Address, or Current Email Address and click ‘Submit’
• The Workspace can be used once the Admin approves the join request

1. Users can navigate between Workspaces by clicking on the user icon on the top right corner and selecting ‘Switch Workspace’
2. All Workspaces created by the user as well as the Workspaces that the user joined are listed and users can click on a Workspace to switch

1. Click the user icon on the top right corner and select ‘Admin Console’
2. Select ‘Workspace’ from the left menu
3. Details like Domain settings, Workspace Name, Website, Logo, Address, and Storage details can be managed by selecting the respective tabs from the top menu.

• Click the user icon on the top right corner and select ‘Admin Console’
• Select ‘Workspace’ from the left menu
• Click on ‘Email Domain’ in the top menu
• Select the ‘Specific Domains’ radio button and enter the email domains to be allowed using which users can join the Workspace
• All other email domains will not be allowed to join the Workspace

Each user who signs up with Vabro will get access to a Personal Workspace. Users can then create Company Workspaces depending on their current plan. To know more details, please click here. The person who creates the Workspace will become the Admin of that Workspace by default.

A Workspace cannot be deleted. Additional Workspaces can be created by:

• Clicking on the user icon on the top right corner and selecting ‘Switch Workspace’ and clicking ‘Create a Workspace’
• A user can create a new Workspace by providing a Workspace Name and Work Email Address
• The Workspace will be available for use after verifying the verification email sent to the Work Email Address

1. Click the user icon on the top right corner and select ‘User Settings’
2. Select 'Invite People’ from the left menu
3. Under the ‘Send Invites’ tab, enter multiple commas separated email addresses and click on ‘Invite’ to invite people to join the Workspace

• Click on the user icon on the top right corner and select ‘Admin Console’
• Select ‘Users’ from the left menu
• Click on ‘Users’ in the top menu to view the users
• Admin and Additional Admin can remove a user by clicking on the three dots in the ‘Action’ column for the user and selecting ‘Remove’
• The user will be removed from the Workspace. However, all artifacts that the user owned or worked on will stay assigned to the user

A Workspace is owned by the Admin. However, up to two Additional Admins can be added as backup to support the Admin in their absence.

• A Team can be created in Step 4 of creating or editing a Project inside a Workspace.
• Click the ‘Add Team’ button on the right and enter the desired name for the Team
• The person who creates the Team will become the Scrum Master by default
• Additional Scrum Masters and Scrum Team members can be invited on the same page

• There is no limit on the number of Teams that can be created. A Product Owner, Additional Product Owner, Scrum Master, and Additional Scrum Master can create as many Teams as the Project needs
• The person who creates the Team will become the Scrum Master of that Team by default

A Team can have unlimited members by default. However, the Admin or Scrum Master can specify a maximum limit from the Team Settings in Admin Console. We recommend Scrum Teams have 6 to 10 members ideally.

• Team details can be edited in Step 4: Teams section while editing a Project
• Select the Team and make changes like renaming the Team, selecting the number of members in the Team, assigning Scrum Masters, Additional Scrum Masters, and Scrum Team members

A Team comprises a Scrum Master, up to two Additional Scrum Masters, and Scrum Team members.

A Scrum Team cannot be deleted. Additional Teams can be created in Step 4: Teams section while creating or editing a Project.

A Scrum Team cannot be part of multiple projects. However, Scrum Team members can be a part of different Teams in other Projects.

A Team needs to have a Scrum Master always assigned to it. So, before removing the Scrum Master from a Team, the Admin, Product Owner, or Scrum Master must invite another user to take over the role. This can be done from the Step 4: Teams section of creating or editing a Project.

Note: A Scrum Master can only be removed from a Team once the person to take over the role accepts the invite.

1. Team details can be edited in Step 4: Teams section while creating or editing a Project
2. To invite/assign an Additional Scrum Master, click in the Additional Scrum Masters box, enter the name, or email address of the Additional Scrum Master to be invited
3. User can accept the invite and join the Team as an Additional Scrum Master

Up to two Additional Scrum Masters can be added as back-up to support the Scrum Master in their absence. Additional Scrum Master also joins the Team as a Scrum Team member.

• Team details can be edited in Step 4: Teams section while creating or editing a Project
• To invite or assign Scrum Team members, click in the Scrum Team members box, enter the name, or email address of the users to be invited
• User can accept the invite and join the Team as a Scrum Team member

• Team details can be edited in Step 4: Teams section while creating or editing a Project
• To remove a Scrum Team member, click on the ‘x’ button next to the Scrum Team member’s name