Skip to main content

Project Terms

Familiarize yourself with common terms and acronyms used in DevOps and for Project Operations at Rizing below.

Project Methodology Terms​

Initiate / Inception is the first project phase and includes the Project Management Workflow. Objectives of this phase include:

  • setting up project governance and project operations tooling
  • assigning team roles
  • ensuring project success criteria is understood by team members and client stakeholders

Requirements is the next project phase and begins part one of Project Implementation Workflow. Objectives include:

  • gathering/preparing a thorough list of requirements and/or user stories from the client
  • developing a comprehensive set of use cases that define core requirements and describe user interaction and system behavior in detail
  • determining the project work plan and delivery milestones

Design is the next project phase and represents part two of the Project implementation workflow. Objectives include:

  • preparing design specifications that describe the technical and security architecture for the application
  • developing wireframes and mockups to flesh out use case scenarios and remaining functional requirements
  • adding design details to requirements/user stories in DevOps
  • creating a test plan

Development is the next project phase and begins the Development workflow. Objectives include:

  • establishing the database and development environments
  • implementing the requirements/user stories and turning use cases and design specifications into code
  • writing test cases to verify requirements are met and system is bug free

Release / Deployment is the next project phase and continues the Development workflow. Objectives include:

  • creating PRs and moving requirements/user stories to a resolved state
  • running the test cases to verify requirments are met and system is bug free
  • merging PRs and creating application releases and deployments

Maintenance is the last project phase and concludes the Development workflow. Objectives include:

  • ongoing support of the software

DevOps Terms​

Agile​

Agile is a term used to describe an approach to software development that emphasizes incremental delivery, team/stakeholder collaboration, continual planning, and continual learning, instead of trying to deliver it all at once near the end.

Agile project teams are cross-functional and use a dynamic process where feedback is gathered and implemented continually. Everyone works together on iterations of a product over a period of time, and the work is organized into a backlog that is prioritized based on business/customer value and incremental delivery.

The process allows for changing requirements and encourages constant feedback from the end users. Learn more about agile software developmen.

CMMI​

CMMI follows the waterfall approach and is a structured process where the team doesn't start on a new phase until the previous one has been completed. The process is linear and stakeholder and customer requirements are gathered at the beginning of the project, and then a sequential project plan is created to accommodate those requirements, usually for a fixed contract price.

The process is more rigid and typically does not allow for changing requirements or adjusting the project scope without the client submitting a change request to the original contract.

Scrum​

An adaptive product development strategy where a cross-functional team works as a unit to reach a common goal within 2-4 week Sprints.

Work Items​

Work items, also referred to as work item types (WITS) are used to track different types of information in DevOps. Each work item represents an object stored in the work item data store. Each work item is based on a work item type and is assigned an identifier which is unique within an organization or project collection. Example work item types include user stories, epics, tasks, etc. The work item types available to you are based on the process used when your project was created (Agile, Basic, Scrum, or CMMI). Work items can be added directly from the Kanban Board and the Backlog.

Boards​

Kanban boards present work items in a board view. They are a highly visual workflow management method used by project teams to visualize and actively manage the creation of products with an emphasis on continual delivery, while not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively.

💎 Tip: "Boards" and "Backlogs" contain the same work items, the only difference is how they are displayed.

Backlogs​

Backlogs present work items in a list format. A product backlog represents your project plan, the roadmap for what your team plans to deliver. Your backlog also provides a repository of all the information you need to track and share with your team.

💎 Tip: "Boards" and "Backlogs" contain the same work items, the only difference is how they are displayed.

Epics   (Agile + CMMI)​

Epics are a type of work item used to represent a large “chunk” of work to be completed or a business initiative to be accomplished. For example, if utilizing a detailed work plan for a large project, Epics may represent milestones in the workplan such as a group of requirements/features for a phase of work being delivered. Examples:

  • High performance
  • Intersection editing
  • External integrations

Features   (Agile + CMMI)​

Features are a type of work item used to represent a shippable component of software. Examples:

  • Map interface for discovery and visualization of intersections
  • Ability to query routes using text search
  • Ability to send email notifications from the SLD

User Stories   (Agile Only)​

User Stories are a type of work item used to represent a functional increment of work. The basic user story structure is as follows:

As a [type of user], I want [some feature] so that [some reason]

Using one of the features from above, Map interface for discovery and visualization intersections, example user stories might be:

  • As a user, I want to perform a search that discovers intersections on the map so I can easily visualize my results
  • As a user, I want the ability to change the style of the base map layer to more easily view assets displayed over top
  • As a user, I want to view details of a single discovered point on the map to quickly determine its accuracy

💡 Note: The term "user" should be modified to match the end user; “user”, “administrator”, “editor”.

Tasks   (Agile + CMMI)​

Tasks are a type of work item used to track the individual elements of work needed to support the completion/implementation of a user story or requirement. Examples:

  • Add standard navigation tools
  • Add basemap widget
  • Add a content panel for map display

Bugs   (Agile + CMMI)​

Bugs are a type of work item used to record a potential source of dissatisfaction with the product. They are the common name of a work item type used for tracking code defects.

Issues   (Agile + CMMI)​

Issues are a type of work item that helps track unplanned activities that may impact the completion of other work. Resolving an issue or impediment requires more work beyond what was scheduled based on actual requirements. Using the issue (Agile or CMMI process) work item type helps you track and manage these issues until you can resolve and close them.

Requirements   (CMMI Only)​

Requirements are a type of work item used to represent a functional increment of work. Using one of the features from above, Map interface for discovery and visualization intersections, example requirements might be:

  • Ability to perform a search that discovers intersections on the map
  • Ability to change the style of the base map layer
  • Ability to view details of a single discovered point on the map

Change Requests   (CMMI Only)​

Change Requests are a type of work item used to manage proposed changes to any project or product that are under change control and go beyond what was scheduled and documented in the requirements.

Reviews   (CMMI Only)​

Reviews are a type of work item used to document the results of a design or code review meeting. Reviews can be useful if your project team needs to track code relevance, extensibility, complexity, code security, etc.

Risks   (CMMI Only)​

Risks are a type of work item used to track the probability and degree of variance between actual and desired outcomes.

Area Paths​

Area Paths are used to support your team's trace-ability and security requirements. Use areas to represent logical or physical components, and then create child areas to represent specific features. Add areas when you have these requirements:

  • Filter queries based on a product or feature area
  • Organize or group work items by team or sub-teams
  • Restrict access to work items based on their area.

Iteration Paths​

Iteration paths allow you to group work into sprints, milestones, or other event-specific or time-related period. Add iterations when you need to support these requirements:

  • Define sprints your development teams use to plan and execute their sprints
  • Set up more complex multi-release and sprint cycles
  • Filter queries based on sprints, milestones, or cycle time for your project
  • Support future work that you're not ready to assign to a target release cycle

Queries​

A query lists a filtered set of work items. You can initiate a query using the query editor. Optionally, you can perform an ad hoc search using the search box.

Microsoft Terms​

Groups​

Microsoft Groups is the cross-application membership service in Office 365. Members added to a Group share common access to a SharePoint team site, Yammer Group, shared Exchange mailbox resources, Planner, Power BI and OneNote.

For more information about Microsoft 365 Groups, see Learn about Microsoft 365 Groups.

🔥 Heads Up: When adding new members always add them to the Team (see Teams below), not to the Group in Outlook. When you add a new member using Teams they are automatically added to both the Team and Group and have immediate access to the shared Group resources including the SharePoint team site, Yammer Group, shared Exchange mailbox resources, Planner, Power BI and OneNote.

Teams​

Microsoft Teams are a collection of people, content, and tools surrounding different projects and outcomes within an organization. Teams can be dynamic for project-based work (for example, launching a product, creating a digital war room), as well as ongoing, to reflect the internal structure of your organization (for example, departments and office locations). Conversations, files and notes across team channels are only visible to members of the team.

🔥 Heads Up: Always create a Team using the option in Teams to create it using an existing Group. When a team is created from an existing group, the Group and Team are "synced" in the membership service and new members added to the Team are automatically added to both the Team and Group and have immediate access to the shared Group resources: SharePoint team site, Yammer Group, shared Exchange mailbox resources, Planner, Power BI and OneNote.

Channels​

Channels are dedicated sections within a Microsoft Team to keep conversations organized by specific topics, projects, disciplines—-whatever works for your team! Files stored on a channel's "Files" tab are stored in the Groups SharePoint team site in the "Documents" library. To learn more, read How SharePoint Online and OneDrive for Business interact with Teams.

Document Libraries​

Document Libraries (named "Documents" by default) provide a secure place on your project teams SharePoint site to store files where you and your co-workers can easily find them, work on them together, and access them from any device at any time. Adding files or moving files between folders is as easy as dragging and dropping them from one location to another.

💡 Note: You can create as many additional document libraries as you'd like on the teams shared SharePoint site, however in Teams only the default "Documents" library is synced to and viewable from the Files tabn.