Good points, Jens.
I always try to stick with four-week sprints. However, I will deviate from
that in some circumstances. Here's my rule of thumb:

--The sprint duration is four weeks or the longest amount of time the
organization can commit to not changing its mind about priorities.

I've consulted to a few organizations that are either really messed up or
have a corporate culture that encourages "too much" random change in
priorities. I always pose it as the team commits to delivering functionality
it agrees to but *in return* the organization to commits to not changing
priorities during a sprint. If the organization can't make that commitment
over a full month then there's no way the team can make their commitment. In
those cases I shorten sprints to perhaps two weeks and get the organization
to commit to not changing priorities over that time. In almost all cases
this helps slowly stabilize the culture and we get back to four week sprints
eventually.

--Mike




> -----Original Message-----
> From: Jens Østergaard [mailto:je@...]
> Sent: Tuesday, October 28, 2003 8:19 AM
> To: scrumdevelopment@yahoogroups.com
> Subject: [scrumdevelopment] Re: very long product backlog
>
> Hi
>
> This is an interesting discussion but i must say I am very suspicious
> about shortening the sprints. It seems to me that everybody wants to
> change the SCRUM theories. As a SCRUM master in my company, one of my
> hardest jobs, is to tell people, not to start changing theories
> before we have a referance plan. Seems to me, everybody at my company
> have come up with ideas of how to improve SCRUM. If I would follow
> all of them, we would end up with 4 hour sprints, consisting of 2
> people.
>
> My most important argument against shortening sprints, is that it
> gives the team decreased respronsibilty, which thereby gives
> decreased enjoyment, decreased team dynamic and decreased efficiency.
> Buisness owners usually wants more control and are worried that the
> team can not handle it. I belive it is a SCRUM Masters job to educate
> the buissnes, about letting go. Trust the team, they are good and
> responsible people. But, if the team wants to decrease a certain
> sprint, then I would probably do it for that particular sprint.
>
> SCRUM is a proven method, when you choose to follow the methodology.
> I am a beliver of 4 week sprints.
>
> Jens
>
>
> --- In scrumdevelopment@yahoogroups.com, "Karl Scotland"
> <karl.scotland@b...> wrote:
> >
> >
> > > -----Original Message-----
> > > From: mintywalker [mailto:mintywalker@y...]
> > >
> > > Shorter sprints might work really well.  It is an interesting
> > > idea, as despite seeing Scrum work well, business owners still
> express
> > > concern about being able to be highly re-active to short-notice
> > > requirements.
> > >
> > > On the flip side, I think we might suffer business owner burn out
> with
> > > a sprint review and planning meeting every week.
> > >
> > > All that said, one of the business owners already and seperatly
> > > suggested 2 week sprints.  I believe we have a winner :)
> > >
> >
> > You'll want to scale back your sprint planning and sprint reviews.
> With
> > our 1 week sprints, we've just started doing a combined sprint
> > review/planning meeting at 10am Monday morning, which lasts no
> longer
> > than 2 hours.  We've also found that by the time we get to the
> review,
> > the customer has usually seen most of the functionality already
> because
> > they've been involved with "Customer Testing", so its more of a
> progress
> > report for anyone else whos interested, which doesn't take too long.
> >
> > Karl
> >
> > BBCi at http://www.bbc.co.uk/
> >
> > This e-mail (and any attachments) is confidential and may contain
> > personal views which are not the views of the BBC unless
> specifically
> > stated.
> > If you have received it in error, please delete it from your
> system.
> > Do not use, copy or disclose the information in any way nor act in
> > reliance on it and notify the sender immediately. Please note that
> the
> > BBC monitors e-mails sent or received.
> > Further communication will signify your consent to this.
>
>
>
> To Post a message, send it to:   scrumdevelopment@eGroups.com
> To Unsubscribe, send a blank message to: scrumdevelopment-
> unsubscribe@eGroups.com
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

On Tuesday, October 28, 2003, at 7:19:06 AM, Jens Østergaard wrote:

> Hi

> This is an interesting discussion but i must say I am very suspicious
> about shortening the sprints. It seems to me that everybody wants to
> change the SCRUM theories. As a SCRUM master in my company, one of my
> hardest jobs, is to tell people, not to start changing theories
> before we have a referance plan. Seems to me, everybody at my company
> have come up with ideas of how to improve SCRUM. If I would follow
> all of them, we would end up with 4 hour sprints, consisting of 2
> people.

> My most important argument against shortening sprints, is that it
> gives the team decreased respronsibilty, which thereby gives
> decreased enjoyment, decreased team dynamic and decreased efficiency.
> Buisness owners usually wants more control and are worried that the
> team can not handle it. I belive it is a SCRUM Masters job to educate
> the buissnes, about letting go. Trust the team, they are good and
> responsible people. But, if the team wants to decrease a certain
> sprint, then I would probably do it for that particular sprint.

> SCRUM is a proven method, when you choose to follow the methodology.
> I am a beliver of 4 week sprints.

It is perhaps worth noting, however, that XP has never used a 4-week model,
and that many teams are now doing one-week or two-week iterations, to good
effect.

Ron Jeffries
www.XProgramming.com
Just because we learned something new today doesn't mean we were
frickin' idiots yesterday.  -- Chris Morris, possibly paraphrasing someone.

On Tuesday, October 28, 2003, at 04:19  PM, Jens Østergaard wrote:

> My most important argument against shortening sprints, is that it
> gives the team decreased respronsibilty, which thereby gives
> decreased enjoyment, decreased team dynamic and decreased efficiency.
> Buisness owners usually wants more control and are worried that the
> team can not handle it.

I do not buy this argument - why does a shorter sprint leads to
decreased responsibility, enjoyment, team dynamic? Either I do have a
team that takes responsibility or not. This is at least my observation.
(I had the problem that some of my team mates did not care about what
they did, because they were used to be controlled by somebody (QA, PM,
Customer). On the other hand I like the idea of four week sprints it
would give me the opportunity to work with less breaks, less planing
meetings, less discussion, with business, less feedback meetings, less
rethinking of what we do...

No I do not mean that two week sprints, or one week sprints or 1 day
sprints are the right thing. I want to say - do what is possible in
your organisation. In my organisation I did not not need to argue about
doing sprints because the were willing to wait with new releases for
two weeks. And they wanted to have new things on production whenever
something is ready. (A bug fix, a new functionality, something). To say
to them, they need to wait four weeks, was impossible.

One benefit of two weeks sprints is the higher team dynamic. Because
you have a success every two week - when your code is going live. The
whole world can see it (have a look: www.one.at - you can browse it
with your handset also)! And believe me - this drives.

cheers

boris





Boris Gloger

Vienna, Austria
+43 699 1699 4977

> I do not buy this argument - why does a shorter sprint leads to
> decreased responsibility, enjoyment, team dynamic? Either I do have
a
> team that takes responsibility or not. This is at least my
observation.

Hi Boris and everybody elese from the Edinburgh class

My argument for a 4 week sprint to be more dynamic, is that the team
takes on a bigger portion of responsibility. I am beliver, that
responsibility and team dynamics go hand in hand.

Cheers to Austria - Jens


--- In scrumdevelopment@yahoogroups.com, Boris Gloger <boris@g...>
wrote:
>
> On Tuesday, October 28, 2003, at 04:19  PM, Jens Østergaard wrote:
>
> > My most important argument against shortening sprints, is that it
> > gives the team decreased respronsibilty, which thereby gives
> > decreased enjoyment, decreased team dynamic and decreased
efficiency.
> > Buisness owners usually wants more control and are worried that
the
> > team can not handle it.
>
> I do not buy this argument - why does a shorter sprint leads to
> decreased responsibility, enjoyment, team dynamic? Either I do have
a
> team that takes responsibility or not. This is at least my
observation.
> (I had the problem that some of my team mates did not care about
what
> they did, because they were used to be controlled by somebody (QA,
PM,
> Customer). On the other hand I like the idea of four week sprints
it
> would give me the opportunity to work with less breaks, less
planing
> meetings, less discussion, with business, less feedback meetings,
less
> rethinking of what we do...
>
> No I do not mean that two week sprints, or one week sprints or 1
day
> sprints are the right thing. I want to say - do what is possible in
> your organisation. In my organisation I did not not need to argue
about
> doing sprints because the were willing to wait with new releases
for
> two weeks. And they wanted to have new things on production
whenever
> something is ready. (A bug fix, a new functionality, something). To
say
> to them, they need to wait four weeks, was impossible.
>
> One benefit of two weeks sprints is the higher team dynamic.
Because
> you have a success every two week - when your code is going live.
The
> whole world can see it (have a look: www.one.at - you can browse it
> with your handset also)! And believe me - this drives.
>
> cheers
>
> boris
>
>
>
>
>
> Boris Gloger
>
> Vienna, Austria
> +43 699 1699 4977

> -----Original Message-----
> From: Jens Østergaard [mailto:je@...]
>
> SCRUM is a proven method, when you choose to follow the methodology.
> I am a beliver of 4 week sprints.

As others have noted, I think you have to apply some context, and common sense. 
As a way of explanation, here's our context.

Our process is primarily "inspired by, and aspires to" XP.  As Ron said, XP
works with shorter iterations, and having tried 1, 2 and 4 week iterations, 1
week works best for us at the moment.  I think its because it gives a very godd
feeling of control due to the increased feedback on progress.  If I suggested
moving to 4 week iterations now because of Srum, I'd be laughed at.  The
business doesn't want to have to wait 4 weeks for any software, when we can give
them stuff every week!

Also, I mentioned we have very short projects.  If a 4 week project runs late,
and actually requires 5 weeks to deliver the funtionality, that's a 25% overrun.
If its followed by a 2 week project, that project has lost 50% of its potential
time.  They're quite high percentages, and the business needs to be able to make
quick decisions as to whether to move a release back, or cut scope. If the
feedback on the 4 week project doesn't come until the 4th week, and the business
can't change the plan until the 4th week, that will almost certainly be too
late.  So actually for us, 4 week iterations are constraining the business,
which is not the goal of "Agile".

Basically, I see things like Scrum (and XP) as great out of the box processes
where you have a failing process.  However, untimatley, it's the values and
principles which are more important than the label.

Karl

BBCi at http://www.bbc.co.uk/

This e-mail (and any attachments) is confidential and may contain
personal views which are not the views of the BBC unless specifically
stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in
reliance on it and notify the sender immediately. Please note that the
BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

I have seen definition of process and methodolgy.But its seems to be
same to me.Can any body please explain difference.And what is
difference between methodologies and methods.
Thanks In Advance.

Methodology is the science (or study) of methods. The
word "methodology" has been widely misused in software when the
word "method" should have been used.

For the purposes of software lifecycle development - the
terms "method" and "process" are effectively synonymous. There is an
argument that "method" might be more accurately applied to craft and
that "process" is more accurately applied to a science or a
production system. I don't feel it is worth trying to split those
hairs.

Regards,

David


--- In scrumdevelopment@yahoogroups.com, "jawwad_33"
<jawwad_33@y...> wrote:
> I have seen definition of process and methodolgy.But its seems to
be
> same to me.Can any body please explain difference.And what is
> difference between methodologies and methods.
> Thanks In Advance.

David,

A short note to say I'm delighted to hear you say this - I thought
for a while that I was the only one!

Best Regards
Neil

--- In scrumdevelopment@yahoogroups.com, "David Anderson"
<netherby_uk@y...> wrote:
> Methodology is the science (or study) of methods. The
> word "methodology" has been widely misused in software when the
> word "method" should have been used.
>

All,

We have used 2 week sprints to good effect.  As others have
mentioned, 4 weeks is a long time in a dynamic business.  Our
timescales are generally similar to Karl's.  They have to be or we
will lose customers.

I agree that we have a responsibility as ScrumMasters to follow the
method.  At the same time, I am employed as a professional by the
business to deliver software solutions when THEY need them.  I see
the Scrum method as a tool that helps me to do this.  I need to
decide how best to use this tool, to help me meet the needs of the
business.

Thanks
Neil

--- In scrumdevelopment@yahoogroups.com, "Karl Scotland"
<karl.scotland@b...> wrote:
>
> > -----Original Message-----
> > From: Jens Østergaard [mailto:je@p...]
> >
> > SCRUM is a proven method, when you choose to follow the
methodology.
> > I am a beliver of 4 week sprints.
>
> As others have noted, I think you have to apply some context, and
common sense.  As a way of explanation, here's our context.
>

jawwad_33 wrote:

> I have seen definition of process and methodolgy.But its seems to be
> same to me.Can any body please explain difference.And what is
> difference between methodologies and methods.
>
all these terms have different meanings in the context of software
engineering, but sometimes are
misused. I'll try to give some definitions:

-Process: an ordered  sequence of activities composed of tasks executed
by workers (roles). This sequence not need
to be fixed and defined but you can define appropriate rules
(preconditions, entry criteria, order, etc.) to choose
the next (one or more) activity/ies.

-Method: a method is composed of a process, a set of techniques
(pattern, analysis, design, interviewing, test, techniques etc.), a
language (modeling languages) with which you work applying the method,
roles whom execute tasks, artifact produced, and so on.

-Methodology can have two meanings: the science of methods or a set of
(body) correlated methods.
The latter has been widely used in SE. You should think that 20 years
ago a methodology for the whole software life cycle were composed of
tens of method, for example: a method for data analysis and design, a
completely different set of methods for function analysis and design,
another method for requirements engineering, and so on for test,
implementation, documentation, etc ; all these methods with different
techniques, modeling languages and activities/processes. Today sometimes
people use methodology instead of method for this reason I think, even
thought today a lot of method has been unified thank to OO and a general
advancement of SE.

I prefer to use method when we define its elements from scratch or by
enlargement of a core method. Instead I use methodology when it has been
composed of a set of  methods separately defined.

Regards,
Maurizio

On Thursday, October 30, 2003, at 12:38:16 AM, neil_e_martin2003 wrote:

> A short note to say I'm delighted to hear you say this - I thought
> for a while that I was the only one!

> --- In scrumdevelopment@yahoogroups.com, "David Anderson"
> <netherby_uk@y...> wrote:
>> Methodology is the science (or study) of methods. The
>> word "methodology" has been widely misused in software when the
>> word "method" should have been used.

I wonder whether there is a lesson here:

'When I use a word,' Humpty Dumpty said, in a rather scornful tone,' it
means just what I choose it to mean, neither more nor less.'
   -- Lewis Carroll, Through the Looking Glass.

Ron Jeffries
www.XProgramming.com
For me, XP ain't out there, it's in here. -- Bill Caputo

This answer is really clearly explained.Thanks A lot for u people.

--- In scrumdevelopment@yahoogroups.com, Maurizio Tripi <mtripi@a...>
wrote:
> jawwad_33 wrote:
>
> > I have seen definition of process and methodolgy.But its seems to
be
> > same to me.Can any body please explain difference.And what is
> > difference between methodologies and methods.
> >
> all these terms have different meanings in the context of software
> engineering, but sometimes are
> misused. I'll try to give some definitions:
>
> -Process: an ordered  sequence of activities composed of tasks
executed
> by workers (roles). This sequence not need
> to be fixed and defined but you can define appropriate rules
> (preconditions, entry criteria, order, etc.) to choose
> the next (one or more) activity/ies.
>
> -Method: a method is composed of a process, a set of techniques
> (pattern, analysis, design, interviewing, test, techniques etc.),
a
> language (modeling languages) with which you work applying the
method,
> roles whom execute tasks, artifact produced, and so on.
>
> -Methodology can have two meanings: the science of methods or a set
of
> (body) correlated methods.
> The latter has been widely used in SE. You should think that 20
years
> ago a methodology for the whole software life cycle were composed
of
> tens of method, for example: a method for data analysis and design,
a
> completely different set of methods for function analysis and
design,
> another method for requirements engineering, and so on for test,
> implementation, documentation, etc ; all these methods with
different
> techniques, modeling languages and activities/processes. Today
sometimes
> people use methodology instead of method for this reason I think,
even
> thought today a lot of method has been unified thank to OO and a
general
> advancement of SE.
>
> I prefer to use method when we define its elements from scratch or
by
> enlargement of a core method. Instead I use methodology when it has
been
> composed of a set of  methods separately defined.
>
> Regards,
> Maurizio

Sorry if I were a bit bombastic in my message concerning the number
of weeks a sprint should last.

My concern is that this fine method, called Scrum, will lose in
value, if it is tampered with to much. As Ken said in Edinburgh, let
us worry about some consultant company, that start misusing it to
earn a lot of money.

What I would like to know is, when is it Scrum and when is it not
Scrum? How much can you bend the theories and still call it Scrum?

I think Boris link to "Inspired by Work"
http://www.fastcompany.com/magazine/29/inspired.html
gives some clues, of how difficult it can be?

Jens (who hopes nobody feels offended)

 

A method in my understanding and practice does not need a process -- as per your definition.

 

A method can simply be a generative set of practices and rules that when applied

together can give rise to an **emergent** process -- not an ordered sequence of activities.

 

In other words, Scrum is a declarative method, in the sense that it generates whatever

process is needed by self-organization through the application of rules and practices.

 

As opposed to prescriptive methods that try to tell you a *sequence of steps* to complete

a process,

 

- Mike

-----Original Message-----
From: Maurizio Tripi [mailto:mtripi@...]
Sent: Thursday, October 30, 2003 3:33 AM
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] Process Same As Methodology./Methods..?

jawwad_33 wrote:

> I have seen definition of process and methodolgy.But its seems to be
> same to me.Can any body please explain difference.And what is
> difference between methodologies and methods.
>
all these terms have different meanings in the context of software
engineering, but sometimes are
misused. I'll try to give some definitions:

-Process: an ordered  sequence of activities composed of tasks executed
by workers (roles). This sequence not need
to be fixed and defined but you can define appropriate rules
(preconditions, entry criteria, order, etc.) to choose
the next (one or more) activity/ies.

-Method: a method is composed of a process, a set of techniques
(pattern, analysis, design, interviewing, test, techniques etc.), a 
language (modeling languages) with which you work applying the method,
roles whom execute tasks, artifact produced, and so on.

-Methodology can have two meanings: the science of methods or a set of
(body) correlated methods.
The latter has been widely used in SE. You should think that 20 years
ago a methodology for the whole software life cycle were composed of
tens of method, for example: a method for data analysis and design, a
completely different set of methods for function analysis and design,
another method for requirements engineering, and so on for test,
implementation, documentation, etc ; all these methods with different
techniques, modeling languages and activities/processes. Today sometimes
people use methodology instead of method for this reason I think, even
thought today a lot of method has been unified thank to OO and a general
advancement of SE.

I prefer to use method when we define its elements from scratch or by
enlargement of a core method. Instead I use methodology when it has been
composed of a set of  methods separately defined.

Regards,
Maurizio




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

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


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

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Greetings all,

I am working in a Scrum-oriented team at present and we are in sprint 5.  Things have gone pretty well and we are well-convinced that Scrum helps us a lot.  I have searched the archives of this discussion group and have looked around the internet for software tools to help manage the burndown and the backlog but have been rather disappointed so far.  This is what I have found:

At http://www.controlchaos.com/certifiedscrum/org.htm, there is the "Certified Scrum" which offers a software package bundled with the certification program but the program is listed at US$15000  (ouch!) for a *single* project license.  There also seems to be no evaluation download option for the software.

Recently, I heard of an offering from VersionOne (http://versionone.net/scrum.asp) which started offering a Scrum-oriented tool as of only this month.  E-mails to them have gone unanswered and there is no pricing information on their web site (nor have I found an evaluation copy option) so I don't know either what they really have to offer or whether it is worth whatever they're charging.

These are just two options.  I would like more.  Does anyone know of other options?  Scrum is a great idea but it is hard to sell to management when management tools for Scrum are so hard (and/or dear) to come by!

Thanks.

Eric Chamberlain | Software Engineer | 425 355-6655 | eric.chamberlain@... | www.creo.com
<<...OLE_Obj...>>

>-----Original Message-----
>From: Jens Østergaard [mailto:je@...]
>Sent: Thursday, October 30, 2003 8:42 AM
>To: scrumdevelopment@yahoogroups.com
>Subject: [scrumdevelopment] Bombastic

>My concern is that this fine method, called Scrum, will lose in
>value, if it is tampered with to much. As Ken said in Edinburgh, let
>us worry about some consultant company, that start misusing it to
>earn a lot of money.

>What I would like to know is, when is it Scrum and when is it not
>Scrum? How much can you bend the theories and still call it Scrum?

I think this only matters depending on perspective. From an internal
point of view, that of the project using Scrum, it doesn't matter. If
the process is working, who cares what it is called.

From an external point of view, that of industry or community, the
name has significance. Part of fostering the acceptance of agile
development is education. This requires being able to name what is
agile and what is not, what is Scrum and what is not, etc. From this
point of view, the "what's in a name" debate is necessary to monitor
and defend abuse of the agile brand / identity.

Chris

cs@...
www.atdesigntime.com
www.christiansepulveda.com/blog
tel: 646.522.0654
fax: 888.453.0790

Greetings all,

I am working in a Scrum-oriented team at present and we are in sprint 5.  Things have gone pretty well and we are well-convinced that Scrum helps us a lot.  I have searched the archives of this discussion group and have looked around the internet for software tools to help manage the burndown and the backlog but have been rather disappointed so far.  This is what I have found:

At http://www.controlchaos.com/certifiedscrum/org.htm, there is the "Certified Scrum" which offers a software package bundled with the certification program but the program is listed at US$15000  (ouch!) for a *single* project license.  There also seems to be no evaluation download option for the software.

Recently, I heard of an offering from VersionOne (http://versionone.net/scrum.asp) which started offering a Scrum-oriented tool as of only this month.  E-mails to them have gone unanswered and there is no pricing information on their web site (nor have I found an evaluation copy option) so I don't know either what they really have to offer or whether it is worth whatever they're charging.

These are just two options.  I would like more.  Does anyone know of other options?  Scrum is a great idea but it is hard to sell to management when management tools for Scrum are so hard (and/or dear) to come by!

Thanks.

Eric Chamberlain | Software Engineer | 425 355-6655 | eric.chamberlain@... | www.creo.com
<<...OLE_Obj...>>

-----Original Message-----
From: Eric Chamberlain [mailto:Eric.Chamberlain@...]
Sent: 30 October 2003 17:03
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Tools, Tools, Scrum Tools!

Greetings all,

I am working in a Scrum-oriented team at present and we are in sprint 5.  Things have gone pretty well and we are well-convinced that Scrum helps us a lot.  I have searched the archives of this discussion group and have looked around the internet for software tools to help manage the burndown and the backlog but have been rather disappointed so far.  This is what I have found:

At http://www.controlchaos.com/certifiedscrum/org.htm, there is the "Certified Scrum" which offers a software package bundled with the certification program but the program is listed at US$15000  (ouch!) for a *single* project license.  There also seems to be no evaluation download option for the software.

Recently, I heard of an offering from VersionOne (http://versionone.net/scrum.asp) which started offering a Scrum-oriented tool as of only this month.  E-mails to them have gone unanswered and there is no pricing information on their web site (nor have I found an evaluation copy option) so I don't know either what they really have to offer or whether it is worth whatever they're charging.

These are just two options.  I would like more.  Does anyone know of other options?  Scrum is a great idea but it is hard to sell to management when management tools for Scrum are so hard (and/or dear) to come by!

Thanks.

Eric Chamberlain | Software Engineer | 425 355-6655 | eric.chamberlain@... | www.creo.com
<<...OLE_Obj...>>

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

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Jens Østergaard wrote:

>Sorry if I were a bit bombastic in my message concerning the number
>of weeks a sprint should last.
>
>My concern is that this fine method, called Scrum, will lose in
>value, if it is tampered with to much. As Ken said in Edinburgh, let
>us worry about some consultant company, that start misusing it to
>earn a lot of money.
>
>
I was actually wondering what the community's view was if someone were
to add 2 weeks to a sprint - mostly because the time given from start to
code freeze was 6 weeks instead of 30 days.

Thanks,
Jim

Here is the list of XP/Scrum tools that I know of:

ScrumProduct - most accurate
http://www.controlchaos.com/certifiedscrum/

A wiki - setup a project by creating a page, then setup each Sprint
in separate pages, then setup stories in separate pages, then
setup tasks in different stories.  More on wikis at:
http://c2.com/cgi/wiki?WikiWikiClones

MS Excel  -- same structure as above but stopping at the Sprint level
(no new tabs for stories)

Shared File - A collection of shared files (electronic of otherwise)
with the same structured as described above i.e. one file per Sprint
and naming conventions for stories tasks e.g. "STORY 1 - do this and
that."
That's what I used on my first Scrum project and it worked quite well.

XPlanner - pretty close to Scrum other than the "time to completion"
thing
http://www.xplanner.org

XpCgi
http://xpcgi.sourceforge.net/

XPWeb
http://xpweb.sf.net/

TWiki/ XPTrackerPlugin
http://twiki.org/cgi-bin/view/Plugins/XpTrackerPlugin

M-ASE
http://sern.ucalgary.ca/%7Emilos/mase/M-ASE.htm

Iterate
http://www.diamond-sky.com/products/iterate/

XpPlanIt
http://www.xpplanit.com/

VersionOne
http://www.versionone.net/

Scope
http://www.selectbs.com/products/products/scope_manager.htm">

Bugzilla - you probably have to use naming conventions to break
down stories and use dependencies
http://www.bugzilla.org

GNATS - ready for Scrum per Jeff Sutherland
http://www.gnu.org/directory/GNU/gnats.html

Double Chocolate -- Awesome tool!!!
http://www.gnu.org/directory/GNU/dcl.html

Scarab - no time estimates but expandable out of the box
http://scarab.tigris.org/



I am probably missing a few, anybody else has more tools Scrum friendly
tools?

- Mike



-----Original Message-----
From: Mike Beedle [mailto:beedlem@...]
Sent: Thursday, October 30, 2003 11:18 AM
To: scrumdevelopment@yahoogroups.com
Subject: RE: [scrumdevelopment] Tools, Tools, Scrum Tools!


We use XPlanner with great success,


the only compromise right now, is that it captures "time worked" in a
task as opposed to "time to completion".

But it is a great tool,

- Mike


-----Original Message-----
From: Eric Chamberlain [mailto:Eric.Chamberlain@...]
Sent: Thursday, October 30, 2003 11:03 AM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Tools, Tools, Scrum Tools!


Greetings all,
I am working in a Scrum-oriented team at present and we are in sprint 5.
Things have gone pretty well and we are well-convinced that Scrum helps
us a lot.  I have searched the archives of this discussion group and
have looked around the internet for software tools to help manage the
burndown and the backlog but have been rather disappointed so far.  This
is what I have found: At
http://www.controlchaos.com/certifiedscrum/org.htm, there is the
"Certified Scrum" which offers a software package bundled with the
certification program but the program is listed at US$15000  (ouch!) for
a *single* project license.  There also seems to be no evaluation
download option for the software. Recently, I heard of an offering from
VersionOne (http://versionone.net/scrum.asp) which started offering a
Scrum-oriented tool as of only this month.  E-mails to them have gone
unanswered and there is no pricing information on their web site (nor
have I found an evaluation copy option) so I don't know either what they
really have to offer or whether it is worth whatever they're charging.
These are just two options.  I would like more.  Does anyone know of
other options?  Scrum is a great idea but it is hard to sell to
management when management tools for Scrum are so hard (and/or dear) to
come by! Thanks.
Eric Chamberlain | Software Engineer | 425 355-6655 |
eric.chamberlain@... | www.creo.com
<<...OLE_Obj...>>


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

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Yahoo! Groups Sponsor
ADVERTISEMENT




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

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Date: Tue, 28 Oct 2003 09:59:06 -0000
From: "Karl Scotland"
Subject: RE: Re: very long product backlog

> -----Original Message-----
> From: Mike Cohn [mailto:mike@...]
>
> The problem with six sprint backlogs is that they usually
> don't get adequate
> attention. I don't think it works well when the number of
> sprint backlogs >
> number of developers. I've been working with a team that has three
> developers spread across a family line of 7 unique products. The
> enhancements for each are tracked separately. When we plan a
> new sprint we
> look at all those lists of product backlog and create a single sprint
> backlog. If we had three developers doing seven sprints (each
> with its own
> backlog) it wouldn't work.
>

I have that pattern!

I have a team of 7 developers, working on multiple projects, for
multiple customers. We effectively keep separate product backlogs for
each project, and combine them into a single sprint backlog. Due to the
small size of each project, we work in weekly sprints, so each project
has a number of sprints (say 2 or 3) allocated to it. I'm about to
start doing a burn down chart over the life of a project, rather than
each Sprint, as a weekly burn down seems too small. (Weekly sprints
work because with very small projects, the business priorities really do
change that often!)

Murray, How would it work you kept separate backlogs for each product,
and allocated weekly sprints to each project, based on the projects'
relative priorities?

Karl

-----Original Message-----
From: Hal Macomber [mailto:hal@...]
Sent: Thursday, October 30, 2003 1:13 PM
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] RE: very long product backlog

Really enjoying this topic.  I work primarily in the AEC world.  Trying to get them to design a building in short cycles is impossible.  However when we do get people to work in a Scrum fashion their results are outstanding.

 

One question I have for the group.  Why would you have a small team of people working on multiple projects?  This seems contrary to the spirit of Scrum.  You are designing multi-tasking into their daily lives.  This only delays completion and introduces waste, frustration, and lower quality.  See this posting http://weblog.halmacomber.com/2003_04_13_archive.html#200157736 and this project e-Tip http://halmacomber.com/e-tip_archive/e-tip009.html

 

Am I missing something here?

Karl Scotland wrote:

Date: Tue, 28 Oct 2003 09:59:06 -0000
From: "Karl Scotland"
Subject: RE: Re: very long product backlog

> -----Original Message-----
> From: Mike Cohn [mailto:mike@...]
>
> The problem with six sprint backlogs is that they usually
> don't get adequate
> attention. I don't think it works well when the number of
> sprint backlogs >
> number of developers. I've been working with a team that has three
> developers spread across a family line of 7 unique products. The
> enhancements for each are tracked separately. When we plan a
> new sprint we
> look at all those lists of product backlog and create a single sprint
> backlog. If we had three developers doing seven sprints (each
> with its own
> backlog) it wouldn't work.
>

I have that pattern!

I have a team of 7 developers, working on multiple projects, for
multiple customers. We effectively keep separate product backlogs for
each project, and combine them into a single sprint backlog. Due to the
small size of each project, we work in weekly sprints, so each project
has a number of sprints (say 2 or 3) allocated to it. I'm about to
start doing a burn down chart over the life of a project, rather than
each Sprint, as a weekly burn down seems too small. (Weekly sprints
work because with very small projects, the business priorities really do
change that often!)

Murray, How would it work you kept separate backlogs for each product,
and allocated weekly sprints to each project, based on the projects'
relative priorities?

Karl

Subscribe to Reforming Project Management Enter your email address: Don't miss a posting! Forward to a friend.

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

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

-----Original Message-----
From: Eric Chamberlain [mailto:Eric.Chamberlain@...]
Sent: Thursday, October 30, 2003 12:03 PM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Tools, Tools, Scrum Tools!

Greetings all,

I am working in a Scrum-oriented team at present and we are in sprint 5.  Things have gone pretty well and we are well-convinced that Scrum helps us a lot.  I have searched the archives of this discussion group and have looked around the internet for software tools to help manage the burndown and the backlog but have been rather disappointed so far.  This is what I have found:

At http://www.controlchaos.com/certifiedscrum/org.htm, there is the "Certified Scrum" which offers a software package bundled with the certification program but the program is listed at US$15000  (ouch!) for a *single* project license.  There also seems to be no evaluation download option for the software.

Recently, I heard of an offering from VersionOne (http://versionone.net/scrum.asp) which started offering a Scrum-oriented tool as of only this month.  E-mails to them have gone unanswered and there is no pricing information on their web site (nor have I found an evaluation copy option) so I don't know either what they really have to offer or whether it is worth whatever they're charging.

These are just two options.  I would like more.  Does anyone know of other options?  Scrum is a great idea but it is hard to sell to management when management tools for Scrum are so hard (and/or dear) to come by!

Thanks.

Eric Chamberlain | Software Engineer | 425 355-6655 | eric.chamberlain@... | www.creo.com
<<...OLE_Obj...>>

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

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

-----Original Message-----
From: Mark McCain [mailto:xtremepm_2003@...]
Sent: Sunday, October 26, 2003 1:44 AM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Scrum vs. PMI?

As a PM professional, I use the following methodologies on projects:

 

- Waterfall - government contracts

- Iterative - corporate contracts

- RUP - corporate, large e-business and government contracts

- Scrum - research projects, small e-business projects, small dev projects where the requirements are not well understood.

 

Each of these methodolgies has its place.  PMBOK is not a methodology, nor does it claim to be.  The principles in Scrum are neither new (date back to the 70s) nor in conflict with the processes outlined in PMBOK.  PMI says scope is progressively elaborated throughout the lifecyle of the project.  Change is handled via a change management process, not so unlike the product backlog ( also a change management process).  The Stakeholders (like a product owner) decide what changes are implemented from the change log. Scrum is even more controlling as it pertains to scope because it PREVENTS change during a sprint.  PMI does not say to prevent change, but influence the factors that cause [e.g. poor coding, poor design, functional specs] change -- This point is often mis-interpeted.

 

You shouldn't try to use a screwdriver when you need a hammer, nor should you try to use SCRUM on every project, it doesn't scale well, but great for small teams.

 

This group seems to believe that management is unecessary and that PM's and Functional Managers should all be fired like Mildred the goose.  It is for this very ANTI-MANAGEMENT behavoir that makes it difficult for me to implement Scrum on a lot of my consulting engagements, where it would work very well.

 

There are over 50,000 PMPs and there are barely 250 Scrum Masters.  So before WE start critizing PMI, we should look inward to see how we can improve Scrum instead of knocking time tested methodologies.  In any case, the people in your organization are the most important factor in project success not any single methodology.  If you believe that SCRUM is the antedote to everything you have truly drank the "COOLADE"

 

Poor leadership as a developer, scrumaster, functional manager or PM results in bad morale and results. I've seen a lot more overtime with scrum, due to poor team leadership than under waterfall.  PMI recognizes the difference between leadership and management and strongly advocates that PM's provide leadership to its people and to manage product development (that doesn't mean to exert total control -- and any methodology can be used to manage a project, including scrum).    PMI says the creation of the WBS should be done by the team with the PM faciliating it -- sound familiar to Sprint Planning?   Scrum is much more controlling than the processes that PMI prescribes.  Never is anyone prevented from contributing to the project, where SCRUM has strict, controlling rules to ensure the team and no one else makes the decisions!

 

I think we should spend more time critiquing ourselves and cleaning up our integrity and professional responsibility before knocking very successful methodologies that have built the pryamids, landed us on the moon, developed Unix and Windows and wonder drugs.  We should also look at why the Scrum Methodology prescribes excluding functional managers and PM's from contributing during the sprint.  They are often the most knowledgeable experts.  Surely there is a better way to do this than calling them chickens, perhaps WE are the chickens who can't deal with management.

 

How can we get our management to care about us developers, if we don't respect their role and contributions.

 

Having lead many projects using almost every imaginable methodology from scrum, rup and waterfall, I look forward to a lively discussion that will surely follow.

 

Xtremely yours,

 

Xtremepm_2003

---

Do you Yahoo!?
Exclusive Video Premiere - Britney Spears

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

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

-----Original Message-----
From: Mark McCain [mailto:xtremepm_2003@...]
Sent: Sunday, October 26, 2003 1:44 AM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Scrum vs. PMI?

As a PM professional, I use the following methodologies on projects:

 

- Waterfall - government contracts

- Iterative - corporate contracts

- RUP - corporate, large e-business and government contracts

- Scrum - research projects, small e-business projects, small dev projects where the requirements are not well understood.

 

Each of these methodolgies has its place.  PMBOK is not a methodology, nor does it claim to be.  The principles in Scrum are neither new (date back to the 70s) nor in conflict with the processes outlined in PMBOK.  PMI says scope is progressively elaborated throughout the lifecyle of the project.  Change is handled via a change management process, not so unlike the product backlog ( also a change management process).  The Stakeholders (like a product owner) decide what changes are implemented from the change log. Scrum is even more controlling as it pertains to scope because it PREVENTS change during a sprint.  PMI does not say to prevent change, but influence the factors that cause [e.g. poor coding, poor design, functional specs] change -- This point is often mis-interpeted.

 

You shouldn't try to use a screwdriver when you need a hammer, nor should you try to use SCRUM on every project, it doesn't scale well, but great for small teams.

 

This group seems to believe that management is unecessary and that PM's and Functional Managers should all be fired like Mildred the goose.  It is for this very ANTI-MANAGEMENT behavoir that makes it difficult for me to implement Scrum on a lot of my consulting engagements, where it would work very well.

 

There are over 50,000 PMPs and there are barely 250 Scrum Masters.  So before WE start critizing PMI, we should look inward to see how we can improve Scrum instead of knocking time tested methodologies.  In any case, the people in your organization are the most important factor in project success not any single methodology.  If you believe that SCRUM is the antedote to everything you have truly drank the "COOLADE"

 

Poor leadership as a developer, scrumaster, functional manager or PM results in bad morale and results. I've seen a lot more overtime with scrum, due to poor team leadership than under waterfall.  PMI recognizes the difference between leadership and management and strongly advocates that PM's provide leadership to its people and to manage product development (that doesn't mean to exert total control -- and any methodology can be used to manage a project, including scrum).    PMI says the creation of the WBS should be done by the team with the PM faciliating it -- sound familiar to Sprint Planning?   Scrum is much more controlling than the processes that PMI prescribes.  Never is anyone prevented from contributing to the project, where SCRUM has strict, controlling rules to ensure the team and no one else makes the decisions!

 

I think we should spend more time critiquing ourselves and cleaning up our integrity and professional responsibility before knocking very successful methodologies that have built the pryamids, landed us on the moon, developed Unix and Windows and wonder drugs.  We should also look at why the Scrum Methodology prescribes excluding functional managers and PM's from contributing during the sprint.  They are often the most knowledgeable experts.  Surely there is a better way to do this than calling them chickens, perhaps WE are the chickens who can't deal with management.

 

How can we get our management to care about us developers, if we don't respect their role and contributions.

 

Having lead many projects using almost every imaginable methodology from scrum, rup and waterfall, I look forward to a lively discussion that will surely follow.

 

Xtremely yours,

 

Xtremepm_2003

---

Do you Yahoo!?
Exclusive Video Premiere - Britney Spears

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

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

-----Original Message-----
From: Hal Macomber [mailto:hal@...]
Sent: 30 October 2003 18:13
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] RE: very long product backlog

Really enjoying this topic.  I work primarily in the AEC world.  Trying to get them to design a building in short cycles is impossible.  However when we do get people to work in a Scrum fashion their results are outstanding.

 

One question I have for the group.  Why would you have a small team of people working on multiple projects?  This seems contrary to the spirit of Scrum.  You are designing multi-tasking into their daily lives.  This only delays completion and introduces waste, frustration, and lower quality.  See this posting http://weblog.halmacomber.com/2003_04_13_archive.html#200157736 and this project e-Tip http://halmacomber.com/e-tip_archive/e-tip009.html

 

Am I missing something here?

Karl Scotland wrote:

Date: Tue, 28 Oct 2003 09:59:06 -0000
From: "Karl Scotland"
Subject: RE: Re: very long product backlog

> -----Original Message-----
> From: Mike Cohn [mailto:mike@...]
>
> The problem with six sprint backlogs is that they usually
> don't get adequate
> attention. I don't think it works well when the number of
> sprint backlogs >
> number of developers. I've been working with a team that has three
> developers spread across a family line of 7 unique products. The
> enhancements for each are tracked separately. When we plan a
> new sprint we
> look at all those lists of product backlog and create a single sprint
> backlog. If we had three developers doing seven sprints (each
> with its own
> backlog) it wouldn't work.
&g! t;

I have that pattern!

I have a team of 7 developers, working on multiple projects, for
multiple customers. We effectively keep separate product backlogs for
each project, and combine them into a single sprint backlog. Due to the
small size of each project, we work in weekly sprints, so each project
has a number of sprints (say 2 or 3) allocated to it. I'm about to
start doing a burn down chart over the life of a project, rather than
each Sprint, as a weekly burn down seems too small. (Weekly sprints
work because with very small projects, the business priorities really do
change that often!)

Murray, How would it work you kept separate backlogs for each product,
and allocated weekly sprints to each project, based on the projects'
relative priorities?

Karl

Subscribe to Reforming Project Management Enter your email address: Don't miss a posting! Forward to a friend.

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

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.   

On Thursday, October 30, 2003, at 12:36:51 PM, Jim McCusker wrote:

> I was actually wondering what the community's view was if someone were
> to add 2 weeks to a sprint - mostly because the time given from start to
> code freeze was 6 weeks instead of 30 days.

Two shorter sprints would provide better feedback and more flexibility on
the part of the PM.

Ron Jeffries
www.XProgramming.com
Do, or do not. There is no try.  --Yoda

On Thursday, October 30, 2003, at 12:02:38 PM, Eric Chamberlain wrote:

> I am working in a Scrum-oriented team at present and we are in sprint 5.
> Things have gone pretty well and we are well-convinced that Scrum helps us a
> lot.  I have searched the archives of this discussion group and have looked
> around the internet for software tools to help manage the burndown and the
> backlog but have been rather disappointed so far.

How many items in your backlog? How many are you burning in every sprint?
What's wrong with a piece of paper and a crayon, or Excel?

Ron Jeffries
www.XProgramming.com
Please state the nature of the development emergency. -- Ryan Ripley