Skip to content

Issue board as a workflow tool

Issues in priority order

Background

This is a continuation of the https://gitlab.com/gitlab-org/gitlab-ce/issues/24686. We are now focused on issue board workflows (more below). This issue outlines the problems, identifies our areas of focus, and tracks the progress of this design.

Ways of using boards

  • As a workflow tool
  • Kanban and Scrum use lists like “To Do”, “Doing” and “Done”
  • Lists need to represent stages
  • Labels on issues represent categories like “UX” or “Frontend”
  • As an organizational tool
  • We want users to use GitLab as more than a code repository
  • Projects that only have an issue tracker might use lists like “Bug”, “Feature request” and “User feedback”

Our initial focus is having boards being used as a workflow tool and solving the problems inherent. We will assume our columns have 30ish issues each, and maybe up to 200 at the extreme.

Lists as stages

  • We are directing this feature towards agile teams and they need stages
  • Alternatives:
    • Keep the boards the way they are and trust users
    • Add new entity “Stage” and replace labels as the base for lists
    • Overload Labels even more with the ability to represent a stage (“Exclusive Label”)
  • a new entity ‘Stage’
  • Open questions:
    • Should ‘stage’ map to I2P / Cycle Analytics?
      • Is this just an option, default or mandatory?
      • Do things ever automatically move?
      • Agile boards don’t typically have a ‘review’ stage? Should we add that?
        • Start with what is right for agile boards. We should feel like part of the same flow as I2P - but that doesn’t necessarily mean identical. The conversation will come up if we need to add the other stages
      • Relationship between stages and milestones?
      • What the scope that stages are going to exist in?
      • Can an issue exist in multiple boards?
        • Overlap of teams, horizontal vs. vertical
        • Answer => Yes
        • If an issue exists in multiple boards, and it is moved across a stage in one board, what happens? Are the stages the same across the multiple boards? Or can an issue have multiple stages based on board? Or do we have ‘parent issues’ that group multiple ‘sub issues’. Each sub issue only exists in one board.
    • Assumptions about Stages:
      • There is a clearly defined order
      • Stages can be renamed
      • Show up on individual issues (part of the issue meta data)
      • An issue should only be able to exist in one stage

Boards for sprints

  • Only show what the team is interested in at the moment
  • We have Milestones, but filtering by Milestone is not persistent
  • Possible solution:
    • Configure each board when creating it and assigning a permanent Milestone filter (not part of the filters bar)
    • Extension: Add any kind of filter in configuration. For example, a true UX board that only shows issues tagged “UX”
  • First: add milestone filter
    • Is it a problem that the backlog is limited by milestone?
    • Open question: how does the PM create the backlog? What is that flow/experience?
      • Focus on manual first - can patch automatic, but make sure everything is possible with a baseline manual solution
      • Backlog shouldn’t be a column, use ‘add from all issues’ dialog. Kanban columns aren’t for organizing/managing issues. Our issue list is.
  • Second: other filters, more complex configuration

Manually add issues to board

  • ‘Add issues to board’ (not backlog)
  • Issues added are always added to first stage of the board.
  • (Minor detail, select all would be awesome after a search or filter)

Miscellaneous

  • Having a setup screen would reinforce the idea that board structure should not be changed often
  • If there are multiple boards, there should be a way for GitLab to remember which one you’re most interested in
  • Manual ordering is essential for prioritization (no way to order issues with the same Priority Label)
  • Multi-selecting issues would be great for organization
  • Change background color of card based on label
  • Hard to read issue titles with so much information
  • Explore what the set up flow looks like
  • Always load the last board you were looking at
  • Multi-selecting issues is lower priority
  • Editing multiple issues by selecting them and using the side bar - nice, but lower priority
  • Definitely should simplify cards visually
  • What information can move to exclusively sidebar or hover (?)
  • Background color - interesting thing to explore down the road, low priority for now, but should there be a way to select which label is used, or somehow use priority labels only, etc.

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.

Edited by 🤖 GitLab Bot 🤖