Mix Scrum and Kanban
Scrumban is a hybrid methodology that borrows elements from both Scrum and Kanban, hence the hybrid name. This board is configured to use sprints as they would be used for Scrum development, but these sprints are not scheduled.
The agile board that we use to manage the publication of the content that you're reading right now uses a mix of Scrum and Kanban frameworks. Here's what this scrumban board looks like in our YouTrack installation:
There are a few reasons why this works for us:
The YouTrack developers use a Scrum framework to deliver updates on a continuous basis. However, the actual delivery of new functionality is typically scheduled for one of our quarterly releases. We use these release cycles as the time box for updating the documentation, so the sprints on this board include a collection of updates to be published for the release.
We only really know which features will be finished and delivered in the release after we see them in the sprint demo. This means that our backlog doesn't contain a predefined set of tasks. Instead, we create tasks directly on the board whenever a developer demonstrates a feature that requires changes to the documentation.
We manage the sprint backlog using a Kanban-style pull system. Whenever we're ready to work on something new, we just pull a card from the column for open tasks and start to work on the issue.
This type of board can be useful for any team that uses a hybrid agile framework.
To build a Scrumban board:
Create your board.
Use the Scrum board template.
Select the projects that you want to manage on the board.
For the Backlog option, choose Create new. You can customize the backlog later.
Edit the first sprint.
Our board uses sprints that correspond to major releases in YouTrack and Hub, however, we only assign each sprint a name.
All sprints are unscheduled.
Set sprint options and board behavior.
When you create a board with the Scrum board template, the Sprints option is enabled by default.
We either pull issues from the backlog or add them manually to the board, so we don’t use any options that add issues to the board automatically.
Define columns.
On our board, columns are identified by values from the State field. We have separate columns for:
Open and Reopened (merged)
In Progress and Wait for Reply (merged)
- In Review
- Ready
- Published
Define swimlanes.
On our board, swimlanes are identified by issues that are assigned the Epic value in the Type field. We show the swimlane for uncategorized cards at the bottom of the board.
Configure cards.
When we add a card to the board, the default value for the Type field is Task. The Color Scheme is based on the set of values for the Priority field. We also enabled the option to show colors for other custom fields.
Pick a chart.
We use the Cumulative flow diagram. This chart best represents our Kanban-style process.
Build the backlog.
We use the backlog to filter out issues that we don’t want to manage on this board. Our backlog uses the following saved search:
project: {Ring Docs} Subsystem: -Wording,-Screencasts #Unresolved has: -{Board Ring Docs}
This search query:
Shows only issues that belong to our project (Ring Docs)
Excludes issues from specific subsystems (Subsystem: -Wording, -Screencasts)
Shows only issues that are unresolved (#Unresolved)
Excludes issues that are already assigned to a sprint on the board (has: -{Board Ring Docs})
