RE: [scrumdevelopment] Re: Scheduling Defect Fixes
- Yes, I understand all of that (he says with a sigh). If we know there are defects we will not declare the features to be 'done'.
So that is not part of the discussion.
But ... oh dear, how many times must I say it before the facts of the matter are understood ... if you are under the fond impression that the features are done, and you move on with your life and with your velocity calculation, and THEN you discover there was a defect (horror of horrors, of course, but it happens) the question is What do do about it?
You see, by that time, the velocity has been updated with the affect of the delivered 'done' features ... they have already been counted as 'done' and have been counted towards velocity. What are you going to do? Go back and put the features back on the Product Backlog, roll back the count in velocity, back out the feature and drop the count of its Story Points (or gummy bears, or whatever the measure of capacity to deliver has been)?
Or are you going to treat the defect as further work to be done, and handle it, and count the effort in the team's ability to deliver stuff?
Date: Tue, 1 Feb 2011 13:18:31 +0000
Subject: [scrumdevelopment] Re: Scheduling Defect Fixes
I think the velocity is the ability to deliver on the "Done" definition
of tasks. So, if a defect found is not covered under "Done" it is a new
feature, otherwise it is a "Not Done" feature which cannot count towards
I agree there will be bugs that will slip through, but again "Done"
definition decides their fate. In our case we consider all P0,P1,P2 bugs
as part of "Done" criterion that should be fixed ASAP and the effort
spent on them rightfully reduces the velocity. We do not take credit for
things "Not Done".
--- In firstname.lastname@example.org, Roy Morien <roymorien@...>
>Sprint" ... yes, I agree.
> I still can't see this, George.
> "velocity is roughly the team's capacity to accomplish work within a
>you should /subtract/ that from the available capacity." ... Why? The
> The bit I don't get is "If you've estimated the work to fix defects,
time and effort in fixing the defects is part of the team's capacity to
accomplish work. Fixing the defects is work. If you have no defects to
fix (highly desirable, of course), then the team's total capacity to
accomplish work will be spent on new development. BUT if they have
defects to fix, then they cannot accomplish that same amount of new
development, although they are working to capacity.
>"velocity is roughly the team's capacity to accomplish NEW work
> What you say is correct only if the definition of velocity is
PREVIOUSLY NOT ATTEMPTED, THAT IS DIRECTLY RELATED TO USER REQUESTS FOR
NEW FUNCTIONALITY, within a Sprint". This is not, in my view, the
definition, purpose and use of the concept of velocity.
> But this is, of course, where I obviously differ from some others.
> Roy Morien
> To: email@example.com
> From: lists@...
> Date: Mon, 31 Jan 2011 13:46:03 -0500
> Subject: Re: [scrumdevelopment] Scheduling Defect Fixes
> On 1/31/11 12:55 PM, Charles Bradley - Scrum Coach, CSM, PSM I wrote:
> > I'm curious though.
> > > 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?
> > mention that the practice is controversial? Maybe you were going fora
> > "basic" or "high level" description of the solution.estimates to
> > To the OP(the one who asked about scheduling bugs into Scrum), my
> > comment is this: Be careful about adding your defect fixing
> > velocity(which is a User Story concept). That practice iscontroversial,
> > and the main risk is that you do not want to decrease transparencyby
> > lumping material amounts of "defect fixing efforts" in with "newsolution,
> > functionality efforts that add value to the system." The best
> > as Ron mentions, is probably to reduce defects to such a small ratethat
> > there is no material amount of defect fixing time. There are otherStory
> > solutions, but they get down "into the weeds" in Scrum and User
> > philosophy.
> Yes. The way I express it is that velocity is roughly the team's
> capacity to accomplish work within a Sprint. If you've estimated the
> work to fix defects, you should /subtract/ that from the available
> capacity. And always remember that the goal is to produce working
> software, not to "get credit" for story points.
> - George
> * George Dinwiddie * http://blog.gdinwiddie.com
> Software Development http://www.idiacomputing.com
> Consultant and Coach http://www.agilemaryland.org
Although, this is not Twitter. I really want to do a +1.>>It (and the length of this thread) is a great illustration of why I recommend that teams not get too wrapped up in estimation. They start looking for numerical precision, and that starts consuming the energy that could be put toward accomplish goals.
Echoes my thoughts completely. Won't have been able to put it better myself.