3 ms·

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

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".
    - olegious 10y ago
      Typically bugs should go on an individual card. Yes, that will create many cards, but if they're small, then they'll be fixed quickly. This is more of an art than a science, experiment with different approaches, read about how others are doing things and modify to match your own process.
      - EduardMe 10y ago
        Ok, this make sense!

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".
  - olegious 10y ago
    Typically bugs should go on an individual card. Yes, that will create many cards, but if they're small, then they'll be fixed quickly. This is more of an art than a science, experiment with different approaches, read about how others are doing things and modify to match your own process.
    - EduardMe 10y ago
      Ok, this make sense!