5 ms·
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 rec
by 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 agoRegarding 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 agoOk 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 agoTypically 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 agoOk, this make sense!