Loading ...
Sorry, an error occurred while loading the content.
 

Re: Bugs/Velocity - Into the Scrum Weeds (offshoot of another thread)

Expand Messages
  • kbs_kulbhushan
    Hello, 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
    Message 1 of 3 , Jan 31, 2011
      Hello,

      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.

      Regards,

      --- In scrumdevelopment@yahoogroups.com, "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.
      >
      >
      >
      > Regards,
      >
      > Tara Santmire
      >
      >
      >
      > From: scrumdevelopment@yahoogroups.com
      > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Chuck B
      > Sent: Monday, January 31, 2011 1:13 PM
      > To: scrumdevelopment@yahoogroups.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
      > "basic"
      > > 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
      > it.
      >
      > 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
      > either.
      >
      > 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?
      >
      > Charles
      >
      > _____
      >
      > From: Ron Jeffries <ronjeffries@...>
      > To: scrumdevelopment@yahoogroups.com
      > 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
      > estimating.
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.