You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This board supports a development Kanban flow that I've used with good results. Whatever structure you follow should be adapted to your team and tweaked over time for best results. Being a Kanban flow, you should also set a maximum Work In Progress limit for each list.
Inbox
This list works as the general input area for stuff that gets found or happens as part of the product's operation and development process.Anything the development or support team identifies goes in here.
As PM / PO, you can sort it out and prioritize it, sending it directly to the Kanban backlog, to the Sandbox board, or added to some Epic on the roadmap (some new requirement that was found).
Support Backlog
The QA and Customer Support teams should have their own backlog, since they usually have the autonomy to implement many tasks they identify. If it's something that requires engineering effort, it should end up in the Dev Backlog
Dev Backlog
This is the main Engineering pipeline. Depending on your team, you may split it under Backend / Web / Mobile, or whichever structure makes sense for you. This is the prioritized list of items to work on next and it's managed by the PM / PO. Items may come from anywhere: the Epics board, the Inbox or the Engineering board.
It's easy for this list to get too big. You should manage it carefully and keep it small, so clutter doesn't accumulate. Make full use of the other boards (Epics and Engineering), to move things out of the development backlog if their priorities change
Blocked
Sometimes cards may get blocked after being in progress. Missing design assets, specs, waiting on some external team, etc... stuff that was previously started but is now waiting for something to happen that’s outside the team’s responsibilities.
It's useful to have a list where these situations are visible, so they can be solved as quickly as possible by the team, Agile Coach / Scrum Master or Product Owner / Manager. The goal is for this to be empty.
In Progress
Easy enough. What the team is working on right now. It's useful for team members to assign themselves to the card(s) they're working on, so it's easier to track who's doing what.
We make heavy use of comments (with @mentions, so we get notifications) and attach any relevant documents and information as development moves forward. If something gets blocked, it goes to that board and the person picks up a new card from the backlog.
CI
As stuff comes to the Continuous Integration environment, the team ensures that tests are passing. The QA team also does a review of the feature to check it’s all as expected. Then, it can move forward to the next environment.
Staging
A similar flow to CI is also applied here. This environment is either: virtually the same as Production or it represents the next version that will be shipped. Another round of manual tests by the QA team, as well as the PM / PO are critical to ensure feature correctness. If anything needs reviewing, it goes back to the Backlog.
Production
These lists represent what was deployed to Production on which dates, and thus there are many of them. After shipping, to keep the Kanban board more manageable, you may archive them or send them to a Changelog board for ease of search and documentation.
This board supports a development Kanban flow that I've used with good results. Whatever structure you follow should be adapted to your team and tweaked over time for best results. Being a Kanban flow, you should also set a maximum Work In Progress limit for each list.
Inbox
This list works as the general input area for stuff that gets found or happens as part of the product's operation and development process.Anything the development or support team identifies goes in here.
As PM / PO, you can sort it out and prioritize it, sending it directly to the Kanban backlog, to the Sandbox board, or added to some Epic on the roadmap (some new requirement that was found).
Support Backlog
The QA and Customer Support teams should have their own backlog, since they usually have the autonomy to implement many tasks they identify. If it's something that requires engineering effort, it should end up in the Dev Backlog
Dev Backlog
This is the main Engineering pipeline. Depending on your team, you may split it under Backend / Web / Mobile, or whichever structure makes sense for you. This is the prioritized list of items to work on next and it's managed by the PM / PO. Items may come from anywhere: the Epics board, the Inbox or the Engineering board.
It's easy for this list to get too big. You should manage it carefully and keep it small, so clutter doesn't accumulate. Make full use of the other boards (Epics and Engineering), to move things out of the development backlog if their priorities change
Blocked
Sometimes cards may get blocked after being in progress. Missing design assets, specs, waiting on some external team, etc... stuff that was previously started but is now waiting for something to happen that’s outside the team’s responsibilities.
It's useful to have a list where these situations are visible, so they can be solved as quickly as possible by the team, Agile Coach / Scrum Master or Product Owner / Manager. The goal is for this to be empty.
In Progress
Easy enough. What the team is working on right now. It's useful for team members to assign themselves to the card(s) they're working on, so it's easier to track who's doing what.
We make heavy use of comments (with @mentions, so we get notifications) and attach any relevant documents and information as development moves forward. If something gets blocked, it goes to that board and the person picks up a new card from the backlog.
CI
As stuff comes to the Continuous Integration environment, the team ensures that tests are passing. The QA team also does a review of the feature to check it’s all as expected. Then, it can move forward to the next environment.
Staging
A similar flow to CI is also applied here. This environment is either: virtually the same as Production or it represents the next version that will be shipped. Another round of manual tests by the QA team, as well as the PM / PO are critical to ensure feature correctness. If anything needs reviewing, it goes back to the Backlog.
Production
These lists represent what was deployed to Production on which dates, and thus there are many of them. After shipping, to keep the Kanban board more manageable, you may archive them or send them to a Changelog board for ease of search and documentation.
┆Issue is synchronized with this Trello card by Unito
The text was updated successfully, but these errors were encountered: