On Thu, 3 Mar 2005 19:55:23 +0100, David H. <dmalloc@...> wrote:
>
> > > >
> > > > This is the sort of stuff I can live with and makes sense.  I *have*
> > > > wondered about the "Code has been refactored" requirement.  What if
> > > > code is well factored to start with?  Do we always need to refactor?
> > > >
> > > Refactoring is a big part of Scrum and test driven development in my
> >
> > Scrum defines no engineering practices. That is not to say that
> > refactoring or TDD isn't important, it is just not part of Scrum.
> >
> I beg to differ. But I guess that is purely philosohpical. To me it is
> part of Scrum because scrum does define a methodology that leads to
> certain processes. Maybe one could argue that it is more part of test
> driven development than scrum. But then again, who cares :)

I should clarify my original comment.  Fowler's definition of
refactoring is "the process of changing a software system in such a
way that it does not alter the external behavior of the code yet
improves its internal structure."

My issue was with this statement as a suggested criteria for
completness: "Code has been refactored".  Refactoring describes a
process, not an end state.  I would rather make the criteria something
like "Code is well factored" and describe a desirable state.  To
suggest that all new code written must be refactored is a bit strong,
IMHO.  Certainly there are cases were the initial implementation of
software is reasonably well factored.

--
Chris Brooks
http://www.chrisbrooks.org

>Sure, the work can be chunked into 30
>day sprints, and we can build the application with localized testing for
>the module we just completed, but it can't go to production until
>everything's done.

I think, just like the "pigs and chickens" thing (which is only about who
gets to speak in a daily scrum), people lose track of what the Scrum "rule"
about "potentially implementable" features is all about.

There isn't any rule that your entire product has to be deployable at the
end of every Sprint.  IMHO, the rule about making each Sprint Backlog item
a "potentially implementable" feature has two purposes:

1.  To keep the team focused on "functionality".  Creating an artifact, or
investigating an approach is not a valid SB item.  You need something that
you can demo to the user at the end and show forward movement on
functionality.

2.  To keep the team focused on finishing.  Starting something doesn't
count.  Finishing it does.  Size things so that they can be completed, even
if this means that the incremental gain in functionality is so small as to
be useless to the end user as a practical matter.


I don't see any conflict here with scheduling releases to occur some
quantity of Sprints in the future, nor do I see any conflict with dealing
with necessary pre-release activities.  I don't think you need to be filled
with angst because some feature that you've developed can't be "released"
until the whole system has been stress tested for 2 weeks in a lab.  The
rules do make you think about what you are doing, and potentially knock out
a whole pantload of activities as valid SB items.  For instance:

1.  Documentation
2.  UAT
3.  Unit Testing
4.  User Training
5.  Investigation
6.  Bug fixing (as an open-ended, general activity)

Wouldn't ordinarily qualify.  Instead if a feature needs those items
completed in order to be considered "potentially implementable", then they
should be included in the SB item for the development of that feature.
Even here, though, you may need to make exceptions.  For instance, you may
have a separate documentation department, who work on their own schedule
and need to see a final version of the product before they will update
documention.  The spirit of the thing is the most important:  Only take on
as much stuff as you can finish, and be clear about what "finishing" means.

Dave Barrett,
Lawyers' Professional Indemnity Company

Hi,
  I am new to Agile Dev and I need help to understand
some basic concepts. I am putting them in the form of
some questions:

1. What is velocity?
2. How is velocity related to productivity?
3. Can velocity change during an iteration?
4. What is the industry average of the velocity say
for a simple java web application development work?
5. How is velocity related to Burn rate?
6. Who decides the velocity for a development team?

Any help is much appreciated.

Thanks
Ravi




__________________________________
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/

Ravi Srinivasan wrote:

>  I am new to Agile Dev and I need help to understand
> some basic concepts. I am putting them in the form of
> some questions:
>
> 1. What is velocity?

The number of features your team finished last week.

Schedule that many features this week.

If a feature is hard, pencil 2 on its card, and treat it as 2 features.

(Better, ask the Onsite Customer "what's the smallest part of this
feature that's most important?"...)

> 2. How is velocity related to productivity?

Because teams finish each week with a deliverable product, velocity
_is_ productivity.

> 3. Can velocity change during an iteration?

During a week, you can become aware you are slow. But one only
measures the velocity during the Planning Game, at the start of each
week.

> 4. What is the industry average of the velocity say
> for a simple java web application development work?

Define "simple".

The velocity metric works for one team because there's no way to
compare it to other teams. Some have seasoned veterans who like to
make things too complex. Some have better tools or environment. Some
teams have too many members. Some think their "simple" web application
is harder than others'.

> 5. How is velocity related to Burn rate?

Burn down rate? That's how you chart velocity over time on a burn-down
chart, right?

> 6. Who decides the velocity for a development team?

The team measure its velocity. Nobody decides it, or orders the team
"please attain this velocity this week."

--
Phlip

On Fri, 4 Mar 2005 14:11:12 -0800 (PST), Ravi Srinivasan
<netlimit2000@...> wrote:
> I am new to Agile Dev and I need help to understand
> some basic concepts. [...]
> 1. What is velocity?

Velocity is a term from XP; I don't know if any other agile methods
use it. "Planning Extreme Programming" by (Kent Beck and Martin
Fowler) probably has the best overall explanation. Note that the new
edition of "Extreme Programming Explained" uses a different approach,
and "velocity" doesn't even make the index.

In the PXP approach: you give stories a point-estimate of relative
work. (So a 3-point story is expected to take three times as long as a
one-point story.) Then you count how many story points you complete
each iteration. That's your velocity.

> 2. How is velocity related to productivity?
Sure.

> 3. Can velocity change during an iteration?
I suppose you could say so, but usually we measure at the iteration level.

> 4. What is the industry average of the velocity say
> for a simple java web application development work?

There's no real answer for this. Velocity is unique to each team.
Since the story estimates are relative, your team might say these
three stories are 2, 5, and 1 point; my team might estimate the same
stories as 4, 10, and 2 points. Or my team might even estimate the
same stories as 5, 2, and 1 point! (Perhaps our team is slower on
yours on database work but faster on JSPs.)

> 5. How is velocity related to Burn rate?

I take burn rate to be $ spent over time to "hire" a team. There's
certainly some correlation, in that commercial teams with no people
have $0/month burn rate and 0 velocity, and adding people to a team
raises the burn rate and is expected to eventually improve the
velocity:)

> 6. Who decides the velocity for a development team?
It's a measured quantity.

For the first iteration, the team makes their best guess. At the end
of the iteration, they count up the stories completed. (No partial
credit for half-done stories, by my light.) For the next iteration,
the team takes on that many points. At the end of the second
iteration, they count up their velocity for that iteration, and take
that on for the next one.

A couple side-points:
- The rule above is known as "Yesterday's Weather" (from the idea that
yesterday's weather is a pretty good predictor for today's).
- "No partial credit" makes velocity measure the team's ability to
_complete_ stories, not their effort.
- If you finish all your stories early, you get to add on new stories
mid-iteration. That way your velocity can go up as well as down.
- If you get part-way through an iteration and realize you won't be
able to deliver everything, you work out with your customer which
story is the least valuable, and drop it.
- Velocity tends to stabilize after a few iterations, and you can
project out the rest of the schedule.

I hope this has helped.

--
    Bill Wake  William.Wake@...  www.xp123.com

On Saturday, March 5, 2005, at 6:03:20 AM, William Wake wrote:

>> 5. How is velocity related to Burn rate?

> I take burn rate to be $ spent over time to "hire" a team. There's
> certainly some correlation, in that commercial teams with no people
> have $0/month burn rate and 0 velocity, and adding people to a team
> raises the burn rate and is expected to eventually improve the
> velocity:)

I take the OP to be referring to "burn down", rather than the
conventional dollar burn.

Burn down rate is the rate at which stories or features or backlog
items are being completed by the team. As such, it is almost exactly
analogous to velocity, except that (as I understand it), burn down
rates are usually stories per unit time, and velocity is more
commonly story "difficulty points" per unit time.

Ron Jeffries
www.XProgramming.com
In times of stress, I like to turn to the wisdom of my Portuguese waitress,
who said: "Olá, meu nome é Marisol e eu serei sua garçonete."
   -- after Mark Vaughn, Autoweek.

I've seen some of the management dashboards
(http://www.solutionsiq.com/pbs/scrum.html) that show planned value vs
earned value but I'm curious how this data can be use to compute
project profitability?

What if a task takes more time to perform than estimated for instance?
How can this be shown on a dashboard.

>
> What if a task takes more time to perform than estimated for instance?
> How can this be shown on a dashboard.
>
That only means you aren't perfect at estimating. Which is quite
understandable, it is merely an estimate. But does the _business
value_ of a feature change, just because it took 20 hours rather than
15 hours to implement it? I guess you are asking this with Fixed
Price, fixed delivery date projects in the back of your mind?

-d

Yes, (attempted) Fixed Priced-Fixed Delivery projects. Unfortunately
that's how it is here.

But because we go over on an estimate does not mean the project would
not be profitable; just that the forcasted profit would be less until
the point all margin has been eaten away of course.


On Sun, 6 Mar 2005 00:01:47 +0100, David H. <dmalloc@...> wrote:
> >
> > What if a task takes more time to perform than estimated for instance?
> > How can this be shown on a dashboard.
> >
> That only means you aren't perfect at estimating. Which is quite
> understandable, it is merely an estimate. But does the _business
> value_ of a feature change, just because it took 20 hours rather than
> 15 hours to implement it? I guess you are asking this with Fixed
> Price, fixed delivery date projects in the back of your mind?
>
> -d
>
>
> To Post a message, send it to:   scrumdevelopment@eGroups.com
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@eGroups.com
>
>
> Yahoo! Groups Sponsor
> ADVERTISEMENT
>
> ________________________________
> Yahoo! Groups Links
>
> To visit your group on the web, go to:
> http://groups.yahoo.com/group/scrumdevelopment/
>
> To unsubscribe from this group, send an email to:
> scrumdevelopment-unsubscribe@yahoogroups.com
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Hi,

I wonder if anybody knows of sucessful projects combining SCRUM & UML?

Regards,

Alex

On Sunday, March 6, 2005, at 6:16:00 AM, Alex Jouravlev wrote:

> I wonder if anybody knows of sucessful projects combining SCRUM & UML?

What kind of use of UML are you concerned about? I'm aware of many
projects that draw some UML on the whiteboard from time to time, for
example.

Ron Jeffries
www.XProgramming.com
The main reason that testing at the end of a development cycle finds
problems is not that problems were put in near the end, it is that
testing was put off until then.

Same here...we employ UML in some of our use case work, but only because it
works well for the team, not because of any relationship with Scrum.

> -----Original Message-----
> From: Ron Jeffries [mailto:ronjeffries@...]
> Sent: Sunday, March 06, 2005 6:37 AM
> To: scrumdevelopment@yahoogroups.com
> Subject: Re: [scrumdevelopment] SCRUM & UML
>
>
>
> On Sunday, March 6, 2005, at 6:16:00 AM, Alex Jouravlev wrote:
>
> > I wonder if anybody knows of sucessful projects combining
> SCRUM & UML?
>
> What kind of use of UML are you concerned about? I'm aware of many
> projects that draw some UML on the whiteboard from time to time, for
> example.
>
> Ron Jeffries
> www.XProgramming.com
> The main reason that testing at the end of a development cycle finds
> problems is not that problems were put in near the end, it is that
> testing was put off until then.
>
>
>
>
> To Post a message, send it to:   scrumdevelopment@eGroups.com
> To Unsubscribe, send a blank message to:
> scrumdevelopment-unsubscribe@eGroups.com
> Yahoo! Groups Links
>
>
>
>
>
>
>

-------------------------------------------------------------------------------
This message and any included attachments are from Siemens Medical Solutions
USA, Inc. and are intended only for the addressee(s).
The information contained herein may include trade secrets or privileged or
otherwise confidential information.  Unauthorized review, forwarding, printing,
copying, distributing, or using such information is strictly prohibited and may
be unlawful.  If you received this message in error, or have reason to believe
you are not authorized to receive it, please promptly delete this message and
notify the sender by e-mail with a copy to
Central.SecurityOffice@...

Thank you

The first Scrums built an OOAD tool that supported Rumbaugh and
Coad-Yourdon, i.e. pre-UML, but the practical issues were the same as
they would be with UML.

Very early in the process the tool began to be built with the tool
(eat your own dog food strategy) and pair programming for these Scrums
involved a senior mentor spending a morning in a developers cube.

On the wall were printouts of the OO design of the piece of the
application the developer was working on. The Scrum mentor would often
generate shreds of paper on the floor as the design was reworked from
the drawing posted on the cube wall. The code was then refactored.
When the mentor left, the developer was left to cleanup and provide
the finishing touches (to both his cube and the code).

These sessions could result in 75% of the code in a component being
trashed. The 25% that remained resulted in a new, refactored design,
that was tighter, faster, and more maintainable and expandable. A
rapidly emerging architecture generated in this way produced
remarkable gains in both productivity and customer excitement about
the product.

A short overview of the first Scrums can be found at
http://jeffsutherland.com/scrum by scrolling down to the 13.12.04
posting (that's Euro for 13 Dec 2004).

Jeff Sutherland

Ravi Srinivasan wrote:

  >  I am new to Agile Dev and I need help to understand
  > some basic concepts. I am putting them in the form of
  > some questions:
  >
  > 1. What is velocity?

Bill Wake already gave a good explanation of velocity as used
in XP.  I recommend reading that over a couple of times.

In Scrum, "velocity" is not an official term, AFAIK, although I
have heard Ken use the word in ScrumMaster Certification classes
before.  I tend to use it with my Scrum clients, but with a
disclaimer that I freely steal whatever concepts and practices
from other processes that I find work within Scrum.

Velocity is essentially the amount of product completed over
time.  In Scrum, product is represented as individual chunks of
features and functionality, sliced and diced into individual
line items in our product backlog.  The amount of product is
represented as the estimates we give to our product backlog
items.  Most Scrum teams estimate in some normalized unit such
as ideal days, although I've seen a few Scrum teams use the XP
style of relative estimating described by Bill.  Time in Scrum
is a sprint, which is 30 days.  So, the most common velocity
that is used by a Scrum team is the amount of estimated product
backlog completed for a sprint.

We can also look at velocity at a finer-grained level.  Within
our sprints, we break our backlog items down into smaller tasks,
representing the work done by individuals on the team.  We give
our tasks estimates, usually normalized to something like ideal
hours.  We can therefore also measure our task velocity for a
time unit like a day or a week.  Most Scrum teams track the
ongoing completion of tasks within a sprint, although usually
in terms of the "burn down" of work rather than the velocity.

  > 2. How is velocity related to productivity?

Higher productivity would tend to produce a higher velocity,
all else remaining equal.  A higher velocity might not mean
higher productivity.  For example if we added two new members
to the team we might get higher velocity, but the team's
overall productivity might have actually fallen due to cross-
training.  You would need other variables besides velocity to
determine productivity, IMHO.

  > 3. Can velocity change during an iteration?

Velocity in terms of estimated product completed for a sprint
obviously does not change within an iteration.  Velocity in
terms of estimated tasks completed over a day or week, could
change during a sprint, and in fact is rarely all that smooth
from what I've seen.

  > 4. What is the industry average of the velocity say
  > for a simple java web application development work?

AFAIK, there is no such normalized average.  There are so many
variables when trying to compare teams, not just the type of
application, but also the size of the team, their experience,
their time together, the environment, is it legacy, etc., etc.
The best I can provide are some numbers from teams with which
I've worked, and explain how I use them.

There are several ways to try and estimate your expected
velocity, that I won't get into here, but one of the simplest
is to take a resource like a programmer, figure out how many
you have and how many work days they have in the sprint.  For
example, I might have 4 programmers with 22 working days in the
sprint, for a total of 88 programmer days.  If you have a good
deal of specialized resources that can only work on certain
types of backlog items, this gets more complex.

If I estimate my backlog items in terms of ideal programmer
days, I can correlate the estimates to available bandwidth.  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.  Many new teams are
tempted to try and load up with 1.0 of their available days and
select way too much backlog.  It never works out that way.  You
have to at least allow for normal overhead and various other
factors that introduce "drag" into the team.

In the end, however, the best thing to do is take a best guess
at your first sprint velocity, and go at it.  After the sprint,
look at what you accomplished.  For the next sprint, assume you
will do about the same.  After three or four sprints, you will
have a pretty good idea of what your actual velocity is.  This is
the "yesterday's weather" described by Bill and others.  If you
need an early forward projection of progress, you obviously need
to estimate, but please understand that early estimates have a
very wide error margin to them.  We refine that with the feedback
from actual sprints.

  > 5. How is velocity related to Burn rate?

As others have asked, it's unclear what you mean by "burn rate."

  > 6. Who decides the velocity for a development team?

When trying to estimate forward, the team does.  A Scrum team is
a self-managing group.  There is no "command and control" type
of management, so no one "tells" anyone else how much work they
can do.  The team has the responsibility to estimate the backlog
items and their anticipated velocity, so that they can make
commitments to the Product Owner and the rest of the organization
as to what they expect to complete for a sprint.  This is done in
the sprint planning activities.  Sometimes a team will schedule
a separate longer-range planning session to estimate product
backlog and velocity.

On the other hand, as Phlip mentioned, velocity is really a
measurement.  We will measure our actual velocity and learn what
we are really capable of doing.  If we observe velocities of 43,
48, 39 and 45 over four iterations, the CTO of the company can
tell us to do 75 and it's just not going to happen (without some
drastic change in the context or environment). Scrum is very good
at surfacing reality and making it visible to all.  Changing
people's behavior in response to reality is another issue... ;-)

  > Any help is much appreciated.

I hope some of that helped.  Maybe combined with some of the
other good replies, you can form a larger picture of how velocity
works?

Regards,
Paul
-----
Paul Hodgetts -- CEO, Coach, Trainer, Consultant
Agile Logic  -- www.agilelogic.com
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

Alex Jouravlev wrote:

  > I wonder if anybody knows of sucessful projects combining
  > SCRUM & UML?

Some (at least 5 or more) of the Scrum teams I've coached over
the past few years have used UML in some way.  These teams have
delivered releases, so I would call them "successful."

Some of these teams, as Ron described, use UML as a language
for communicating designs informally on white boards, sheets
of paper, etc.  A few produce technical documentation of their
designs, and somewhat more formally create the UML diagrams
with a tool.  A couple of teams used their tool to reverse
generate some diagrams of interest to capture their evolving
design at milestone points, like the end of a sprint.  I have
not yet worked with a Scrum team that used UML in a Model
Driven Architecture context to generate code from UML models,
but I'm very interested if anyone has done so.

Forgive me if I'm jumping to conclusions, but I've had this
question asked of me by clients and it often leads to this...

Are you really asking about the use of UML as a modeling and
communication language for designs, or are you asking about
some other process, perhaps RUP, that advocates UML within it?

UML is not a process or method.  Scrum is.  There is nothing
about Scrum that includes or excludes the use of UML as a
modeling language if the team chooses to do so as part of
their specific engineering practices.  Scrum wants to travel
light, so we push against excessive or unnecessary practices,
but very little is prohibited by Scrum.

If you are really asking about the combination of another
process, like RUP, with Scrum, that's a whole 'nother topic.
There was a recent article by someone at Rational about it
(look back through the archives) that was, well, somewhat
less than satisfying.  I know of others, including myself,
that have tried to bridge the two for clients.  I'm very
interested in discussing it further if that's what you mean.

Regards,
Paul
-----
Paul Hodgetts -- CEO, Coach, Trainer, Consultant
Agile Logic  -- www.agilelogic.com
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

Rene Poston wrote:

  > Has anyone seen this problem with the Excel plugin for Scrun
  > (see below)?

Unfortunately, attachments are stripped by Yahoo, so the digests
and the list archives do not show them.  I don't get individual
emails, so I didn't see the screen shots (I actually just switched
that, but too late for this message).

But, I have helped a bunch of my clients get the plug-in working.
The most common problem is the missing MS Access DLL, but I've
seen others as well.

Could you describe your problem with some text (like what the
message says)?  Maybe I could help.

Thanks,
Paul
-----
Paul Hodgetts -- CEO, Coach, Trainer, Consultant
Agile Logic  -- www.agilelogic.com
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

Velocity

1. What is velocity?

Velocity is the rate of change of the burndown chart. Ideally, the
burndown drops one day per team member every day.

This is rarely seen in practice, although I have seen teams do it when
they are properly focused.

If you have 7 member of the team, the ideal burndown will drop 7 days
per calendar day. If the burndown starts at

200 days, the ideal burndown chart will be:

y = 200 - 7x where y is the days of work and x is the number of
calendar working days.

The velocity in this case is -7.

In reality, the burndown chart tends to go up during the initial part
of the sprint, and the downward velocity is variable throughout.

2. How is velocity related to productivity?

Velocity is proportional to productivity. It indicates how many units
of work are accomplished per day by the team.

3. Can velocity change during an iteration?

Examine any burndown chart and you will see that it is highly
variable. Teams tend to have their own "signature"

charts that reflect the way they typically do their work in a sprint.

4. What is the industry average of the velocity say
for a simple java web application development work?

If you look at Capers Jones research, they industry average for
typical applications is 3 features points per month per programmer.
There are an average of 54 lines of code per feature point in Java
(same as C++).

Now if the team defined their ideal developer day as industry average
and executed on it they would have perfect velocity. Another team
might define their ideal developer day as six times industry average
and execute on it. Their velocity would look the same on the burndown
chart, but they would deliver six times as much work.

So while velocity is proportional to productivity, it is not a direct measure.

Mike Cohn has data on a Java Scrum that reimplemented a waterfall
project. The waterfall project was industry average and Mike's team
was about 6 times more productive. This is typical for a well running
Scrum. In my experience, only about 10% of them are running well. This
is mainly due to not following Scrum practice, allowing the team to be
interrupted by many things, and the motivation of team members.

5. How is velocity related to Burn rate?

Velocity is the slope of the burn rate.

6. Who decides the velocity for a development team?

The velocity depends on the productivity of the team. This is highly
variable depending on environment, motivation, Scrum execution,
experience, and capability. No one can "decide" on the velocity of the
team. The team can observe their own velocity, identify blocks that
are impeding throughput, remove the blocks, and watch the velocity go
up.

Feel free to correct, add, or modify these comments. They are stream
of consciousness on a lazy Sunday morning after lying on the beach for
a week in Puerto Rico.

Jeff Sutherland


On Fri, 4 Mar 2005 14:11:12 -0800 (PST), Ravi Srinivasan
<netlimit2000@...> wrote:
>
> Hi,
>  I am new to Agile Dev and I need help to understand
> some basic concepts. I am putting them in the form of
> some questions:
>
> 1. What is velocity?
> 2. How is velocity related to productivity?
> 3. Can velocity change during an iteration?
> 4. What is the industry average of the velocity say
> for a simple java web application development work?
> 5. How is velocity related to Burn rate?
> 6. Who decides the velocity for a development team?
>
> Any help is much appreciated.
>
> Thanks
> Ravi

--
Jeff Sutherland, Ph.D.
CTO PatientKeeper Inc.
Certified ScrumMaster Practitioner and Inventor of the Agile Scrum Process
Microsoft Business Framework Advisory Council
Object Management Group/HL7 Liaison Committee
Co-Chair, HL7 Orders and Observations Technical Committee
Co-Investigator, Operating Room of the Future, Univ. of Maryland Medical System
617-947-7400 mobile
jeff.sutherland@...

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

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 created about 4000
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

Actually I did my first burn down chart before high school. I was
about 12 year old... But I did not know about velocity or Scrum
then ;-)

My parents used to take their big 4-week French summer vacations in
Corsica and we had to catch a ferryboat at Marseilles (South of
France) driving from Paris. As the drive took at least 8 hours,
every year there was a certain amount of stress in the family car
about catching the ferry. We had the tendency of setting
unreasonable deadline (not loosing one day of vacation after my dad
last day of work) and we encountered a lot of unplanned traffic jams
(due to the millions of Europeans heading the same day to the
Mediterranean Sea). Sounds like an IT project with unreasonable
deadlines and unforeseen events, doesn't it ;-) Anyhow I created a
simple chart on which I was plotting our progress every few
kilometers and was able to answer with some authority if we had some
chance to make it or not looking at the slope of the (kilometer)
burn down chart. A couple of years later I even started to think of
keeping records of the family car 'velocity' from one year to
another since some events (like traffic jams around the big cities)
were recurring events.

All this to say that the beauty with Scrum is in its simplicity and
burn down charts are amazingly easy to implement tools.

Thierry Thelliez
www.doxcelerate.com

Jeff Sutherland wrote:

> I don't see any new jargon here.

I must work on the message inside my joke...

> Velocity is the rate of change of the burndown chart. Ideally, the
> burndown drops one day per team member every day.

The newbie did not display awareness of terms beyond "velocity" - especially
"burndown chart". Hence, defining velocity in terms of burndown creates a
tautology, with no other references for the newbie to hang onto. My
response, by contrast, simply said "the velocity is the number of features
finished in a week," which pinned the definition back to simpler things.

Then I read your post, and richoche'd off on a tangent, with an English
spin, as usual...

--
   Phlip
   http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

Mike: I respectfully beg to differ:

On Monday, March 7, 2005, at 7:18:26 AM, Mike Beedle wrote:

> If you want to pick up fights this is not the place to do it (I suggest you
> go back to the extreme programming list and pick a fight with the usual
> gorillas, dinosaurs, or mammoths ;-)

Objection.

> -- here at the Scrum list we are busy
> getting our teams to *full speed* through Scrum, not in nitpicking our
> jargon.

Often I do find it difficult to figure out what Phlip is getting at:
I believe that his native language is not mine. However, I also
find, often, that there is a valuable point in his rather "flip"
presentation.

In this case, for example, where he pointed out that the
explanations so far of velocity and such were not as pointed as they
might be. The question was asked by a newcomer and there is special
value in providing clarity to newcomers.

> We don't have any time to waste.

If that were true, would not the above have been a waste of time?

> Scrumers United,

> I suggest we use the English common words *speed*, *velocity* and
> *acceleration* for Scrum as defined by Jeff Sutherland:

> Speed (or 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.

I think these are good words. But the words speed and velocity are
metaphoric in this case, reflecting "distance toward goal" in terms
of features, stories, or whatever burns on your project. The
metaphor is not clear to newcomers: the OP's question makes this
clear. I'm glad that you returned to nitpicking the jargon here,
since it seems to need it.

It was good of the OP to ask rather than guess; good of the
respondents to offer explanations; good of Phlip to point out a gap
in the definitions; and good of you to keep our minds on the
important business of Scrum.

Ron Jeffries
www.XProgramming.com
If we're not shipping our software when it's ready,
it's poor business practice.
If we're not sure whether our software is ready,
it's poor software practice.
http://www.xprogramming.com/blog/Page.aspx?display=FrequentReleases

Ron Jeffries:

So are you now the official "extreme lawyer"?

Well, counselor, please approach the Scrum bench.

Ron Jeffries objected:
> mb wrote:
>> If you want to pick up fights this is not the place to do it (I suggest
>> you go back to the extreme programming list and pick a fight with the
>> usual gorillas, dinosaurs, or mammoths ;-)
>
> Objection.

Sustained :-).

Ron Jeffries wrote:
> Mb wrote:
> > We don't have any time to waste.
> If that were true, would not the above have been a waste of time?

Add infinitum.

Jeff Sutherland appropriately suggested:
> Speed (or 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.

Ron Jeffries wrote:
>I think these are good words. But the words speed and velocity are
>metaphoric in this case, reflecting "distance toward goal" in terms
>of features, stories, or whatever burns on your project. The
>metaphor is not clear to newcomers: the OP's question makes this
>clear. I'm glad that you returned to nitpicking the jargon here,
>since it seems to need it.

Objection overruled.

Counselor, in your humble opinion they are metaphors but for most others
velocity and acceleration already have standard definitions:

"The rate of speed of action or occurrence."
http://dictionary.reference.com/search?q=velocity

"The rate of change of velocity with respect to time."
http://dictionary.reference.com/search?q=acceleration

But are we, in the Agile world, in the business of redefining basic English
(or some other language), at the expense of making things even more
complicated or intuitive?

I agree that we do have some Agile language already defined and that this is
helpful... but these definitions should be used in context --

Scrummers are not XPers, so Scrummers should be mandated to use XP language.

Ron Jeffries wrote:
>It was good of the OP to ask rather than guess; good of the
>respondents to offer explanations; good of Phlip to point out a gap
>in the definitions; and good of you to keep our minds on the
>important business of Scrum.

Thanks for remind us of the "big picture".  Yes, communications (even
violent communications), are better than no communications....  -- keep the
flow going,

- Mike

** I unfortunately will not be able to participate in further discussion on
this:  I have work to do at a client site!

I'll catch up with the thread later on tonight.


-----Original Message-----
From: Ron Jeffries [mailto:ronjeffries@...]
Sent: Monday, March 07, 2005 6:39 AM
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] Velocity?


Mike: I respectfully beg to differ:

On Monday, March 7, 2005, at 7:18:26 AM, Mike Beedle wrote:

> If you want to pick up fights this is not the place to do it (I suggest
you
> go back to the extreme programming list and pick a fight with the usual
> gorillas, dinosaurs, or mammoths ;-)

Objection.

> -- here at the Scrum list we are busy
> getting our teams to *full speed* through Scrum, not in nitpicking our
> jargon.

Often I do find it difficult to figure out what Phlip is getting at:
I believe that his native language is not mine. However, I also
find, often, that there is a valuable point in his rather "flip"
presentation.

In this case, for example, where he pointed out that the
explanations so far of velocity and such were not as pointed as they
might be. The question was asked by a newcomer and there is special
value in providing clarity to newcomers.

> We don't have any time to waste.

If that were true, would not the above have been a waste of time?

> Scrumers United,

> I suggest we use the English common words *speed*, *velocity* and
> *acceleration* for Scrum as defined by Jeff Sutherland:

> Speed (or 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.

I think these are good words. But the words speed and velocity are
metaphoric in this case, reflecting "distance toward goal" in terms
of features, stories, or whatever burns on your project. The
metaphor is not clear to newcomers: the OP's question makes this
clear. I'm glad that you returned to nitpicking the jargon here,
since it seems to need it.

It was good of the OP to ask rather than guess; good of the
respondents to offer explanations; good of Phlip to point out a gap
in the definitions; and good of you to keep our minds on the
important business of Scrum.

Ron Jeffries
www.XProgramming.com
If we're not shipping our software when it's ready,
it's poor business practice.
If we're not sure whether our software is ready,
it's poor software practice.
http://www.xprogramming.com/blog/Page.aspx?display=FrequentReleases




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

Since there seems to be interest in this item, I've tweaked it for
usability and published it again on the Scrums.org wiki. If you are
intersted in (intentially) casual metrics for "how are we doing with
Scrum", have a look. There is now a downloadable excel spreadsheet
with template and example.

http://wiki.scrums.org/index.cgi?ScrumScoreboard

Feel free to send me your questions or improvements so I can post them
- the more the merrier. (You'll find the wiki is read-only due to spam
attacks, a temporary situation only)

Have a good week, all
deb

--- In scrumdevelopment@yahoogroups.com, "Deb" <deborah@h...> wrote:
> ... I've developed a "Scrum Scoreboard" of sorts
> that could be extended to cover other Agile practices too. I'm just
> floating an idea at this point - feedback would be welcome on the
> ScrumRegistry wiki: http://wiki.scrums.org/index.cgi?ScrumScoreboard
>
> Have a good weekend!
> deb

Rene Poston wrote:

  > I installed the ScrumMaster.xla add-in for Excel. However,
  > every time I bring up Excel now I get the following error
  > messages:
  >
  > Could not load an object because its not available on this
  > machine.

Does it show anything that tells us what the object is?

The Scrum plug-in for Excel requires the MS Calendar 10.0
OCX control, which is installed with Microsoft Access.  If
you do not have Access installed on your machine, this
control would be missing.  This is the most common "could
not load object" issue I see when helping my CSMs install
the Scrum plug-in.  It may be what you are seeing.

The message comes up every time you start Excel, because the
Scrum plug-in loads itself up every time you start Excel.

I hunted down the MS Calendar 10.0 OCX Control by searching
the web for it.  I believe I searched for either "MS Calendar
10.0 OCX Control" or "mscal.exe" and found a place where I
could download it.  I have a copy of the OCX control, that I
know solves the issue, if you have no luck locating it.
Please send me an email *off-line* if you need the file.

I hope this helps,
Paul
-----
Paul Hodgetts -- CEO, Coach, Trainer, Consultant
Agile Logic  -- www.agilelogic.com
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

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

--- 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
> created about 4000
> 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/