41067Re: [scrumdevelopment] Re: Using Scrum for a maintenance / sustained engineering assignment
- Sep 2, 2009Hello,
Are you running automated tests?
I get the impression that the code is causing the problem here, not the estimations of velocity of the team.
I would do some major code review sessions before tackling bugs which, in my opinion, the users should not be the ones reporting.
For me, velocity is an estimate of how much functionality items can be delivered at the end of a sprint. Even story points are not entirely necessary. As a PO I would even be happy with a velocity measurements of 'a couple \ a few \ a handful \ many'.
In that sense you can treat bug fixing in the same way. How many bugs will be fixed? Many? A couple? That becomes your velocity.
But what do you want to use the velocity measurement for? Are you devising a release plan? Are you trying to estimate when all bugs will be fixed?
JacobOn Wed, Sep 2, 2009 at 12:17 PM, Roy Morien <roymorien@...> wrote:
It seems to me that the effort in fixing a defect can be reasonably counted in the team's velocity. Maybe it will be of interest as to why the defect occurred, and certainly there will be some effort in clearly understanding what the defect is, and how to rectify it ... but, velocity is a measure of how much 'effort and complexity' a team can achieve in a sprint. Where does it say that velocity can only measure effort on new, 'green fields' work?The cause of the defect, the reason it occurred, the reason that it was not detected during the development of the feature in which the defect occurred, can be considered in a review or sprint retrospective, so that the process of development can be improved to avoid the same situation occurring again. But this is not part of 'velocity'.My reaction to the statement 'they need to spend more time ... more than 4 hours' is 'maybe they would make better use of that time by getting on with fixing it, rather than trying to come up with a better estimate of when they will finish fixing it'. Sure , spend the necessary time understanding the problem, but to spend a lot of time trying to come up with a better estimate of time seems a rather unhelpful activity.Regards,Roy Morien
Date: Tue, 1 Sep 2009 20:09:17 +0000
Subject: [scrumdevelopment] Re: Using Scrum for a maintenance / sustained engineering assignment
--- In email@example.com, Ron Jeffries <ronjeffries@...> wrote:
> Hello, wnoida. On Saturday, August 8, 2009, at 3:55:13 AM, you
> > The biggest challenge we are facing is with second part of the
> > sprint planning meeting. Once the team understands the priortized
> > backlog items, they need to spend time with the application,
> > explore the code, gain more functional knowledge before they can
> > come up with the commitment and some estimates. This exercise
> > needs more than 4 hours. The collaoration between Developers and
> > Testers also becomes challenging.
> What value would you get if it didn't take that long? Why not just
> prioritize the defects and start working?
> Ron Jeffries
> Yesterday's code should be as good as we could make it yesterday.
> The fact that we know more today, and are more capable today,
> is good news about today, not bad news about yesterday.
Thanks for the reply Ron. Here we are mostly dealing with defects. How can we measure the teams velocity? As defects are assigned to the team members they are not in a position to assign story points to it. Can we assign story points after fixing the defects, as now the developer knows the size of the work item? This will help us build a history and we can use this to predict the velocity for future sprints? How should we approach this issue when fixing defects? what is a good metrics in this situation?
Find out how here Use Messenger in your Hotmail inbox
- << Previous post in topic Next post in topic >>