Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

About this board #195

Closed
staging-unito-github-app bot opened this issue Sep 14, 2022 · 0 comments
Closed

About this board #195

staging-unito-github-app bot opened this issue Sep 14, 2022 · 0 comments

Comments

@staging-unito-github-app
Copy link

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

@LamTVB LamTVB closed this as completed Sep 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant