## What's the meaning of "Adjusted Planning Velocity"?

Expand Messages
• I read a document mentioned that, when a Scrum team try to do the estimation, they need to use the Adjusted Planning Velocity - The planning velocity
Message 1 of 19 , Mar 30, 2008
I read a document mentioned that, when a Scrum team try to do the estimation, they need to use the "Adjusted Planning Velocity" - The planning velocity multiply several drag factors. The formula is:

Adjusted Planning Velocity (units are Points/Sprint)
= Planning Velocity x DP x DF x DT x DD

The values of DP, DF, DT and DD are

Proximity(DP)
• Multiple Time Zones: 0.8
• Same Office Building: 1.0
Time Together(DF)
• <3 months: 0.6
• 3 to 12 months: 0.8
• >12 months: 1.0
Knowledge of Technology (DT)
• Low: 0.6
• Medium: 0.8
• High: 1.0
Knowledge of Domain (DD)
• Low: 0.6
• Medium: 0.8
• High: 1.0
The question is, why the drag factor value is smaller as the condition is worth. For example, when the "Knowledge of Technology" is low, the factor value is 0.6. That means the value of Adjusted Planning Velocity is smaller than the original Planning Velocity. It doesn't make sense to me because based on my understanding, if the condition is worth, the adjusted velocity should be larger because the team needs more effort to complete it. I am not quite understand what this adjusted velocity mean and how to use it. Please provide your suggestions and thanks a lot.
• Lidingshan wrote - The question is, why the drag factor value is smaller as the condition is worth. For example, when the Knowledge of Technology is low,
Message 2 of 19 , Mar 30, 2008

Lidingshan wrote – “The question is, why the drag factor value is smaller as the condition is worth. For example, when the "Knowledge of Technology" is low, the factor value is 0.6. That means the value of Adjusted Planning Velocity is smaller than the original Planning Velocity. It doesn't make sense to me because based on my understanding, if the condition is worth, the adjusted velocity should be larger because the team needs more effort to complete it. I am not quite understand what this adjusted velocity mean and how to use it. Please provide your suggestions and thanks a lot. “

When the “knowledge of Technology” is low the factor value is 0.6, which means the things are moving at a lower pace as compared to if the “knowledge of Technology” factor value was 1.0. That shows the downward swift in the Planning velocity.

Confidentiality Notice:

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. If you are not the intended recipient, please notify the sender at admin@... immediately and destroy all the copies of this message and any attachments

• The velocity is the amount of points the team can take per sprint. Giving this, applying a drag factor that lowers the velocity when conditions are worth looks
Message 3 of 19 , Mar 30, 2008
The velocity is the amount of points the team can take per sprint.
Giving this, applying a drag factor that lowers the velocity when
conditions are worth looks logical to me.

Let's say the planning velocity is 100 but the team lacks of domain
knowledge (very low). The adjusted planning velocity is 60. The team
should take items for 60 points only.

On Mon, Mar 31, 2008 at 6:40 AM, lidingshan <lidingshan@...> wrote:
>
>
> I read a document mentioned that, when a Scrum team try to do the estimation, they need to use the "Adjusted Planning Velocity" - The planning velocity multiply several drag factors. The formula is:
>
> Adjusted Planning Velocity (units are Points/Sprint)
> = Planning Velocity x DP x DF x DT x DD
>
> The values of DP, DF, DT and DD are
>
> Proximity(DP)
>
>
> Multiple Time Zones: 0.8
> Same Office Building: 1.0
>
>
> <3 months: 0.6
> 3 to 12 months: 0.8
> >12 months: 1.0Knowledge of Technology (DT)
>
>
> Low: 0.6
> Medium: 0.8
> High: 1.0Knowledge of Domain (DD)
>
>
> Low: 0.6
> Medium: 0.8
> High: 1.0The question is, why the drag factor value is smaller as the condition is worth. For example, when the "Knowledge of Technology" is low, the factor value is 0.6. That means the value of Adjusted Planning Velocity is smaller than the original Planning Velocity. It doesn't make sense to me because based on my understanding, if the condition is worth, the adjusted velocity should be larger because the team needs more effort to complete it. I am not quite understand what this adjusted velocity mean and how to use it. Please provide your suggestions and thanks a lot.
>
>

--
Pascal Thivent
• ... [snip] ... Velocity is the amount of work accomplished. The harder it is, the less accomplished. ... I m not sure you need to use it at all. It could,
Message 4 of 19 , Mar 31, 2008
lidingshan wrote:
> I read a document mentioned that, when a Scrum team try to do the
> estimation, they need to use the "Adjusted Planning Velocity" - The
> planning velocity multiply several drag factors.
[snip]
> The question is, why the drag factor value is smaller as the condition
> is worth. For example, when the "Knowledge of Technology" is low, the
> factor value is 0.6. That means the value of Adjusted Planning Velocity
> is smaller than the original Planning Velocity. It doesn't make sense to
> me because based on my understanding, if the condition is worth, the
> adjusted velocity should be larger because the team needs more effort to
> complete it.

Velocity is the amount of work accomplished. The harder it is, the less
accomplished.

> I am not quite understand what this adjusted velocity mean
> and how to use it. Please provide your suggestions and thanks a lot.

I'm not sure you need to use it at all. It could, perhaps, be useful
for estimating velocity at the start of the project. But after the
first sprint, using the technique of "yesterday's weather" avoids any
calculations.

The technique "yesterday's weather" means to expect to accomplish about
the same amount this sprint as you did the last sprint. Of course there
will be variation from sprint to sprint, but for the most part, it is
not possible to predict this accurately. If you can't be accurate,
there's no point in trying to add extra precision.

If you know there is a major difference, you might want to account for
it. For example, if half the team is leaving, you might guess that
you'll accomplish less than half your former velocity.

Most of the time, however, it's just little things. And since little
things happen all the time, they get reflected in the "yesterday's
weather" number.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
• Pascal Thivent wrote: The velocity is the amount of points the team can take per sprint. Giving this, applying a drag factor that lowers the
Message 5 of 19 , Mar 31, 2008

"Pascal Thivent" <pascal@...> wrote:

The velocity is the amount of points the team can take per sprint.
Giving this, applying a drag factor that lowers the velocity when
conditions are worth looks logical to me.

Let's say the planning velocity is 100 but the team lacks of domain
knowledge (very low). The adjusted planning velocity is 60. The team
should take items for 60 points only.

Do you mean that, when team make the estimation and pick up items totally 100 points, then consider the adjusted velocity, then the team needs to move out total 40 points items from the sprint planning scope?

• Actually, i m not sure how this tool should be used: for the velocity of the first sprint, if conditions change, if a new team is introduced... I remember some
Message 6 of 19 , Apr 1, 2008
Actually, i'm not sure how this tool should be used: for the velocity
of the first sprint, if conditions change, if a new team is
introduced...

Estimate" which is calculated by applying a drag factor to the
original estimate with a similar approach to the one you're
mentioning.

Adjusted estimate = estimate * (1 + drag factor) where the drag factor
varies from 0.8 to 0 and depends on Time Together, Knowledge of
Technology and Knowledge of Domain
Adjusted estimate = estimate * 0.6 if teams are collocated
Adjusted estimate = estimate * 1.4 if more than one team

I may be missing something but I don't really see the point of
applying a drag factor (on estimates or on the velocity) when using
story points. This drag factor is already included in the velocity and
the velocity will increase as the condition get better. This would
make more sense with "Team Days" (or Ideal Team Days) and a fixed
"velocity" equal to the number of days in a sprint.

0On Tue, Apr 1, 2008 at 7:21 AM, lidingshan <lidingshan@...> wrote:
>
>
>
>
>
> "Pascal Thivent" <pascal@...> wrote:
>
> The velocity is the amount of points the team can take per sprint.
> Giving this, applying a drag factor that lowers the velocity when
> conditions are worth looks logical to me.
>
> Let's say the planning velocity is 100 but the team lacks of domain
> knowledge (very low). The adjusted planning velocity is 60. The team
> should take items for 60 points only.
>
> Do you mean that, when team make the estimation and pick up items totally
> 100 points, then consider the adjusted velocity, then the team needs to move
> out total 40 points items from the sprint planning scope?
>
>
>
>
>

--
Pascal Thivent
• I m not sure where/why you heard about some velocity drag factor equation in a CSM course. I never was taught that. The whole idea seems like funny math to
Message 7 of 19 , Apr 2, 2008
I'm not sure where/why you heard about some velocity drag factor equation in a CSM course.  I never was taught that.

The whole idea seems like funny math to me.  For example - how do you quantify the lack of domain knowledge to be .3 or .6?  Or time together - what's that mean?  Is that drinking beers at the pub, working together, etc.

I think this equation help draw awareness to the idea that things like:  the team's domain knowledge, their evolution as a team (forming, storming, norming, performing), and colocation, etc.  all play into the velocity.  I do not know about the whole idea of "adjusted velocity," though.  If the team can take on only 40 pts, rather than 100 pts, their velocity is 40.

I think the idea of saying "Well if you guys were worth your salt you should be able to plan 100 pts, but because you don't have enough togetherness and your all dumb, I only expect you to do 40."  I think that'd would only be a morale killer for a team.  Why not instead simply focus on what the team can do -- which is what you defined velocity as.  All the "drag factors" are already built-in, you don't need to compensate further.  Don't confuse velocity with productivity (which is what it's feeling like you are doing here with the "planning velocity").

The velocity is the velocity... if the Product Owner wants the team to do more then they need to understand what's holding up the team.

Nicholas

On Tue, Apr 1, 2008 at 6:03 PM, Pascal Thivent <pascal@...> wrote:
Actually, i'm not sure how this tool should be used: for the velocity
of the first sprint, if conditions change, if a new team is
introduced...

Estimate" which is calculated by applying a drag factor to the
original estimate with a similar approach to the one you're
mentioning.

Adjusted estimate = estimate * (1 + drag factor) where the drag factor
varies from 0.8 to 0 and depends on Time Together, Knowledge of
Technology and Knowledge of Domain
Adjusted estimate = estimate * 0.6 if teams are collocated
Adjusted estimate = estimate * 1.4 if more than one team

I may be missing something but I don't really see the point of
applying a drag factor (on estimates or on the velocity) when using
story points. This drag factor is already included in the velocity and
the velocity will increase as the condition get better. This would
make more sense with "Team Days" (or Ideal Team Days) and a fixed
"velocity" equal to the number of days in a sprint.

0On Tue, Apr 1, 2008 at 7:21 AM, lidingshan <lidingshan@...> wrote:
>
>
>
>
>
> "Pascal Thivent" <pascal@...> wrote:
>
>  The velocity is the amount of points the team can take per sprint.
>  Giving this, applying a drag factor that lowers the velocity when
>  conditions are worth looks logical to me.
>
>  Let's say the planning velocity is 100 but the team lacks of domain
>  knowledge (very low). The adjusted planning velocity is 60. The team
>  should take items for 60 points only.
>
> Do you mean that, when team make the estimation and pick up items totally
> 100 points, then consider the adjusted velocity, then the team needs to move
> out total 40 points items from the sprint planning scope?
>
>
>
>
>

--
Pascal Thivent

------------------------------------

To Post a message, send it to:   scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:scrumdevelopment-digest@yahoogroups.com
mailto:scrumdevelopment-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

--
Nicholas Cancelliere - Austin, TX
CSM/CSP and Rails Developer

"Try not to become a man of success but rather to become a man of value." --Albert Einstein
• Well, I m sure as I have the paper version on my desk right now : there are some slides about drag factor. Having reread them, I confirm this drag factor was
Message 8 of 19 , Apr 2, 2008
Well, I'm sure as I have the paper version on my desk right now :
there are some slides about drag factor.

Having reread them, I confirm this drag factor was applied on
estimates in *ITD* and that the amount of work to take was based on
the team *capacity* in ITD / sprint, not a velocity in story points.

Check this sample course (http://www.scrumalliance.org/resources/36),
p.37 to 45.

Using story points for estimates has not always been the case and
people did use Ideal days or Ideal Team Days earlier. With ITD, I can
see the need for a drag factor and it juste makes the whole thing very
similar to SP and velocity. It's just more complicated, less
accurate... and I guess that's why we prefer story points today.

Anyhow, as I wrote it, I don't don't see the point of a drag when
using story points and velocity neither. I was just replying to the
original question.

Cheers,

On Wed, Apr 2, 2008 at 7:34 PM, Nicholas Cancelliere
<nickaustin74@...> wrote:
>
>
>
>
> I'm not sure where/why you heard about some velocity drag factor equation in
> a CSM course. I never was taught that.
>
> The whole idea seems like funny math to me. For example - how do you
> quantify the lack of domain knowledge to be .3 or .6? Or time together -
> what's that mean? Is that drinking beers at the pub, working together, etc.
>
> I think this equation help draw awareness to the idea that things like: the
> team's domain knowledge, their evolution as a team (forming, storming,
> norming, performing), and colocation, etc. all play into the velocity. I
> do not know about the whole idea of "adjusted velocity," though. If the
> team can take on only 40 pts, rather than 100 pts, their velocity is 40.
>
> I think the idea of saying "Well if you guys were worth your salt you should
> be able to plan 100 pts, but because you don't have enough togetherness and
> your all dumb, I only expect you to do 40." I think that'd would only be a
> morale killer for a team. Why not instead simply focus on what the team can
> do -- which is what you defined velocity as. All the "drag factors" are
> already built-in, you don't need to compensate further. Don't confuse
> velocity with productivity (which is what it's feeling like you are doing
> here with the "planning velocity").
>
> The velocity is the velocity... if the Product Owner wants the team to do
> more then they need to understand what's holding up the team.
>
> Nicholas
>
>
>
>
>
> On Tue, Apr 1, 2008 at 6:03 PM, Pascal Thivent <pascal@...> wrote:
> >
> >
> >
> > Actually, i'm not sure how this tool should be used: for the velocity
> > of the first sprint, if conditions change, if a new team is
> > introduced...
> >
> > I remember some slides in the CSM course talking about "Adjusted
> > Estimate" which is calculated by applying a drag factor to the
> > original estimate with a similar approach to the one you're
> > mentioning.
> >
> > Adjusted estimate = estimate * (1 + drag factor) where the drag factor
> > varies from 0.8 to 0 and depends on Time Together, Knowledge of
> > Technology and Knowledge of Domain
> > Adjusted estimate = estimate * 0.6 if teams are collocated
> > Adjusted estimate = estimate * 1.4 if more than one team
> >
> > I may be missing something but I don't really see the point of
> > applying a drag factor (on estimates or on the velocity) when using
> > story points. This drag factor is already included in the velocity and
> > the velocity will increase as the condition get better. This would
> > make more sense with "Team Days" (or Ideal Team Days) and a fixed
> > "velocity" equal to the number of days in a sprint.
> >
> >
> > 0On Tue, Apr 1, 2008 at 7:21 AM, lidingshan <lidingshan@...> wrote:
> > >
> > >
> > >
> > >
> > >
> > > "Pascal Thivent" <pascal@...> wrote:
> > >
> > > The velocity is the amount of points the team can take per sprint.
> > > Giving this, applying a drag factor that lowers the velocity when
> > > conditions are worth looks logical to me.
> > >
> > > Let's say the planning velocity is 100 but the team lacks of domain
> > > knowledge (very low). The adjusted planning velocity is 60. The team
> > > should take items for 60 points only.
> > >
> > > Do you mean that, when team make the estimation and pick up items
> totally
> > > 100 points, then consider the adjusted velocity, then the team needs to
> move
> > > out total 40 points items from the sprint planning scope?
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> > --
> > Pascal Thivent
> >
> > ------------------------------------
> >
> >
> >
> > To Post a message, send it to: scrumdevelopment@...
> >
> > To Unsubscribe, send a blank message to:
> >
> >
> >
> >
> >
> >
> >
>
>
>
> --
> Nicholas Cancelliere - Austin, TX
> CSM/CSP and Rails Developer
>
> "Try not to become a man of success but rather to become a man of value."
> --Albert Einstein
>
>

--
Pascal
• Hi, The whole thing sounds like a throwback to defined methods. In fact, it bears a strong resemblance to COCOMO II. Of course it is appealing to think we
Message 9 of 19 , Apr 2, 2008
Hi,

The whole thing sounds like a throwback to defined methods. In fact, it
bears a strong resemblance to COCOMO II. Of course it is appealing to
think we could calibrate our velocity model with this neat set of
factors and values. But we're dealing with complexity here. Which is why
we use an empirical framework.

Yes, we expect the team to produce less DONE software when:
* They are not collocated
* They are a new team
* The domain is novel
* The tools/technology are unfamiliar
* They are unused to collaboration / self-organisation (Scrum) - I added

But, as George says, using "yesterday's weather", or as I recommend, a
rolling average of the last 3 sprints, the team will quickly establish a
reasonable velocity estimate.

And I always try to emphasize that velocity only exists to create (and
update) a credible release plan / product burndown. The only important
measure of progress for the team is shippable business functionality.

Regards,

Peter
CSC

--- In scrumdevelopment@yahoogroups.com, "lidingshan" <lidingshan@...>
wrote:
>
> I read a document mentioned that, when a Scrum team try to do the
> estimation, they need to use the "Adjusted Planning Velocity" - The
> planning velocity multiply several drag factors. The formula is:
>
> Adjusted Planning Velocity (units are Points/Sprint)
> = Planning Velocity x DP x DF x DT x DD
>
> The values of DP, DF, DT and DD are
>
> Proximity(DP)
>
> * Multiple Time Zones: 0.8
> * Same Office Building: 1.0
> Time Together(DF)
>
> * <3 months: 0.6
> * 3 to 12 months: 0.8
> * >12 months: 1.0
> Knowledge of Technology (DT)
>
> * Low: 0.6
> * Medium: 0.8
> * High: 1.0
> Knowledge of Domain (DD)
>
> * Low: 0.6
> * Medium: 0.8
> * High: 1.0
> The question is, why the drag factor value is smaller as the condition
> is worth. For example, when the "Knowledge of Technology" is low, the
> factor value is 0.6. That means the value of Adjusted Planning
Velocity
> is smaller than the original Planning Velocity. It doesn't make sense
to
> me because based on my understanding, if the condition is worth, the
> adjusted velocity should be larger because the team needs more effort
to
> complete it. I am not quite understand what this adjusted velocity
mean
> and how to use it. Please provide your suggestions and thanks a lot.
>
• I think its typically used when you re trying to establish the initial capacity for a team - that have not used Scrum before. Once you ve a few sprints and
Message 10 of 19 , Apr 3, 2008
I think its typically used when you're trying to establish the initial capacity for a team - that have not used Scrum before.

Once you've a few sprints and therefore some history behind you Yesterday's weather is more useful than an emperical calculation.

Mark CS?
----------------------------------------------------------------------
Blog: http://www.notesfromatooluser.com/
One Year of Scrum: Lessons Learned
http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html
Aperture vs. Lightroom - best comparisons
http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html
Customer Retention Department - Vonage Customer Service Sucks
http://www.notesfromatooluser.com/2007/06/customer_retent.html
• There are a number of issues in play here. First off Scrum is so simple and Agile is so lightweight that people are often tempted to improve it with more
Message 11 of 19 , Apr 3, 2008
There are a number of issues in play here. First off Scrum is so
simple and Agile is so lightweight that people are often tempted to
"improve" it with more complex innovations. Virtually all these
mutations are, in my experience, deleterious. Velocity is a simple
empirical observation that is retrospective and helps with longer
range planning. Innovating on that with additional concepts is
no value. For example of you say your velocity is X you are saying
that you observed the team completing X in a given sprint. You can
predict that you will probably deliver X in subsequent sprints. Adding
information. People also seem to think that adding to the complexity
of a mathematical equation adds to it's precision. In that case of
velocity calculations that simply isn't the case.
• I m sorry James - I think your wrong. I don t have time to go through the slide decks from the course but I really do think that this was involved in answering
Message 12 of 19 , Apr 3, 2008
I'm sorry James - I think your wrong. I don't have time to go through the slide decks from the course but I really do think that this was involved in answering the problem of estimating initial capacity so the team has some clue as to how many stories they can safely commit to.

Of course no someone will cite line and verse proving me a fool.

Mark
----------------------------------------------------------------------
Blog: http://www.notesfromatooluser.com/
One Year of Scrum: Lessons Learned
http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html
Aperture vs. Lightroom - best comparisons
http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html
Customer Retention Department - Vonage Customer Service Sucks
http://www.notesfromatooluser.com/2007/06/customer_retent.html
• Mark, For me this would be the worst possible place to use this. A new team establishes its capacity by committing to the backlog items one by one until they
Message 13 of 19 , Apr 4, 2008
Mark,

For me this would be the worst possible place to use this. A new team
establishes its capacity by committing to the backlog items one by one
until they feel unable to take on more. The fidelity is low, but so
what? No formulaic approach such as described in this post will yield a
more accurate result, but the danger is that it may *appear* to.

Peter
CSC

--- In scrumdevelopment@yahoogroups.com, "Mark Levison" <mlevison@...>
wrote:
>
> I think its typically used when you're trying to establish the initial
> capacity for a team - that have not used Scrum before.
>
> Once you've a few sprints and therefore some history behind you
Yesterday's
> weather is more useful than an emperical calculation.
>
> Mark CS?
> ----------------------------------------------------------------------
> Blog: http://www.notesfromatooluser.com/
> One Year of Scrum: Lessons Learned
> http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html
> Aperture vs. Lightroom - best comparisons
> http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html
> Customer Retention Department - Vonage Customer Service Sucks
> http://www.notesfromatooluser.com/2007/06/customer_retent.html
>
• Peter, I m not saying I ve ever used this approach. I m just remembering how it was framed in my CSM course nearly 18 mths ago. Honestly I don t see a huge
Message 14 of 19 , Apr 7, 2008
Peter, I'm not saying I've ever used this approach. I'm just remembering how it was framed in my CSM course nearly 18 mths ago. Honestly I don't see a huge problem if it helps the team limit what they try to take on in the first few iterations.

Every team I've seen over commits for the first little while. My current team has just grown by four team members and all of sudden we're taking on way too much and making a mess of it. In fact some team members are prepared to compromise quality, to get stories "done". As a result I have to act as a brake, reminding them of the importance of quality. If we'd had a better estimate of our initial capacity we might be better off now.

Mark
----------------------------------------------------------------------
Blog: http://www.notesfromatooluser.com/
One Year of Scrum: Lessons Learned
http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html
Aperture vs. Lightroom - best comparisons
http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html
Customer Retention Department - Vonage Customer Service Sucks
http://www.notesfromatooluser.com/2007/06/customer_retent.html
• I don t deny that that s what it s for. My argument is that it is a flawed strategy. In my opinion velocity based planning in sprint 1 is very dangerous. It
Message 15 of 19 , Apr 7, 2008
I don't deny that that's what it's for. My argument is that it is a
flawed strategy. In my opinion velocity based planning in sprint 1 is
very dangerous. It takes several sprints to calibrate your velocity
metrics so trying to base a committment on them (before you have them)
doesn't make sense and is certainly not improved by adding a bunch of
cruft. Rather the team should decompose backlog items until their
available time is filled up and than back off one or two items.
Pretending that we have a "scientific" way of estimating initial
velocity by adding a bunch of multiplication factors feels very
"waterfallish" to me. In any case it is definitely 100% voodoo which
is something agile tries to get away from.

Jimi

--- In scrumdevelopment@yahoogroups.com, "Mark Levison" <mlevison@...>
wrote:
>
> I'm sorry James - I think your wrong. I don't have time to go
through the
> slide decks from the course but I really do think that this was
involved in
> answering the problem of estimating initial capacity so the team has
some
> clue as to how many stories they can safely commit to.
>
> Of course no someone will cite line and verse proving me a fool.
>
> Mark
> ----------------------------------------------------------------------
> Blog: http://www.notesfromatooluser.com/
> One Year of Scrum: Lessons Learned
> http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html
> Aperture vs. Lightroom - best comparisons
> http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html
> Customer Retention Department - Vonage Customer Service Sucks
> http://www.notesfromatooluser.com/2007/06/customer_retent.html
>
• I don t deny that that s what it s for. My argument is that it is a flawed strategy. In my opinion velocity based planning in sprint 1 is very dangerous. It
Message 16 of 19 , Apr 7, 2008
I don't deny that that's what it's for. My argument is that it is a
flawed strategy. In my opinion velocity based planning in sprint 1 is
very dangerous. It takes several sprints to calibrate your velocity
metrics so trying to base a committment on them (before you have them)
doesn't make sense and is certainly not improved by adding a bunch of
cruft. Rather the team should decompose backlog items until their
available time is filled up and than back off one or two items.
Pretending that we have a "scientific" way of estimating initial
velocity by adding a bunch of multiplication factors feels very
"waterfallish" to me. In any case it is definitely 100% voodoo which
is something agile tries to get away from.

Jimi

--- In scrumdevelopment@yahoogroups.com, "Mark Levison" <mlevison@...>
wrote:
>
> I'm sorry James - I think your wrong. I don't have time to go
through the
> slide decks from the course but I really do think that this was
involved in
• I agree. Agile is based on honesty. I don t see anything wrong with saying Look, we re about to kick off our first sprint, with a new team, and a new process.
Message 17 of 19 , Apr 7, 2008
I agree. Agile is based on honesty. I don't see anything wrong with
saying "Look, we're about to kick off our first sprint, with a new
team, and a new process. Frankly, we simply do not *know* how much
we'll get done. Historically, a team knows the least at the beginning
of a project, regardless of the process used. We'll do our best to
estimate the features, but it's likely we'll be off. We'll have a much
better idea how much we can commit to at the end of the upcoming
iteration."

Trying to come up with a "scientific" basis for velocity at this point
in time is asking for trouble.

Mark

--- In scrumdevelopment@yahoogroups.com, "James S. Fosdick, PMP, CSP"
<jsfosdickcsp@...> wrote:
>
> I don't deny that that's what it's for. My argument is that it is a
> flawed strategy. In my opinion velocity based planning in sprint 1 is
> very dangerous. It takes several sprints to calibrate your velocity
> metrics so trying to base a committment on them (before you have them)
> doesn't make sense and is certainly not improved by adding a bunch of
> cruft. Rather the team should decompose backlog items until their
> available time is filled up and than back off one or two items.
> Pretending that we have a "scientific" way of estimating initial
> velocity by adding a bunch of multiplication factors feels very
> "waterfallish" to me. In any case it is definitely 100% voodoo which
> is something agile tries to get away from.
>
> Jimi
>
> --- In scrumdevelopment@yahoogroups.com, "Mark Levison" <mlevison@>
> wrote:
> >
> > I'm sorry James - I think your wrong. I don't have time to go
> through the
> > slide decks from the course but I really do think that this was
> involved in
> > answering the problem of estimating initial capacity so the team has
> some
> > clue as to how many stories they can safely commit to.
> >
> > Of course no someone will cite line and verse proving me a fool.
> >
> > Mark
> > ----------------------------------------------------------------------
> > Blog: http://www.notesfromatooluser.com/
> > One Year of Scrum: Lessons Learned
> > http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html
> > Aperture vs. Lightroom - best comparisons
> > http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html
> > Customer Retention Department - Vonage Customer Service Sucks
> > http://www.notesfromatooluser.com/2007/06/customer_retent.html
> >
>
• I agree with Jim. In fact, I like to use velocity only for release strategies, to look way into the future. For sprint planning I prefer commitment based
Message 18 of 19 , Apr 7, 2008
I agree with Jim. In fact, I like to use velocity only for release
strategies, to look way into the future. For sprint planning I prefer
commitment based planning, which causes the team to actually look at the
stories in front of them,

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628

James S. Fosdick, PMP, CSP wrote:
>
> I don't deny that that's what it's for. My argument is that it is a
> flawed strategy. In my opinion velocity based planning in sprint 1 is
> very dangerous. It takes several sprints to calibrate your velocity
> metrics so trying to base a committment on them (before you have them)
> doesn't make sense and is certainly not improved by adding a bunch of
> cruft. Rather the team should decompose backlog items until their
> available time is filled up and than back off one or two items.
> Pretending that we have a "scientific" way of estimating initial
> velocity by adding a bunch of multiplication factors feels very
> "waterfallish" to me. In any case it is definitely 100% voodoo which
> is something agile tries to get away from.
>
> Jimi
>
> --- In scrumdevelopment@yahoogroups.com
> <mailto:scrumdevelopment%40yahoogroups.com>, "Mark Levison" <mlevison@...>
> wrote:
> >
> > I'm sorry James - I think your wrong. I don't have time to go
> through the
> > slide decks from the course but I really do think that this was
> involved in
> > answering the problem of estimating initial capacity so the team has
> some
> > clue as to how many stories they can safely commit to.
> >
> > Of course no someone will cite line and verse proving me a fool.
> >
> > Mark
> > ----------------------------------------------------------
> > Blog: http://www.notesfromatooluser.com/
> <http://www.notesfromatooluser.com/>
> > One Year of Scrum: Lessons Learned
> > http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html
> <http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html>
> > Aperture vs. Lightroom - best comparisons
> > http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html
> <http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html>
> > Customer Retention Department - Vonage Customer Service Sucks
> > http://www.notesfromatooluser.com/2007/06/customer_retent.html
> <http://www.notesfromatooluser.com/2007/06/customer_retent.html>
> >
>
>
• Velocity number to be used as a tool, it assumes all things being the same... So the team can look at it to tweak their commitments: Do we feel our pace
Message 19 of 19 , Apr 7, 2008
Velocity number to be used as a tool, it assumes "all things being the same..."   So the team can look at it to tweak their commitments:  Do we feel our pace is sustainable?  No - take on less work, yes - take on more work.  As a product owner you can use velocity to try and guess when features will be taken on by the development team.

Anything beyond this and you're starting to move away from empirical methods -- which I think Scrum is about.  Scrum is an empirical approach to project management, we go with what we know and what we've observed.  Crazy math computations to divine the future are not what Scrum is about.  (I still want to know how you quantify "togetherness" as a factor of 0.6 to 1!)

Change a team membership, change the technology stack, etc ... the velocity will change too.  There is no magic formula other than time and observation.

Nicholas

On Mon, Apr 7, 2008 at 2:12 PM, Dan Rawsthorne <dan.rawsthorne@...> wrote:
I agree with Jim. In fact, I like to use velocity only for release
strategies, to look way into the future. For sprint planning I prefer
commitment based planning, which causes the team to actually look at the
stories in front of them,

Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628

James S. Fosdick, PMP, CSP wrote:
>
> I don't deny that that's what it's for. My argument is that it is a
> flawed strategy. In my opinion velocity based planning in sprint 1 is
> very dangerous. It takes several sprints to calibrate your velocity
> metrics so trying to base a committment on them (before you have them)
> doesn't make sense and is certainly not improved by adding a bunch of
> cruft. Rather the team should decompose backlog items until their
> available time is filled up and than back off one or two items.
> Pretending that we have a "scientific" way of estimating initial
> velocity by adding a bunch of multiplication factors feels very
> "waterfallish" to me. In any case it is definitely 100% voodoo which
> is something agile tries to get away from.
>
> Jimi
>
> --- In scrumdevelopment@yahoogroups.com
> <mailto:scrumdevelopment%40yahoogroups.com>, "Mark Levison" <mlevison@...>
> wrote:
> >
> > I'm sorry James - I think your wrong. I don't have time to go
> through the
> > slide decks from the course but I really do think that this was
> involved in
> > answering the problem of estimating initial capacity so the team has
> some
> > clue as to how many stories they can safely commit to.
> >
> > Of course no someone will cite line and verse proving me a fool.
> >
> > Mark
> > ----------------------------------------------------------
> > Blog: http://www.notesfromatooluser.com/
> <http://www.notesfromatooluser.com/>
> > One Year of Scrum: Lessons Learned
> > http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html
> <http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html>
> > Aperture vs. Lightroom - best comparisons
> > http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html
> <http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html>
> > Customer Retention Department - Vonage Customer Service Sucks
> > http://www.notesfromatooluser.com/2007/06/customer_retent.html
> <http://www.notesfromatooluser.com/2007/06/customer_retent.html>
> >
>
>

------------------------------------

To Post a message, send it to:   scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/scrumdevelopment/

<*> To change settings online go to:
http://groups.yahoo.com/group/scrumdevelopment/join
(Yahoo! ID required)

<*> To change settings via email:
mailto:scrumdevelopment-digest@yahoogroups.com
mailto:scrumdevelopment-fullfeatured@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
scrumdevelopment-unsubscribe@yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

--
Nicholas Cancelliere - Austin, TX
CSM/CSP and Rails Developer

"Try not to become a man of success but rather to become a man of value." --Albert Einstein
Your message has been successfully submitted and would be delivered to recipients shortly.