3 ms·

Thanks for the tips! A card limit is something I just discovered recently and a great suggestion. I also like the idea of having the feature requests in a diff

Thanks for the tips! A card limit is something I just discovered recently and a great suggestion. I also like the idea of having the feature requests in a different view or even different system. I used to collect all features and bugs inside a note-taking app on my mac. This worked well until I hit 100 or so items. It's true, the important things come up again and again, but sometimes it's a small group of very noisy users, which skew the true numbers. Or it comes from people using your trial, who are not your ideal customers. So I would like to track how many and which users are requesting something. Just to avoid biases and loud users with their edge-cases. What's your experience with this? Regarding the kanban columns. You know other column systems and workflows, which are maybe more suitable? Another point we missed out earlier is to review the cards and throw away stale ones.

olegious 10y ago
I think you have to always be focused on whatever top level goal/metric/OKR you're currently focused on and then define and test hypotheses that you think will get you to there in the fastest way possible. Think of it this way, if your current goal is to improve metric X by Y % then you should only be focused on ideas, hypotheses and feedback that can get you there, ignore everything else. In terms of columns, I like simplicity: Backlog -> Development -> Test -> Done Depending on your workflows, between "Test" and "Done" you can have a "To Be Deployed" column. This assumes that all features in the Backlog have been validated. My process there is: OKR (metric) -> Hypothesis (how will I meet this OKR?) -> Assumptions (what risky assumptions am I making in the hypothesis?) -> Experiment design (how can I prove/disprove the assumption?) -> Experiment -> review outcome and either discard the hypothesis or build it out to production level. In this workflow, items make it into the Backlog at the Experiment and "build out" stages. So you come up with an experiment that may require engineering effort, that's a card in your backlog. Your experiment validates your hypothesis, so you want to put more resources into the hypothesis, so that creates more cards to fully build out the feature. edit: I always liked this post by UserVoice because it shows you how far you can take these things, I wouldn't necessarily use their workflow, but it is interesting: https://community.uservoice.com/blog/trello-google-docs-product-management/ https://community.uservoice.com/blog/trello-google-docs-prod...
- EduardMe 10y ago
  Thanks for the link! Loved the point about capturing user stories: > Good specs tell the (customer) and business story rather than act as an implementation recipe Reading about the pain of the customer in his own words vs working on some feature description is so much better (first point is better). This gives the whole thing a purpose and doesn't feel like an arbitrary, invalidated idea. About the metrics. Sorry, I think I used the wrong word here. I mean some prioritization scoring, such as impact & effort of a feature or bug to make cards more comparable. I tried that once, but found that most of the time you already know which points seem to be high impact and low effort. Not sure, if one should score and then strictly follow the descending list of items. Edit: Or you start working on something, which is supposed to be high effort, but after re-reading the customer stories, you find a way more efficient and easier way to implement the requested functionality. Then the priority was incorrect the whole time.
  - olegious 10y ago
    Regarding scoring- in the ideal scenario, you're always working on cards that are most aligned with your top line goals, so you always want to be prioritizing based on your goals. For level of effort scoring, we just use a 1, 2, 3, 5, 8 system. Where 8 is too big to estimate and 1 is an hour or so. What happens if you misestimate? Unless something goes from 5 to 8, then it really doesn't matter because you should always be working on what's most important. If something goes from a 1 to a 5 and some commitment can't be met, then you must reduce the scope of the card or change the commitment. Don't waste too much time on the scoring, it isn't an exact science- spend more time ensuring you're working on the right things.
    - EduardMe 10y ago
      Ok understood. We mostly don't use any estimates. Neither effort, nor time. I have changed our boards to the main recommendations so far and now I hit some wall. Our QC is testing away a new internal release and getting back with the issues. But they create a new card in the "Test" list containing a check list with all the potential bugs they found, around 10-12 items. Should they rather create single cards for each issue and push it into the inbox? I feel somehow its going against the system to summarize a dozen points in a kind of "Test Report Card".
EduardMe 10y ago
By the way, found this chrome extension which shows the lists in yellow or red, if you are overfilling it with cards in trello: https://chrome.google.com/webstore/detail/kanban-wip-for-trello/oekefjibcnongmmmmkdiofgeppfkmdii https://chrome.google.com/webstore/detail/kanban-wip-for-tre...

olegious 10y ago

I think you have to always be focused on whatever top level goal/metric/OKR you're currently focused on and then define and test hypotheses that you think will get you to there in the fastest way possible. Think of it this way, if your current goal is to improve metric X by Y % then you should only be focused on ideas, hypotheses and feedback that can get you there, ignore everything else. In terms of columns, I like simplicity: Backlog -> Development -> Test -> Done Depending on your workflows, between "Test" and "Done" you can have a "To Be Deployed" column. This assumes that all features in the Backlog have been validated. My process there is: OKR (metric) -> Hypothesis (how will I meet this OKR?) -> Assumptions (what risky assumptions am I making in the hypothesis?) -> Experiment design (how can I prove/disprove the assumption?) -> Experiment -> review outcome and either discard the hypothesis or build it out to production level. In this workflow, items make it into the Backlog at the Experiment and "build out" stages. So you come up with an experiment that may require engineering effort, that's a card in your backlog. Your experiment validates your hypothesis, so you want to put more resources into the hypothesis, so that creates more cards to fully build out the feature. edit: I always liked this post by UserVoice because it shows you how far you can take these things, I wouldn't necessarily use their workflow, but it is interesting: https://community.uservoice.com/blog/trello-google-docs-product-management/ https://community.uservoice.com/blog/trello-google-docs-prod...

EduardMe 10y ago
Thanks for the link! Loved the point about capturing user stories: > Good specs tell the (customer) and business story rather than act as an implementation recipe Reading about the pain of the customer in his own words vs working on some feature description is so much better (first point is better). This gives the whole thing a purpose and doesn't feel like an arbitrary, invalidated idea. About the metrics. Sorry, I think I used the wrong word here. I mean some prioritization scoring, such as impact & effort of a feature or bug to make cards more comparable. I tried that once, but found that most of the time you already know which points seem to be high impact and low effort. Not sure, if one should score and then strictly follow the descending list of items. Edit: Or you start working on something, which is supposed to be high effort, but after re-reading the customer stories, you find a way more efficient and easier way to implement the requested functionality. Then the priority was incorrect the whole time.
- olegious 10y ago
  Regarding scoring- in the ideal scenario, you're always working on cards that are most aligned with your top line goals, so you always want to be prioritizing based on your goals. For level of effort scoring, we just use a 1, 2, 3, 5, 8 system. Where 8 is too big to estimate and 1 is an hour or so. What happens if you misestimate? Unless something goes from 5 to 8, then it really doesn't matter because you should always be working on what's most important. If something goes from a 1 to a 5 and some commitment can't be met, then you must reduce the scope of the card or change the commitment. Don't waste too much time on the scoring, it isn't an exact science- spend more time ensuring you're working on the right things.
  - EduardMe 10y ago
    Ok understood. We mostly don't use any estimates. Neither effort, nor time. I have changed our boards to the main recommendations so far and now I hit some wall. Our QC is testing away a new internal release and getting back with the issues. But they create a new card in the "Test" list containing a check list with all the potential bugs they found, around 10-12 items. Should they rather create single cards for each issue and push it into the inbox? I feel somehow its going against the system to summarize a dozen points in a kind of "Test Report Card".

EduardMe 10y ago

By the way, found this chrome extension which shows the lists in yellow or red, if you are overfilling it with cards in trello: https://chrome.google.com/webstore/detail/kanban-wip-for-trello/oekefjibcnongmmmmkdiofgeppfkmdii https://chrome.google.com/webstore/detail/kanban-wip-for-tre...