4 ms·

We do pretty much the same on our team with only items for the current and next release on the board. All other items that might be done are on a backlog board

by loumf 10y ago

We do pretty much the same on our team with only items for the current and next release on the board. All other items that might be done are on a backlog board with lists for bugs and features by priority. We build a new release from that board. So, left to right on the main board: Inbox, v.nextNext, v.next, In process, Review Requested, In Testing, Done.next, Done.nextNext Done lists get moved to a "Releases" board when the version is released. Inbox is triaged once per week to somewhere on the Backlog board or to a current release only if it's urgent or a regression introduced by those releases (like the bug was found in a beta) The key to using Kanban, IMO, is to keep the number of cards pretty low. Use a pull to bring cards on when lists get empty -- do not just keep adding.

sova 10y ago
Yeah a low number of cards <10 is ideal. Single digit if possible.
- EduardMe 10y ago
  Yes, this one is one of the small hacks with high impact!
EduardMe 10y ago
Thanks! I can see a bit different approach in your workflow, which I like. In our lists, we don't track specific releases, the cards are just continuously moving up the chain. In your approach you are tracking releases separately from the backlog. I think the last part you mention, to keep a card limit, is what broke our system from time to time. And the reviewing is probably very important, so stale cards are not kept around for no reason. Is there a special way you organize your backlog board? Such as sorting it in themes of your application, urgency, etc? And do you keep track, if it was an external user request (and from how many) vs internal request (your own ideas) or other metrics? Do you find attaching estimates help, such as effort + impact?
- loumf 10y ago
  > Is there a special way you organize your backlog board? One list for each priority/case-type pair, so High-bug, Medium-bug, ... High-Feature, Medium-Feature, etc' > ... external user request If support made the card, they attach the case. No reporting on this though, it's mostly for followup -- when the card is moved to a Done, we can let the customer know what release it will be in. > estimates We do a very high-level estimate bucket. Mostly to size the release.
  - EduardMe 10y ago
    I like the idea of attaching the case. Not only for following up, but also for reading the whole reason why something should be implemented and it shows the developers that there is a real person with a real pain behind it. Furthermore reading the original case sometimes helps in finding more efficient solutions. > high-level estimate bucket How does this bucket look like? Something like: `within 6 months`, `3 months`, `this month` or kind of effort oriented like `high effort` (takes long), `medium effort`, `low effort` (quickly implemented)?
    - loumf 10y ago
      Effort and in days. Cards that are more than 10 days get broken down.

by loumf 10y ago

sova 10y ago

Yeah a low number of cards <10 is ideal. Single digit if possible.

EduardMe 10y ago
Yes, this one is one of the small hacks with high impact!

EduardMe 10y ago

Thanks! I can see a bit different approach in your workflow, which I like. In our lists, we don't track specific releases, the cards are just continuously moving up the chain. In your approach you are tracking releases separately from the backlog. I think the last part you mention, to keep a card limit, is what broke our system from time to time. And the reviewing is probably very important, so stale cards are not kept around for no reason. Is there a special way you organize your backlog board? Such as sorting it in themes of your application, urgency, etc? And do you keep track, if it was an external user request (and from how many) vs internal request (your own ideas) or other metrics? Do you find attaching estimates help, such as effort + impact?

loumf 10y ago
> Is there a special way you organize your backlog board? One list for each priority/case-type pair, so High-bug, Medium-bug, ... High-Feature, Medium-Feature, etc' > ... external user request If support made the card, they attach the case. No reporting on this though, it's mostly for followup -- when the card is moved to a Done, we can let the customer know what release it will be in. > estimates We do a very high-level estimate bucket. Mostly to size the release.
- EduardMe 10y ago
  I like the idea of attaching the case. Not only for following up, but also for reading the whole reason why something should be implemented and it shows the developers that there is a real person with a real pain behind it. Furthermore reading the original case sometimes helps in finding more efficient solutions. > high-level estimate bucket How does this bucket look like? Something like: `within 6 months`, `3 months`, `this month` or kind of effort oriented like `high effort` (takes long), `medium effort`, `low effort` (quickly implemented)?
  - loumf 10y ago
    Effort and in days. Cards that are more than 10 days get broken down.