## Re: [scrumdevelopment] Velocity?

Expand Messages
• Thanks to you all for the prompt response regarding the concept of velocity. I have few more basic questions on velocity…I will pick the definition that
Message 1 of 22 , Mar 7, 2005
Thanks to you all for the prompt response regarding
the concept of velocity.

I have few more basic questions on velocity�I will
pick the definition that helped me best understand
what the velocity means:

"Velocity is essentially the amount of product
completed over time." - Paul Hodgetts

�The teams with which I've worked multiply their
available days times an adjustment of 0.4 to 0.8 to
get the number of ideal days they can accomplish, and
that helps them figure out their velocity and what
they can commit to in a sprint.� - Paul Hodgetts

Is there any term in SCRUM around the value �0.4�
mentioned above? 0.4 (or 40%) is used here as an
estimation that will help the team define its
velocity.
This means that depending on the developer, the factor
could be 40% or 80% and still achieve the velocity
defined by the team. Right?

Thanks
Ravi

--- Jeff Sutherland <jeff.sutherland@...>
wrote:
> Well, it may be confusing but it is high school
> physics. You know that
> about 20% of Americas think that the sun rotates
> around the earth and
> 45% of Americans think that water coming out of a
> coiled hose will
> flow in a spiral fashion. Not to mention another 45%
> that think a ball
> rolling off a table top will hit the floor directly
> below the edge of
> the table. An equal number think the earth was
> years ago, but I digress.
>
> Velocity equals the rate of change of distance with
> time. Acceleration
> is the rate of change of velocity. This has nothing
> to do with Scrum.
>
> In Scrum, the distance is amount of work done.
>
> However, we train people in CSM to use an ideal
> developer day to
> estimate work for their team. This concept of an
> ideal developer day
> will be different for different Scrum teams. Ergo,
> productivity can be
> different across teams with the same velocity.
>
> I don't see any new jargon here. We have been using
> the same words for a decade.
>
> Jeff Sutherland
>
>
> On Sun, 6 Mar 2005 11:36:48 -0800, Phlip
> <phlip2005@...> wrote:
> >
> > Jeff Sutherland wrote:
> >
> > > Velocity is the rate of change of the burndown
> chart. Ideally, the
> > > burndown drops one day per team member every
> day.
> >
> > This answer doubles the amount of undefined
> jargon, and then adds a
> > confusing ideal that implies one can _set_ the
> velocity.
> >
> > Who do you think you are?
> >
> > Oh, wait. You think you are Jeff Sutherland.
> >
> > <impersonation voice="Emily Litela">Never
> mind.</impersonation>
> >
> > --
> > Phlip
> >
>
http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
>

__________________________________
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/
• It is common for development teams to multiply their ideal developer day by a fraction to estimate the amount of work they get done in a day. If it is 0.40,
Message 2 of 22 , Mar 7, 2005
It is common for development teams to multiply their ideal developer
day by a fraction to estimate the amount of work they get done in a
day. If it is 0.40, they can only allocate 40% of the their day to the
Sprint backlog.

It is important for teams to be realistic, particularly in early
Sprints. The most important thing is to actually complete the work
they commit to in a Sprint. Once that is done repeatedly, they can
focus on improving throughput within the Sprint.

In my view, a 40% team is a very distracted team. I've seen teams run
at more than 100% of their ideal developer day.

The reality is that in most organizations a tremendous amount of work
on blocking items must be undertaken to get teams to peak efficiency.
That is the hard part of Scrum. The organization must undergo some
business process reengineering in order for their development teams to
function properly. People will come up with every reason, however
improbable, to argue that their teams cannot possibly operate at peak
efficiency. They will often say that the goal of their organization is
really not higher productivity.

They will say this as development jobs are being outsourced because it
is cheaper to run an inefficient organization elsewhere. The really
scary thing is that outsourcing organizations are beginning to adopt
Scrum because it makes them highly competitive.

Counterintuitively, the more efficiently the team runs, the higher the morale.

Jeff Sutherland

On Mon, 7 Mar 2005 12:34:42 -0800 (PST), Ravi Srinivasan
<netlimit2000@...> wrote:
>
> Thanks to you all for the prompt response regarding
> the concept of velocity.
>
> I have few more basic questions on velocity…I will
> pick the definition that helped me best understand
> what the velocity means:
>
> "Velocity is essentially the amount of product
> completed over time." - Paul Hodgetts
>
> "The teams with which I've worked multiply their
> available days times an adjustment of 0.4 to 0.8 to
> get the number of ideal days they can accomplish, and
> that helps them figure out their velocity and what
> they can commit to in a sprint." - Paul Hodgetts
>
> Is there any term in SCRUM around the value '0.4'
> mentioned above? 0.4 (or 40%) is used here as an
> estimation that will help the team define its
> velocity.
> This means that depending on the developer, the factor
> could be 40% or 80% and still achieve the velocity
> defined by the team. Right?
>
> Thanks
> Ravi
• ... That is loading factor . Some velocity estimations track the ratio of estimated time to actual time. That s why I used the definition the number of
Message 3 of 22 , Mar 7, 2005
Ravi Srinivasan wrote:
>
> "The teams with which I've worked multiply their
> available days times an adjustment of 0.4 to 0.8 to
> get the number of ideal days they can accomplish, and
> that helps them figure out their velocity and what
> they can commit to in a sprint." - Paul Hodgetts
>
> Is there any term in SCRUM around the value '0.4'
> mentioned above? 0.4 (or 40%) is used here as an
> estimation that will help the team define its
> velocity.

estimated time to actual time.

That's why I used the definition "the number of features completed in
a week". There are those who request feature estimates in days, and
who can then expect a velocity tick of one per day per developer. This
requires math, that I hoped to avoid.

> This means that depending on the developer, the factor
> could be 40% or 80% and still achieve the velocity
> defined by the team. Right?

There is no benefit to tracking individual velocity. Conscientious
individuals do this, for themselves, automatically, but if they don't
it's no big deal. The team will know who is slacking.

Put this another way: What would you do about a worker who was
chronically lower than others? The answer is nothing. That worker
might be the one who always takes on hard, stories, or the one who
always helps boost others velocity.

--
Phlip
• ... In the book Agile Project Management with Scrum on page 11, Ken calls an adjustment made to an estimate a complexity factor. Unless I missed it, that
Message 4 of 22 , Mar 7, 2005
Ravi wrote:

> Thanks to you all for the prompt response regarding
> the concept of velocity.
>
> I have few more basic questions on velocityI will
> pick the definition that helped me best understand
> what the velocity means:
>
> "Velocity is essentially the amount of product
> completed over time." - Paul Hodgetts
>
> The teams with which I've worked multiply their
> available days times an adjustment of 0.4 to 0.8 to
> get the number of ideal days they can accomplish, and
> that helps them figure out their velocity and what
> they can commit to in a sprint. - Paul Hodgetts
>
>
> Is there any term in SCRUM around the value 0.4
> mentioned above? 0.4 (or 40%) is used here as an
> estimation that will help the team define its
> velocity.

In the book "Agile Project Management with Scrum" on page 11,
factor." Unless I missed it, that book doesn't talk about
adjustments applied to velocity, since velocity isn't really
discuss as such. In the CSM courses, Ken calls an adjustment

> This means that depending on the developer, the factor
> could be 40% or 80% and still achieve the velocity
> defined by the team. Right?

I fear there is a disconnect here in what I'm trying to
describe and what you are understanding from it. The
"factor of 40% or 80%" is used to estimate velocity. The
team achieves whatever velocity they can really achieve.
Let me try again from another angle...

Let's assume we have a team of only programmers to simplify
things. We have four of them dedicated full time to the
project with only normal company overhead to consider.

We estimate our product backlog items in ideal programmer
days. In other words, if I had a perfect 8 hour day with
no interruptions or overhead at all, how long would it take?

We schedule a sprint from March 1 to March 31, within which
there are 23 working days, taking into consideration the
weekends (we have a life ;-).

As a developer, if I had no overhead at all (in other words
an "ideal day"), I my perfect velocity would be 23 ideal
days of estimated work done in the sprint. Times 4 gives
me a perfect velocity of 92 total ideal days of work that
the team could do in the sprint.

But days are not ideal, and conditions are not ideal. For
example, I know I have 3 hours of meetings, and another hour
of corporate paperwork to do. So I lose 4 hours a week,
which means (given a 40 hour week), that I have to multiply
my ideal velocity by 0.9 just to accommodate that.

There are other things that reduce our velocity ("drag"
using Ken's CSM term). Just the fact that we are learning
Scrum and how to work as a self-managed team adds drag. If
our environment is not ideal, for example our builds take
too long or testing is hard, that adds drag. Teams that
are not used to working together or are distributed across
multiple locations add drag. So we can add up all the hours
lost in a week to all the different drag producing things,
and adjust for them as well.

My experience is that a new Scrum team, on their first
sprint, will need a drag adjustment of from 0.4 to 0.6. A
Scrum team that has several sprints under their belt will
have a better drag adjustment, maybe 0.6 to 0.8. I have
never had a team at 1.0, just due to some minimal company
overhead. Teams and their environments are very different,
so these are just my generalizations from my work with teams
over the past three years.

Anyway, let's say we decide on a drag adjustment of 0.6 for
our little team on their first sprint. We multiply the
perfect velocity of 92 ideal days, times 0.6, and we would
commit to no more than 55 estimated ideal days of backlog
items for the first sprint.

The most important thing is that we will learn very quickly
(guaranteed within 30 days), how many estimated ideal days
we can really do. We may do 52, or we may do 63, but we'll
have some feedback to help with sprint two. From this point
on, the drag factors are not as meaningful, although we can
reverse calculate them if want.

If we have to make an initial estimate of an entire release
(i.e., multiple sprints) without the benefit of having done
at least one sprint to get real feedback, we have to use an
estimating method like ideal days and drag adjustments, or
one of a couple of other variants of estimating. I would
very strongly recommend trying to do at least one sprint
before making any long-range commitments for a release. If
we must do so before starting, be conservative on our drag
adjustment -- I see way too many new Scrum teams be overly
optimistic and choose something like 0.8, only to find their
first sprint is 0.4, and their release average ends up 0.7.

Does that help?

Paul
-----
Paul Hodgetts -- CEO, Coach, Trainer, Consultant
phodgetts@... -- (714) 577-5795
Yahoo agilelogic - AIM AgileLogic - MSN agilelogic - ICQ 295726213

Agile Logic
www.agilelogic.com
1519 E. Chapman Ave. #254 -- Fullerton, CA, USA 92831
Training, Coaching, Consulting -- Agile Processes/Scrum/Lean/XP
Complete solutions for adopting agile processes, Scrum and XP.

Upcoming Events:

Certified ScrumMaster Training, Las Vegas, NV - April 25-26, 2005
http://www.agilelogic.com/CSM.html
• If an ideal day is a day with no distractions and all inputs ready to go when needed by the developer, then if a team is exceeding an ideal day I suspect
Message 5 of 22 , Mar 7, 2005
If an ideal day is a day with no distractions and all inputs ready to go
when needed by the developer, then if a team is exceeding an ideal day I
suspect they've incorrectly defined an ideal day. It seem impossible to have
a day with less than zero distractions.

--Mike Cohn
Author of User Stories Applied for Agile Software Development
www.mountaingoatsoftware.com

-----Original Message-----
From: Jeff Sutherland [mailto:jeff.sutherland@...]
Sent: Monday, March 07, 2005 1:53 PM
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] Velocity?

It is common for development teams to multiply their ideal developer
day by a fraction to estimate the amount of work they get done in a
day. If it is 0.40, they can only allocate 40% of the their day to the
Sprint backlog.

It is important for teams to be realistic, particularly in early
Sprints. The most important thing is to actually complete the work
they commit to in a Sprint. Once that is done repeatedly, they can
focus on improving throughput within the Sprint.

In my view, a 40% team is a very distracted team. I've seen teams run
at more than 100% of their ideal developer day.

The reality is that in most organizations a tremendous amount of work
on blocking items must be undertaken to get teams to peak efficiency.
That is the hard part of Scrum. The organization must undergo some
business process reengineering in order for their development teams to
function properly. People will come up with every reason, however
improbable, to argue that their teams cannot possibly operate at peak
efficiency. They will often say that the goal of their organization is
really not higher productivity.

They will say this as development jobs are being outsourced because it
is cheaper to run an inefficient organization elsewhere. The really
scary thing is that outsourcing organizations are beginning to adopt
Scrum because it makes them highly competitive.

Counterintuitively, the more efficiently the team runs, the higher the
morale.

Jeff Sutherland

On Mon, 7 Mar 2005 12:34:42 -0800 (PST), Ravi Srinivasan
<netlimit2000@...> wrote:
>
> Thanks to you all for the prompt response regarding
> the concept of velocity.
>
> I have few more basic questions on velocity.I will
> pick the definition that helped me best understand
> what the velocity means:
>
> "Velocity is essentially the amount of product
> completed over time." - Paul Hodgetts
>
> "The teams with which I've worked multiply their
> available days times an adjustment of 0.4 to 0.8 to
> get the number of ideal days they can accomplish, and
> that helps them figure out their velocity and what
> they can commit to in a sprint." - Paul Hodgetts
>
> Is there any term in SCRUM around the value '0.4'
> mentioned above? 0.4 (or 40%) is used here as an
> estimation that will help the team define its
> velocity.
> This means that depending on the developer, the factor
> could be 40% or 80% and still achieve the velocity
> defined by the team. Right?
>
> Thanks
> Ravi

To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@...
• Hi Ravi, I m unsure if Mike Cohn still has the draft of his new book on planning on www.mountaingoatsoftware.com. It is all about planning and very valuable in
Message 6 of 22 , Mar 8, 2005
Hi Ravi,

I'm unsure if Mike Cohn still has the draft of his new book on
planning on www.mountaingoatsoftware.com. It is all about planning and
very valuable in answering you questions. Have a look and pick the

My personal opinion: don't go too deep with your studies, once you
understand the principles of velocity and burndown charts then go with
your best guess. Planning is an art, not science. And agile planning
doesn't differ in that respect from any other planning.

--Hubert

On Mon, 7 Mar 2005 12:34:42 -0800 (PST), Ravi Srinivasan
<netlimit2000@...> wrote:
>
> Thanks to you all for the prompt response regarding
> the concept of velocity.
>
> I have few more basic questions on velocity…I will
> pick the definition that helped me best understand
> what the velocity means:
>
> "Velocity is essentially the amount of product
> completed over time." - Paul Hodgetts
>
> "The teams with which I've worked multiply their
> available days times an adjustment of 0.4 to 0.8 to
> get the number of ideal days they can accomplish, and
> that helps them figure out their velocity and what
> they can commit to in a sprint." - Paul Hodgetts
>
> Is there any term in SCRUM around the value '0.4'
> mentioned above? 0.4 (or 40%) is used here as an
> estimation that will help the team define its
> velocity.
> This means that depending on the developer, the factor
> could be 40% or 80% and still achieve the velocity
> defined by the team. Right?
>
> Thanks
> Ravi
>
> --- Jeff Sutherland <jeff.sutherland@...>
> wrote:
> > Well, it may be confusing but it is high school
> > physics. You know that
> > about 20% of Americas think that the sun rotates
> > around the earth and
> > 45% of Americans think that water coming out of a
> > coiled hose will
> > flow in a spiral fashion. Not to mention another 45%
> > that think a ball
> > rolling off a table top will hit the floor directly
> > below the edge of
> > the table. An equal number think the earth was
> > years ago, but I digress.
> >
> > Velocity equals the rate of change of distance with
> > time. Acceleration
> > is the rate of change of velocity. This has nothing
> > to do with Scrum.
> >
> > In Scrum, the distance is amount of work done.
> >
> > However, we train people in CSM to use an ideal
> > developer day to
> > estimate work for their team. This concept of an
> > ideal developer day
> > will be different for different Scrum teams. Ergo,
> > productivity can be
> > different across teams with the same velocity.
> >
> > I don't see any new jargon here. We have been using
> > the same words for a decade.
> >
> > Jeff Sutherland
> >
> >
> > On Sun, 6 Mar 2005 11:36:48 -0800, Phlip
> > <phlip2005@...> wrote:
> > >
> > > Jeff Sutherland wrote:
> > >
> > > > Velocity is the rate of change of the burndown
> > chart. Ideally, the
> > > > burndown drops one day per team member every
> > day.
> > >
> > > This answer doubles the amount of undefined
> > jargon, and then adds a
> > > confusing ideal that implies one can _set_ the
> > velocity.
> > >
> > > Who do you think you are?
> > >
> > > Oh, wait. You think you are Jeff Sutherland.
> > >
> > > <impersonation voice="Emily Litela">Never
> > mind.</impersonation>
> > >
> > > --
> > > Phlip
> > >
> >
> http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
> >
>
> __________________________________
> Celebrate Yahoo!'s 10th Birthday!
> Yahoo! Netrospective: 100 Moments of the Web
> http://birthday.yahoo.com/netrospective/
>
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
>
>
>
>
>
• When a basketball team enters the zone they score more points than their ideal day. Records are set. Jeff On Mon, 7 Mar 2005 18:57:37 -0700, Mike Cohn
Message 7 of 22 , Mar 8, 2005
When a basketball team enters the "zone" they score more points than
their ideal day. Records are set.

Jeff

On Mon, 7 Mar 2005 18:57:37 -0700, Mike Cohn
<mike@...> wrote:
>
> If an ideal day is a day with no distractions and all inputs ready to go
> when needed by the developer, then if a team is exceeding an ideal day I
> suspect they've incorrectly defined an ideal day. It seem impossible to have
> a day with less than zero distractions.
>
> --Mike Cohn
> Author of User Stories Applied for Agile Software Development
> www.mountaingoatsoftware.com
>
> -----Original Message-----
> From: Jeff Sutherland [mailto:jeff.sutherland@...]
> Sent: Monday, March 07, 2005 1:53 PM
> To: scrumdevelopment@yahoogroups.com
> Subject: Re: [scrumdevelopment] Velocity?
>
> It is common for development teams to multiply their ideal developer
> day by a fraction to estimate the amount of work they get done in a
> day. If it is 0.40, they can only allocate 40% of the their day to the
> Sprint backlog.
>
> It is important for teams to be realistic, particularly in early
> Sprints. The most important thing is to actually complete the work
> they commit to in a Sprint. Once that is done repeatedly, they can
> focus on improving throughput within the Sprint.
>
> In my view, a 40% team is a very distracted team. I've seen teams run
> at more than 100% of their ideal developer day.
>
> The reality is that in most organizations a tremendous amount of work
> on blocking items must be undertaken to get teams to peak efficiency.
> That is the hard part of Scrum. The organization must undergo some
> business process reengineering in order for their development teams to
> function properly. People will come up with every reason, however
> improbable, to argue that their teams cannot possibly operate at peak
> efficiency. They will often say that the goal of their organization is
> really not higher productivity.
>
> They will say this as development jobs are being outsourced because it
> is cheaper to run an inefficient organization elsewhere. The really
> scary thing is that outsourcing organizations are beginning to adopt
> Scrum because it makes them highly competitive.
>
> Counterintuitively, the more efficiently the team runs, the higher the
> morale.
>
> Jeff Sutherland
>
> On Mon, 7 Mar 2005 12:34:42 -0800 (PST), Ravi Srinivasan
> <netlimit2000@...> wrote:
> >
> > Thanks to you all for the prompt response regarding
> > the concept of velocity.
> >
> > I have few more basic questions on velocity.I will
> > pick the definition that helped me best understand
> > what the velocity means:
> >
> > "Velocity is essentially the amount of product
> > completed over time." - Paul Hodgetts
> >
> > Additionally I found this:
> > "The teams with which I've worked multiply their
> > available days times an adjustment of 0.4 to 0.8 to
> > get the number of ideal days they can accomplish, and
> > that helps them figure out their velocity and what
> > they can commit to in a sprint." - Paul Hodgetts
> >
> > Is there any term in SCRUM around the value '0.4'
> > mentioned above? 0.4 (or 40%) is used here as an
> > estimation that will help the team define its
> > velocity.
> > This means that depending on the developer, the factor
> > could be 40% or 80% and still achieve the velocity
> > defined by the team. Right?
> >
> > Thanks
> > Ravi
>
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@...
>
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
>
>
>
• But if a basketball team were to define an ideal game it would probably be one where all shots went in or when all defenders were out of place. My point is
Message 8 of 22 , Mar 8, 2005
But if a basketball team were to define an ideal game it would probably be
one where all shots went in or when all defenders were out of place.

My point is that if it is something a team can do then it's not their
ideal--there must be some overhead, there must be some missed shots.

--Mike

-----Original Message-----
From: Jeff Sutherland [mailto:jeff.sutherland@...]
Sent: Tuesday, March 08, 2005 7:21 AM
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] Velocity?

When a basketball team enters the "zone" they score more points than
their ideal day. Records are set.

Jeff

On Mon, 7 Mar 2005 18:57:37 -0700, Mike Cohn
<mike@...> wrote:
>
> If an ideal day is a day with no distractions and all inputs ready to go
> when needed by the developer, then if a team is exceeding an ideal day I
> suspect they've incorrectly defined an ideal day. It seem impossible to
have
> a day with less than zero distractions.
>
> --Mike Cohn
> Author of User Stories Applied for Agile Software Development
> www.mountaingoatsoftware.com
>
> -----Original Message-----
> From: Jeff Sutherland [mailto:jeff.sutherland@...]
> Sent: Monday, March 07, 2005 1:53 PM
> To: scrumdevelopment@yahoogroups.com
> Subject: Re: [scrumdevelopment] Velocity?
>
> It is common for development teams to multiply their ideal developer
> day by a fraction to estimate the amount of work they get done in a
> day. If it is 0.40, they can only allocate 40% of the their day to the
> Sprint backlog.
>
> It is important for teams to be realistic, particularly in early
> Sprints. The most important thing is to actually complete the work
> they commit to in a Sprint. Once that is done repeatedly, they can
> focus on improving throughput within the Sprint.
>
> In my view, a 40% team is a very distracted team. I've seen teams run
> at more than 100% of their ideal developer day.
>
> The reality is that in most organizations a tremendous amount of work
> on blocking items must be undertaken to get teams to peak efficiency.
> That is the hard part of Scrum. The organization must undergo some
> business process reengineering in order for their development teams to
> function properly. People will come up with every reason, however
> improbable, to argue that their teams cannot possibly operate at peak
> efficiency. They will often say that the goal of their organization is
> really not higher productivity.
>
> They will say this as development jobs are being outsourced because it
> is cheaper to run an inefficient organization elsewhere. The really
> scary thing is that outsourcing organizations are beginning to adopt
> Scrum because it makes them highly competitive.
>
> Counterintuitively, the more efficiently the team runs, the higher the
> morale.
>
> Jeff Sutherland
>
> On Mon, 7 Mar 2005 12:34:42 -0800 (PST), Ravi Srinivasan
> <netlimit2000@...> wrote:
> >
> > Thanks to you all for the prompt response regarding
> > the concept of velocity.
> >
> > I have few more basic questions on velocity.I will
> > pick the definition that helped me best understand
> > what the velocity means:
> >
> > "Velocity is essentially the amount of product
> > completed over time." - Paul Hodgetts
> >
> > Additionally I found this:
> > "The teams with which I've worked multiply their
> > available days times an adjustment of 0.4 to 0.8 to
> > get the number of ideal days they can accomplish, and
> > that helps them figure out their velocity and what
> > they can commit to in a sprint." - Paul Hodgetts
> >
> > Is there any term in SCRUM around the value '0.4'
> > mentioned above? 0.4 (or 40%) is used here as an
> > estimation that will help the team define its
> > velocity.
> > This means that depending on the developer, the factor
> > could be 40% or 80% and still achieve the velocity
> > defined by the team. Right?
> >
> > Thanks
> > Ravi
>
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@...
>
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@...
>
>
>

To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@...
• Yes, there are chapters for an upcoming book called Agile Estimating and Planning at www.mountaingoatsoftware.com/agileplanning. There used to be more
Message 9 of 22 , Mar 8, 2005
Yes, there are chapters for an upcoming book called "Agile Estimating and
Planning" at www.mountaingoatsoftware.com/agileplanning. There used to be
more chapters up there but I'm working on second drafts so I'm only
reposting chapters as I finish second drafts. I'd love to hear thoughts on
the available chapters from anyone interesting in estimating and planning.

Thanks,
Mike Cohn
Author of User Stories Applied for Agile Software Development
www.mountaingoatsoftware.com

-----Original Message-----
From: Hubert Smits [mailto:hubert.smits@...]
Sent: Tuesday, March 08, 2005 1:42 AM
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] Velocity?

Hi Ravi,

I'm unsure if Mike Cohn still has the draft of his new book on
planning on www.mountaingoatsoftware.com. It is all about planning and
very valuable in answering you questions. Have a look and pick the

My personal opinion: don't go too deep with your studies, once you
understand the principles of velocity and burndown charts then go with
your best guess. Planning is an art, not science. And agile planning
doesn't differ in that respect from any other planning.

--Hubert

On Mon, 7 Mar 2005 12:34:42 -0800 (PST), Ravi Srinivasan
<netlimit2000@...> wrote:
>
> Thanks to you all for the prompt response regarding
> the concept of velocity.
>
> I have few more basic questions on velocity.I will
> pick the definition that helped me best understand
> what the velocity means:
>
> "Velocity is essentially the amount of product
> completed over time." - Paul Hodgetts
>
> "The teams with which I've worked multiply their
> available days times an adjustment of 0.4 to 0.8 to
> get the number of ideal days they can accomplish, and
> that helps them figure out their velocity and what
> they can commit to in a sprint." - Paul Hodgetts
>
> Is there any term in SCRUM around the value '0.4'
> mentioned above? 0.4 (or 40%) is used here as an
> estimation that will help the team define its
> velocity.
> This means that depending on the developer, the factor
> could be 40% or 80% and still achieve the velocity
> defined by the team. Right?
>
> Thanks
> Ravi
>
> --- Jeff Sutherland <jeff.sutherland@...>
> wrote:
> > Well, it may be confusing but it is high school
> > physics. You know that
> > about 20% of Americas think that the sun rotates
> > around the earth and
> > 45% of Americans think that water coming out of a
> > coiled hose will
> > flow in a spiral fashion. Not to mention another 45%
> > that think a ball
> > rolling off a table top will hit the floor directly
> > below the edge of
> > the table. An equal number think the earth was
> > years ago, but I digress.
> >
> > Velocity equals the rate of change of distance with
> > time. Acceleration
> > is the rate of change of velocity. This has nothing
> > to do with Scrum.
> >
> > In Scrum, the distance is amount of work done.
> >
> > However, we train people in CSM to use an ideal
> > developer day to
> > estimate work for their team. This concept of an
> > ideal developer day
> > will be different for different Scrum teams. Ergo,
> > productivity can be
> > different across teams with the same velocity.
> >
> > I don't see any new jargon here. We have been using
> > the same words for a decade.
> >
> > Jeff Sutherland
> >
> >
> > On Sun, 6 Mar 2005 11:36:48 -0800, Phlip
> > <phlip2005@...> wrote:
> > >
> > > Jeff Sutherland wrote:
> > >
> > > > Velocity is the rate of change of the burndown
> > chart. Ideally, the
> > > > burndown drops one day per team member every
> > day.
> > >
> > > This answer doubles the amount of undefined
> > jargon, and then adds a
> > > confusing ideal that implies one can _set_ the
> > velocity.
> > >
> > > Who do you think you are?
> > >
> > > Oh, wait. You think you are Jeff Sutherland.
> > >
> > > <impersonation voice="Emily Litela">Never
> > mind.</impersonation>
> > >
> > > --
> > > Phlip
> > >
> >
> http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
> >
>
> __________________________________
> Celebrate Yahoo!'s 10th Birthday!
> Yahoo! Netrospective: 100 Moments of the Web
> http://birthday.yahoo.com/netrospective/
>
> To Post a message, send it to: scrumdevelopment@...
> To Unsubscribe, send a blank message to:
scrumdevelopment-unsubscribe@...