You can clone with
HTTPS or Subversion.
Breaking this out of issue #49.
One thing we could use is 0-point bugs. We regularly have bugs that literally take 5 minutes to do. We've been scoring them as 1, but that's a half-day equivalent and that messes up our velocity numbers.
So, I'd like a p= vs. p=0 distinction where the latter is ok and doesn't indicate (via red background) that it needs sprint-planning evaluation work.
@pmac replied to my comment with this:
@willkg I think the right answer with bugs you'd like to be less than 1 is to just do
them and not put them in a sprint. "Fix this tiny issue" isn't really a user story anyway.
We could do this, but I'm not sure the distinction is useful. Most scrum practitioners
I've seen use a much wider point value range than is typical at Mozilla as well. At my
last job, a 1 point story meant it was a text change, and the rest were basically
multiples of that. It was not uncommon for us to have a 13 point bug, and if we wanted
to go much higher, that usually meant that some breaking apart into more stories was
Then I replied in IRC along these lines:
"Just do it now" doesn't work because these are issues that take 5-10 minutes which is real time and should get scheduled in a sprint. You could argue that our point values should get adjusted to reflect this, but scrumbugz provides no advice on how point values should work.
In the meantime, p= is definitely different than p=0. The former is scoreless since there is no number there. The latter has a score of 0 which was intentional.
So, I think there are two possible solutions at this point:
scrumbugz institutes what the point values mean across all projects such that the code supports specific meaning in the points
scrumbugz doesn't institute what the point values mean but instead allows p=0 to be a valid scoring for a story and doesn't show it as red in the sprint list
Since p=inf has been folded in here.
I guess p=inf is the opposite of what willg proposed with p=0. Where p=0 are bugs that have been scored and the score is so little since they will take little time. p=inf is where someone has scored but the story is just too big i.e. it needs to be broken down or clarified so that it can be properly estimated.
Both indicate that the bug has been scored in some way as opposed to being unscored.
The whole p=inf thing is not relevant to this issue. That's a completely different issue that has its own issue to discuss it in.
This is explicitly about p=0 and removing the red background in the table--that's it.
Ah sorry comment on the wrong issue :(
This is all set in the new scrumbugz. Closing it out.