Re: Bugs/Velocity - Into the Scrum Weeds (offshoot of another thread)
My opinion also is that we should have a FAQ that acts as a reference point for further discussion.
It would capture common knowledge and discussions can build on that instead of always starting from scratch.
--- In firstname.lastname@example.org, "Tara Santmire" <tara@...> wrote:
> While I sort of agree with you that it would be nice to have some nice FAQ.
> I think that there is actually a value add to discussing these things in
> this kind of forum. There is give and take with a range of practitioners.
> Individuals can inspect the various thoughts and offerings and adapt them to
> their particular circumstance and that seems pretty Scrumish/Agile to me.
> Tara Santmire
> From: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of Chuck B
> Sent: Monday, January 31, 2011 1:13 PM
> To: email@example.com
> Subject: [scrumdevelopment] Bugs/Velocity - Into the Scrum Weeds (offshoot
> of another thread)
> > > If you wish to estimate how long they will take to fix, feel free
> > > to do so.
> > No mention of adding defect fixing to your velocity calculation? Even to
> > mention that the practice is controversial? Maybe you were going for a
> > or "high level" description of the solution.
> These are the kind of things I run into when coaching teams. Ron wrote an
> excellent post which describes an excellent practice, IMO. Unfortunately,
> due to (what I personally believe is) the mis-use of User Stories, people
> will interpret what Ron said about "backlog items" to be equivalent to "User
> Stories", and will begin adding in defect fixing time into their velocity
> calculations -- even though he never once mentioned the term velocity. Now,
> others have different views of whether or how defect fixing gets added to
> velocity, and I respect that.
> I don't blame anyone in particular for this (what I believe is a)
> misunderstanding. IMO, the root cause analysis comes down to the fact that
> User Stories != Product Backlog Items, and this is never made clear in the
> Scrum Guide or some other artifact with as much credibility as the Scrum
> Guide. Further, The Scrum Guide mentions velocity once, but never defines
> I honestly think that the optional User Stories tip in the Scrum Guide,
> along with the lone vague mention of velocity, has substantially contributed
> to much misunderstanding and controversy. Further, having a lone
> book(arguably outdated) dedicated to User Stories doesn't really help
> There are so many practical questions that are not well answered by the
> Scrum Guide(or the available material on User Stories), and because of the
> split between between the SA and Scrum.org, there is even more ambiguity.
> I guess I kind of wish that Scrum.org or someone else credible would have a
> Scrum FAQ to help teams with such practical questions as:
> How do I handle bugs in Scrum?
> Should bugs be counted in velocity?
> The Scrum Guide never really defines velocity. In the Scrum Guide's view,
> what does it mean?
> Are PBI's the same as User Stories?
> Is <activity X> a PBI or a task? How do you tell the difference?
> My team has to coordinate with another department to so our systems can talk
> to each other. Is that a PBI? Is that a Story? How do we plan for that?
> What are some choices for estimating PBI's ? For User Stories?
> My team is being required to write some system documentation. Is that a
> PBI, User Story, task, or something else?
> How do I handle so called "technical stories" ?
> How do I handle "technical debt" ?
> I'm not saying there should be any one prescribed solution to each of these,
> just maybe a selection of solutions that seem to have some success in the
> industry. I think Scrum is getting to the point where it wouldb e useful to
> have some guidance beyond the Scrum Guide, but with a similar credible value
> as the Scrum Guide. Unfortunately, IMO, much of the literature out there
> doesn't necessarily give advice consistent with the Scrum Guide.
> Anyone have any suggestions?
> From: Ron Jeffries <ronjeffries@...>
> To: firstname.lastname@example.org
> Sent: Mon, January 31, 2011 4:55:38 AM
> Subject: [scrumdevelopment] Scheduling Defect Fixes
> My Dear Colleague,
> Thank you for your question about scheduling and estimating defect
> fixes. It is an important topic: more so than you may have realized.
> The short answer to your question is:
> Defects should be placed in the backlog and prioritized just like
> all other planned or potential changes to the system.
> If you wish to estimate how long they will take to fix, feel free
> to do so. You'll surely want some kind of sense of size so as to
> know how many backlog items to take on in the Sprint.
> However, there's much more to it than this. The other aspects I'll
> cover below are usually far more important than the scheduling and