Documentation

DevGob documentation

Learn how DevGob organizes work, governs changes on their way to production, and keeps each organization's information separate. Start with the basics, then go to the area you need.

Start here

Three steps from no account to a project you can plan work in.

  1. 1

    Request a workspace

    Every organization gets its own workspace at your-team.devgob.com, with its own users, projects and data. Request one from the public form; an administrator reviews it before it is activated.

    Request a workspace
  2. 2

    Sign in to your workspace

    Sign in at your organization's own address. If you only know the workspace name, the sign-in page will find it for you and send you to the right place.

    Go to sign in
  3. 3

    Set up your first project

    A workspace holds projects; a project holds teams, a backlog, sprints and deployments. The work-item types, states and transitions are configured per workspace, so the process can match how your organization already works.

Browse by area

Each area below describes what the product does, not what it plans to do.

Work items

The unit of work, and the hierarchy that organizes it.

  • Hierarchy: Epic → Feature → Product Backlog Item → Task.
  • Plus Bug, Issue, Impediment, Pre-release Defect and Support for work that does not fit the hierarchy.
  • Types, states and the transitions between them are configured per workspace — not fixed by the product.
  • Every item carries a readable reference such as PAGOS-364 for people to quote in conversation.
Read the article

Backlog and boards

Order the work, then watch it move.

  • A product backlog per project, with triage for incoming items.
  • Drag-to-reorder priority, kept per team.
  • Boards by state, with the columns your process defines.
  • Filters by type, state, assignee, iteration and team.
Read the article

Sprints and capacity

Plan an iteration against the hours you really have.

  • Iterations with start and end dates, per team.
  • Capacity per person, accounting for holidays and days off.
  • A burndown of remaining work across the iteration.
  • Retrospectives recorded against the sprint they belong to.
Read the article

Deployment governance

The part that makes this more than a task tracker: a change goes to production through a governed, evidenced workflow.

  • Eleven phases: New, Development, Code Review, Test, To Committee, Committee Authorized, Installed Pre, To Committee Prod, Committee Prod Authorized, Installed Prod, Done.
  • Each phase has an owner role and a condition for leaving it.
  • Two committee gates, not one: a change is authorized separately for pre-production and for production, each recorded with who gave the authorization and when.
  • Install evidence captured for both pre-production and production.
  • A production rollback opens a linked bug automatically, at the highest severity, so nothing is lost in the hurry.
Read the article

Reports and dashboards

What is happening, without asking anyone.

  • A dashboard per project with the state of the current iteration.
  • General reports covering work items, deployments and overdue work.
  • Charts rendered by the server — nothing to install, nothing to load.
  • Export to CSV for anything you need to take elsewhere.
Read the article

Roles and permissions

Who can do what, decided by role rather than by person.

  • System roles — SuperAdmin and Workspace Administrator — are fixed by the product and cannot be edited.
  • Functional roles are editable templates: Product Owner, Scrum Master, Tech Lead, Developer, QA, Release Manager, Committee Approver, Stakeholder, Auditor.
  • Permissions are granular actions on a resource, granted to a role and never to an individual.
  • Administering the system and governing the work are deliberately separate: a project manager cannot grant themselves permissions.
Read the article

Administration

Everything a workspace administrator controls.

  • Users, authorized email addresses and role assignment.
  • Single sign-on with Microsoft Entra ID, Google or any OIDC provider.
  • GitHub integration, linking branches and pull requests to work items.
  • Work calendars, storage quotas and the workspace's own plan.
Read the article

Security and data isolation

How one workspace's information stays that workspace's information.

  • Each workspace is resolved from its own subdomain before anything else happens, and every query is scoped to it.
  • Passwords hashed with bcrypt; optional two-factor authentication.
  • An append-only audit log covering state changes, permission changes and denied access.
  • Deleted records are marked, not erased, so history stays reconstructable.
Read the article

Language and accessibility

Usable by the whole team, not just part of it.

  • Full interface in Spanish and English, switchable at any time.
  • Dark and light themes, remembered per person.
  • Built to WCAG 2.1 AA: keyboard navigation, contrast, screen readers.
  • Works on a phone — the same screens, laid out for a small display.
Read the article

Still have a question?

If something here does not answer what you need, ask us directly — a person reads every message.