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.
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".
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.
> 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.