Release Burndown chart in Excel

[Jeff Martin]

Does anyone have a template or example of how to create an alternative
release burndown chart described by Mike Cohn at
http://www.mountaingoatsoftware.com/alt_releaseburndown?

I've written one using a charting component, but I'm trying to keep
things simple and keeping it in Excel is the simplest path.

Thanks,

Jeff Martin
Senior Developer
Smith Seckman Reid, Inc.
[phone] Direct
[phone] Fax
***@ssr-inc.com <mailto:***@ssr-inc.com>
http://www.ssr-inc.com <http://www.ssr-inc.com/>
P Please do not print this e-mail unless necessary

Notice: This message is confidential, is intended only for the named
recipient(s) and may contain information that is privileged or exempt
from disclosure under applicable law. If you are not the intended
recipient(s), you are notified that the dissemination, distribution or
copying of this message is strictly prohibited. If you received this
message and are not an intended recipient, please delete it from your
computer.

[Jeff Martin]

Nevermind, I figured out how to do it in Excel. If anyone is
interested, email me and I will send you the file.

________________________________

From: ***@yahoogroups.com
[mailto:***@yahoogroups.com] On Behalf Of Jeff Martin
Sent: Wednesday, August 01, 2007 10:29 AM
To: ***@yahoogroups.com
Subject: [scrumdevelopment] Release Burndown chart in Excel



Does anyone have a template or example of how to create an alternative
release burndown chart described by Mike Cohn at
http://www.mountaingoatsoftware.com/alt_releaseburndown
<http://www.mountaingoatsoftware.com/alt_releaseburndown> ?

I've written one using a charting component, but I'm trying to keep
things simple and keeping it in Excel is the simplest path.

Thanks,

Jeff Martin
Senior Developer
Smith Seckman Reid, Inc.
[phone] Direct
[phone] Fax
***@ssr-inc.com <mailto:***@ssr-inc.com>
http://www.ssr-inc.com <http://www.ssr-inc.com/>
P Please do not print this e-mail unless necessary

Notice: This message is confidential, is intended only for the named
recipient(s) and may contain information that is privileged or exempt
from disclosure under applicable law. If you are not the intended
recipient(s), you are notified that the dissemination, distribution or
copying of this message is strictly prohibited. If you received this
message and are not an intended recipient, please delete it from your
computer.

[Mike Cohn]

Hi Jeff--
I saw your later email saying you figured out how to create this type
of burndown chart. But you can see how I do it via the link at the
bottom of:
http://www.mountaingoatsoftware.com/alt_releaseburndown
And if you don't know what this type of burndown bar chart looks
like, it is described on that page which includes a link to an XLS
file for creating them.
Regards,
Mike Cohn
Author:
Agile Estimating and Planning
User Stories Applied
www.mountaingoatsoftware.com

Post by Jeff Martin
Does anyone have a template or example of how to create an
alternative release burndown chart described by Mike Cohn at http://
www.mountaingoatsoftware.com/alt_releaseburndown?
I've written one using a charting component, but I'm trying to keep
things simple and keeping it in Excel is the simplest path.
Thanks,
Jeff Martin
Senior Developer
Smith Seckman Reid, Inc.
[phone] Direct
[phone] Fax
http://www.ssr-inc.com
P Please do not print this e-mail unless necessary
Notice: This message is confidential, is intended only for the
named recipient(s) and may contain information that is privileged
or exempt from disclosure under applicable law. If you are not the
intended recipient(s), you are notified that the dissemination,
distribution or copying of this message is strictly prohibited. If
you received this message and are not an intended recipient, please
delete it from your computer.

[Ilja Preuss]

Post by Jeff Martin
I've written one using a charting component, but I'm trying to keep
things simple and keeping it in Excel is the simplest path.

In my experience, for those kinds of charts, manually drawn diagrams on
flip chart paper, put on a wall for everyone to see, works even better.

Cheers, Ilja


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

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

<*> Your email settings:
Individual Email | Traditional

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

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

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

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

[Jeff Martin]

Except when the CFO emails you and asks you how the project is going,
"walk down to my office and look on the wall" is not the answer he's
looking for. Or when he wants to include the development status in his
monthly board meeting, we are a small chart on a page with a lot of
other charts and information. I'm not going to ask him to drag in a
giant piece of paper with my scribbled drawings on it.



Warning: small rant is ahead and this is in no way aimed at you Ilja, I
value everyone's advice on this mailing list. I've done a significant
amount of reading on agile and Scrum in particular and I read most of
the messages that come through this mailing list. There seems to be
this contingent of the community that believe anything more than index
cards and hand drawn charts are sacrilege. Now, I agree that
concentrating more on the tools than the actual development of the
product is definitely not a good thing. And the first value of agile is
"Individuals and interactions over processes and tools." But it even
states that there is value in the processes and tools, just more value
in the individuals and interactions. If the individuals involved prefer
to track their tasks in a software tool rather than on an index card,
then that's what they should do. If the product owner prefers to see
the burndown as an Excel chart that can be printed, copied and pasted
and emailed over a hand drawn chart, then that's what should happen. I
don't understand the aversion to using software in the process. We
spend our entire career telling companies that we can write software to
improve their businesses and processes, but we're saying we can't
improve our own? That our process is better with index cards and cork
boards? It's very true that most of the "agile" tools on the market are
not agile and either have too much or not enough. But that doesn't mean
that any use of software is A Bad Thing(c).



Isn't the entire point of agile development to do what works for your
team? This thought process that thinks you can't be agile if you are
using a software package to track tasks or you aren't collocated or if
you don't follow the rules to the letter or you have fewer or more than
5-9 people on the team. I'm calling bull on that. Agile is about doing
what works the best. If we all follow the same rules, we're no better
off than we were before. If we all do agile the right way, that
probably means that we'll all be doing things a little differently than
each other. One thing I will concede is that everyone should start off
as simple as possible. I am a firm believer in the concept of knowing
why you are breaking the rules before you start breaking them.



Once again, this is not directed at you Ilja. It's just the result of a
lot of different emails and blog posts.



jeff





From: ***@yahoogroups.com
[mailto:***@yahoogroups.com] On Behalf Of Ilja Preuss
Sent: Saturday, August 04, 2007 12:32 PM
To: ***@yahoogroups.com
Subject: Re: [scrumdevelopment] Release Burndown chart in Excel

Post by Jeff Martin
I've written one using a charting component, but I'm trying to keep
things simple and keeping it in Excel is the simplest path.

In my experience, for those kinds of charts, manually drawn diagrams on
flip chart paper, put on a wall for everyone to see, works even better.

Cheers, Ilja

[George Dinwiddie]

Post by Jeff Martin
Except when the CFO emails you and asks you how the project is going,
"walk down to my office and look on the wall" is not the answer he's
looking for. Or when he wants to include the development status in his
monthly board meeting, we are a small chart on a page with a lot of
other charts and information. I'm not going to ask him to drag in a
giant piece of paper with my scribbled drawings on it.

[rant against simple tools deleted]

Jeff, could it be that your CFO might be looking for some report other
than what's useful within the team? Might an email summarizing how the
project is going answer the question better than forwarding a copy of your
tracking tool?

I'm reminded of a project leader I once had who chastised several of the
team for writing "ate some turkey" on their weekly status report one
November. Apparently, he merely cut and pasted the contents of those
reports into the one he sent to the CEO. Rather than be embarrassed at
his lack of attention to the status and progress of the project, he was
angry that those comments had made visible his lack of oversight.

Now I'm not suggesting that you're not overseeing your project properly.
I am asking, however, if you're presenting it in the best way to upper
management. Perhaps you've settled for the easiest way, instead.

- George
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------




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

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

<*> Your email settings:
Individual Email | Traditional

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

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

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

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

[Clay Ver Valen]

I'd like to stay out of the pros and cons of this and just let the list
know that I've updated the Sprint Tracking Excel template available from
the Scrum Alliance web site.



This new version includes a new worksheet, "Release Burn Down", for
easily creating the Release Burn Down chart as described in Mike Cohn's
earlier posting. Basically, all you need do is fill in the Progress
figures and the rest will just fill in for you with the chart legend
automatically displaying what the anticipated release sprint indicated
by the trendlines is. I just sent the ZIP file to the webmaster so it
should be up there within a couple days at
http://www.scrumalliance.org/resources/18.



For anyone that can't wait, please send me an email message off-list and
I will email you back with the ZIP file attached.



- Clay



From: ***@yahoogroups.com
[mailto:***@yahoogroups.com] On Behalf Of George Dinwiddie
Sent: Monday, August 06, 2007 10:43 AM
To: ***@yahoogroups.com
Subject: RE: [scrumdevelopment] Release Burndown chart in Excel

Post by Jeff Martin
Except when the CFO emails you and asks you how the project is going,
"walk down to my office and look on the wall" is not the answer he's
looking for. Or when he wants to include the development status in his
monthly board meeting, we are a small chart on a page with a lot of
other charts and information. I'm not going to ask him to drag in a
giant piece of paper with my scribbled drawings on it.

[rant against simple tools deleted]

Jeff, could it be that your CFO might be looking for some report other
than what's useful within the team? Might an email summarizing how the
project is going answer the question better than forwarding a copy of
your
tracking tool?

I'm reminded of a project leader I once had who chastised several of the
team for writing "ate some turkey" on their weekly status report one
November. Apparently, he merely cut and pasted the contents of those
reports into the one he sent to the CEO. Rather than be embarrassed at
his lack of attention to the status and progress of the project, he was
angry that those comments had made visible his lack of oversight.

Now I'm not suggesting that you're not overseeing your project properly.

I am asking, however, if you're presenting it in the best way to upper
management. Perhaps you've settled for the easiest way, instead.

- George

[Mike Cohn]

Fantastic, Clay. Thank you for providing this resource to us.
Regards,
Mike Cohn
Author:
Agile Estimating and Planning
User Stories Applied
www.mountaingoatsoftware.com

I’d like to stay out of the pros and cons of this and just let the
list know that I’ve updated the Sprint Tracking Excel template
available from the Scrum Alliance web site.
This new version includes a new worksheet, “Release Burn Down”,
for easily creating the Release Burn Down chart as described in
Mike Cohn’s earlier posting. Basically, all you need do is fill in
the Progress figures and the rest will just fill in for you with
the chart legend automatically displaying what the anticipated
release sprint indicated by the trendlines is. I just sent the ZIP
file to the webmaster so it should be up there within a couple days
at http://www.scrumalliance.org/resources/18.
For anyone that can’t wait, please send me an email message off-
list and I will email you back with the ZIP file attached.
- Clay
Dinwiddie
Sent: Monday, August 06, 2007 10:43 AM
Subject: RE: [scrumdevelopment] Release Burndown chart in Excel

Post by Jeff Martin
Except when the CFO emails you and asks you how the project is

going,

Post by Jeff Martin
"walk down to my office and look on the wall" is not the answer he's
looking for. Or when he wants to include the development status

in his

Post by Jeff Martin
monthly board meeting, we are a small chart on a page with a lot of
other charts and information. I'm not going to ask him to drag in a
giant piece of paper with my scribbled drawings on it.

[rant against simple tools deleted]
Jeff, could it be that your CFO might be looking for some report other
than what's useful within the team? Might an email summarizing how the
project is going answer the question better than forwarding a copy of your
tracking tool?
I'm reminded of a project leader I once had who chastised several of the
team for writing "ate some turkey" on their weekly status report one
November. Apparently, he merely cut and pasted the contents of those
reports into the one he sent to the CEO. Rather than be embarrassed at
his lack of attention to the status and progress of the project, he was
angry that those comments had made visible his lack of oversight.
Now I'm not suggesting that you're not overseeing your project
properly.
I am asking, however, if you're presenting it in the best way to upper
management. Perhaps you've settled for the easiest way, instead.
- George
--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------

[Jeff Martin]

That is a very good question and something I'm still trying to answer.
My company is not only new to scrum, but fairly new to software
development as well. The company does engineering design and are used
to set phases and a project being x% complete. It's funny to see that
they are so precise on the % complete of a project, they will say a
project is 56.8% complete. And we all know there is no way to be that
precise. So, yes, I'm still looking for the best way of providing
information up the ladder. But I still need to provide the burndown
chart to the CFO, as he is the product owner on most of our projects, so
he is part of the team.



From: ***@yahoogroups.com
[mailto:***@yahoogroups.com] On Behalf Of George Dinwiddie
Sent: Monday, August 06, 2007 12:43 PM
To: ***@yahoogroups.com
Subject: RE: [scrumdevelopment] Release Burndown chart in Excel

Post by Jeff Martin
Except when the CFO emails you and asks you how the project is going,
"walk down to my office and look on the wall" is not the answer he's
looking for. Or when he wants to include the development status in his
monthly board meeting, we are a small chart on a page with a lot of
other charts and information. I'm not going to ask him to drag in a
giant piece of paper with my scribbled drawings on it.

[rant against simple tools deleted]

Jeff, could it be that your CFO might be looking for some report other
than what's useful within the team? Might an email summarizing how the
project is going answer the question better than forwarding a copy of
your
tracking tool?

I'm reminded of a project leader I once had who chastised several of the
team for writing "ate some turkey" on their weekly status report one
November. Apparently, he merely cut and pasted the contents of those
reports into the one he sent to the CEO. Rather than be embarrassed at
his lack of attention to the status and progress of the project, he was
angry that those comments had made visible his lack of oversight.

Now I'm not suggesting that you're not overseeing your project properly.

I am asking, however, if you're presenting it in the best way to upper
management. Perhaps you've settled for the easiest way, instead.

- George

[George Dinwiddie]

Jeff,

You might want to look at Quality Software Management, vol 2 for some
other ideas on how to measure and present software progress.

- George

Post by Jeff Martin
That is a very good question and something I'm still trying to answer.
My company is not only new to scrum, but fairly new to software
development as well. The company does engineering design and are used
to set phases and a project being x% complete. It's funny to see that
they are so precise on the % complete of a project, they will say a
project is 56.8% complete. And we all know there is no way to be that
precise. So, yes, I'm still looking for the best way of providing
information up the ladder. But I still need to provide the burndown
chart to the CFO, as he is the product owner on most of our projects, so
he is part of the team.
Sent: Monday, August 06, 2007 12:43 PM
Subject: RE: [scrumdevelopment] Release Burndown chart in Excel

Post by Jeff Martin
Except when the CFO emails you and asks you how the project is going,
"walk down to my office and look on the wall" is not the answer he's
looking for. Or when he wants to include the development status in his
monthly board meeting, we are a small chart on a page with a lot of
other charts and information. I'm not going to ask him to drag in a
giant piece of paper with my scribbled drawings on it.

[rant against simple tools deleted]
Jeff, could it be that your CFO might be looking for some report other
than what's useful within the team? Might an email summarizing how the
project is going answer the question better than forwarding a copy of your
tracking tool?
I'm reminded of a project leader I once had who chastised several of the
team for writing "ate some turkey" on their weekly status report one
November. Apparently, he merely cut and pasted the contents of those
reports into the one he sent to the CEO. Rather than be embarrassed at
his lack of attention to the status and progress of the project, he was
angry that those comments had made visible his lack of oversight.
Now I'm not suggesting that you're not overseeing your project properly.
I am asking, however, if you're presenting it in the best way to upper
management. Perhaps you've settled for the easiest way, instead.
- George
--
----------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------




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

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

<*> Your email settings:
Individual Email | Traditional

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

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

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

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

[matt gelbwaks]

I am with you Jeff.
We are a large Argentine IT Outsourcer working with clients on 4
continents. Some have never been to our HQ, never the less walked down to
the PM's office to see a burndown. It is funny to hear some of the rants
people have against modifying Scrum or XP or Agile to suit your enterprise
or organization. It is also funny to hear people hold the line on these
methodologies being meant for small collocated teams only and therefore you
can't use software to automate certain aspects of the approach. I get much
mirth out of this last one because it so seems that people forget what we
are doing - we are building software to automate tasks that people can no
longer do without automation. We are a global community now, IT is, so we
need to automate certain aspects of it. You are also quite correct in that
we must understand all the deviations we make. I am having this
conversation right now with our internal and external assessors to teach
them that, through moderation, we can be both Agile and CMMI. And we can,
and we will. Just like you can have an excel spreadsheet for your burndown
chart (with automated trend lines!!!!).
Ping me off list if you still need a template.

m

Post by Jeff Martin
Except when the CFO emails you and asks you how the project is going,
"walk down to my office and look on the wall" is not the answer he's looking
for. Or when he wants to include the development status in his monthly
board meeting, we are a small chart on a page with a lot of other charts and
information. I'm not going to ask him to drag in a giant piece of paper
with my scribbled drawings on it.
Warning: small rant is ahead and this is in no way aimed at you Ilja, I
value everyone's advice on this mailing list. I've done a significant
amount of reading on agile and Scrum in particular and I read most of the
messages that come through this mailing list. There seems to be this
contingent of the community that believe anything more than index cards and
hand drawn charts are sacrilege. Now, I agree that concentrating more on
the tools than the actual development of the product is definitely not a
good thing. And the first value of agile is "Individuals and interactions
over processes and tools." But it even states that there is value in the
processes and tools, just more value in the individuals and interactions.
If the individuals involved prefer to track their tasks in a software tool
rather than on an index card, then that's what they should do. If the
product owner prefers to see the burndown as an Excel chart that can be
printed, copied and pasted and emailed over a hand drawn chart, then that's
what should happen. I don't understand the aversion to using software in
the process. We spend our entire career telling companies that we can write
software to improve their businesses and processes, but we're saying we
can't improve our own? That our process is better with index cards and cork
boards? It's very true that most of the "agile" tools on the market are not
agile and either have too much or not enough. But that doesn't mean that
any use of software is A Bad Thing(c).
Isn't the entire point of agile development to do what works for your
team? This thought process that thinks you can't be agile if you are using
a software package to track tasks or you aren't collocated or if you don't
follow the rules to the letter or you have fewer or more than 5-9 people on
the team. I'm calling bull on that. Agile is about doing what works the
best. If we all follow the same rules, we're no better off than we were
before. If we all do agile the right way, that probably means that we'll
all be doing things a little differently than each other. One thing I will
concede is that everyone should start off as simple as possible. I am a
firm believer in the concept of knowing why you are breaking the rules
before you start breaking them.
Once again, this is not directed at you Ilja. It's just the result of a
lot of different emails and blog posts.
jeff
*Sent:* Saturday, August 04, 2007 12:32 PM
*Subject:* Re: [scrumdevelopment] Release Burndown chart in Excel

Post by Jeff Martin
I've written one using a charting component, but I'm trying to keep
things simple and keeping it in Excel is the simplest path.

In my experience, for those kinds of charts, manually drawn diagrams on
flip chart paper, put on a wall for everyone to see, works even better.
Cheers, Ilja

[Neeraj Deginal]

I think people are sharing more of their experiences. Using software or
doing it manually is purely individual/team's preference and
requirement. SCRUM does not define any rule as such. I agree that any
methodology we use should help us get better results.



Neeraj



-----Original Message-----
From: ***@yahoogroups.com
[mailto:***@yahoogroups.com] On Behalf Of matt gelbwaks
Sent: Tuesday, August 07, 2007 5:48 AM
To: ***@yahoogroups.com
Subject: [SPAM] Re: [scrumdevelopment] Release Burndown chart in Excel
Importance: Low



I am with you Jeff.
We are a large Argentine IT Outsourcer working with clients on 4
continents. Some have never been to our HQ, never the less walked down
to the PM's office to see a burndown. It is funny to hear some of the
rants people have against modifying Scrum or XP or Agile to suit your
enterprise or organization. It is also funny to hear people hold the
line on these methodologies being meant for small collocated teams only
and therefore you can't use software to automate certain aspects of the
approach. I get much mirth out of this last one because it so seems
that people forget what we are doing - we are building software to
automate tasks that people can no longer do without automation. We are
a global community now, IT is, so we need to automate certain aspects of
it. You are also quite correct in that we must understand all the
deviations we make. I am having this conversation right now with our
internal and external assessors to teach them that, through moderation,
we can be both Agile and CMMI. And we can, and we will. Just like you
can have an excel spreadsheet for your burndown chart (with automated
trend lines!!!!).
Ping me off list if you still need a template.

m
Except when the CFO emails you and asks you how the project is going,
"walk down to my office and look on the wall" is not the answer he's
looking for. Or when he wants to include the development status in his
monthly board meeting, we are a small chart on a page with a lot of
other charts and information. I'm not going to ask him to drag in a
giant piece of paper with my scribbled drawings on it.



Warning: small rant is ahead and this is in no way aimed at you Ilja, I
value everyone's advice on this mailing list. I've done a significant
amount of reading on agile and Scrum in particular and I read most of
the messages that come through this mailing list. There seems to be
this contingent of the community that believe anything more than index
cards and hand drawn charts are sacrilege. Now, I agree that
concentrating more on the tools than the actual development of the
product is definitely not a good thing. And the first value of agile is
"Individuals and interactions over processes and tools." But it even
states that there is value in the processes and tools, just more value
in the individuals and interactions. If the individuals involved prefer
to track their tasks in a software tool rather than on an index card,
then that's what they should do. If the product owner prefers to see
the burndown as an Excel chart that can be printed, copied and pasted
and emailed over a hand drawn chart, then that's what should happen. I
don't understand the aversion to using software in the process. We
spend our entire career telling companies that we can write software to
improve their businesses and processes, but we're saying we can't
improve our own? That our process is better with index cards and cork
boards? It's very true that most of the "agile" tools on the market are
not agile and either have too much or not enough. But that doesn't mean
that any use of software is A Bad Thing(c).



Isn't the entire point of agile development to do what works for your
team? This thought process that thinks you can't be agile if you are
using a software package to track tasks or you aren't collocated or if
you don't follow the rules to the letter or you have fewer or more than
5-9 people on the team. I'm calling bull on that. Agile is about doing
what works the best. If we all follow the same rules, we're no better
off than we were before. If we all do agile the right way, that
probably means that we'll all be doing things a little differently than
each other. One thing I will concede is that everyone should start off
as simple as possible. I am a firm believer in the concept of knowing
why you are breaking the rules before you start breaking them.



Once again, this is not directed at you Ilja. It's just the result of a
lot of different emails and blog posts.



jeff





From: ***@yahoogroups.com
<mailto:***@yahoogroups.com>
[mailto:***@yahoogroup s.com] On Behalf Of Ilja Preuss
Sent: Saturday, August 04, 2007 12:32 PM
To: ***@yahoogroups.com
<mailto:***@yahoogroups.com>
Subject: Re: [scrumdevelopment] Release Burndown chart in Excel

Post by Jeff Martin
I've written one using a charting component, but I'm trying to keep
things simple and keeping it in Excel is the simplest path.

In my experience, for those kinds of charts, manually drawn diagrams on
flip chart paper, put on a wall for everyone to see, works even better.

Cheers, Ilja

[Ilja Preuss]

Post by matt gelbwaks
It is funny to hear some of the
rants people have against modifying Scrum or XP or Agile to suit your
enterprise or organization.

Part of that is coming from experience with people who modify the
approach without understanding how the original works - see
http://www.xprogramming.com/xpmag/jatBaseball.htm for a humorous take on it.

Of course there are also valid reasons for modifying the game - if you
were playing on the moon, for example, you probably had to apply heavy
modifications to make it work at all. I wouldn't be surprised if
baseball fans would be kind of upset if the resulting game still would
be called baseball.

Post by matt gelbwaks
It is also funny to hear people hold the
line on these methodologies being meant for small collocated teams only

What's funny about that???

Post by matt gelbwaks
and therefore you can't use software to automate certain aspects of the
approach.

I have never seen the reasoning that way.

It's certainly true, though, that to the extent that your team being big
or distributed forces you to use software tools, you simply can't be as
Agile as smaller, colocated teams. Does that thought trouble you?

Post by matt gelbwaks
I get much mirth out of this last one because it so seems
that people forget what we are doing - we are building software to
automate tasks that people can no longer do without automation.

I'm not forgetting that at all. Does that mean that we should blindly
use software to automate everything, whithout caring about whether it
seems to be effective or not? Or what else are you getting at here?

Post by matt gelbwaks
We are
a global community now, IT is, so we need to automate certain aspects of
it.

All Agile proponents are saying, as far as I can tell, is that being
distributed will invariably make you less effective - partly because you
will have to use software tools instead of more direct forms of
communication and collaboration.

Is that something you disagree with?

Post by matt gelbwaks
Just like you
can have an excel spreadsheet for your burndown chart (with automated
trend lines!!!!).

Sure you can. I deem it to be interesting to talk about the pros and
cons of doing so, but that might just be me.

Cheers, Ilja


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

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

<*> Your email settings:
Individual Email | Traditional

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

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

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

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

[matt gelbwaks]

This type of conversation/argument is easier in person, as simple
misunderstandings of emphasis are easily clarified.

I certainly agree with you on most of your points, as you seem to be
agreeing and accentuating mine.

One point I would like to clarify, though: there are no absolutes in any
business where people are involved. You state

Post by Ilja Preuss
to the extent that your team being big
or distributed forces you to use software tools, you simply can't be as
Agile as smaller, colocated teams.

I have worked with both functional and disfunctional teams, large and
small. Many improved for my presence (though not all). Some big teams had
stunning thoughput with low overhead. Some small teams were so poorly
gelled and motivated that their through put was nearly non-existent. This
doesn't trouble me. I always say that a good coach has enough experience to
be able to look at any team and quickly make some changes to increase their
throughput. In some cases it may be automating software, in others, it
maybe some exercises to increase trust or understanding. But in no case,
does the thought bother me. I never try to achieve the theoretical maximum
- I just want to see the team go far enough up the curve so that their
productivity is on the level part of the asymptote.

Post by Ilja Preuss
All Agile proponents are saying, as far as I can tell, is that being
distributed will invariably make you less effective - partly because you
will have to use software tools instead of more direct forms of
communication and collaboration.

is very valid, though I would point out merely that it is "tools" not
"software tools" that you must use (phones, video links, web meetings, as
well as spreadsheets, tracking tools, etc).


m

[Ilja Preuss]

Post by matt gelbwaks
This type of conversation/argument is easier in person, as simple
misunderstandings of emphasis are easily clarified.

So true!

Post by matt gelbwaks
I certainly agree with you on most of your points, as you seem to be
agreeing and accentuating mine.

Ok.

Post by matt gelbwaks
One point I would like to clarify, though: there are no absolutes in any
business where people are involved. You state
to the extent that your team being big
or distributed forces you to use software tools, you simply can't be as
Agile as smaller, colocated teams.
I have worked with both functional and disfunctional teams, large and
small. Many improved for my presence (though not all). Some big teams
had stunning thoughput with low overhead. Some small teams were so
poorly gelled and motivated that their through put was nearly
non-existent. This doesn't trouble me. I always say that a good coach
has enough experience to be able to look at any team and quickly make
some changes to increase their throughput. In some cases it may be
automating software, in others, it maybe some exercises to increase
trust or understanding. But in no case, does the thought bother me. I
never try to achieve the theoretical maximum - I just want to see the
team go far enough up the curve so that their productivity is on the
level part of the asymptote.

I totally agree. I can't imagine that you would typically improve a
dysfunctional team by adding people (although just the right person
might actually work), or by distributing the team members, though. I can
imagine the opposite.

Post by matt gelbwaks
All Agile proponents are saying, as far as I can tell, is that being
distributed will invariably make you less effective - partly because you
will have to use software tools instead of more direct forms of
communication and collaboration.
is very valid, though I would point out merely that it is "tools" not
"software tools" that you must use (phones, video links, web meetings,
as well as spreadsheets, tracking tools, etc).

"Software tools" wasn't meant exclusively, of course.

Cheers, Ilja


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

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

<*> Your email settings:
Individual Email | Traditional

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

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

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

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

[Petri Heiramo]

I agree with what Jeff said.

Post by Jeff Martin
Except when the CFO emails you and asks you how the project is going,
"walk down to my office and look on the wall" is not the answer he's
looking for. Or when he wants to include the development status in his
monthly board meeting, we are a small chart on a page with a lot of
other charts and information. I'm not going to ask him to drag in a
giant piece of paper with my scribbled drawings on it.

Every project has stakeholders whose needs it must satisfy. I wouldn't
call that a general requirement, but an environmental variable that
favors using tools that do provide the needed information in desired
format. I'm sure the team would understand that, and take the effort
to use the necessary tools (I mean, wow, the CEO is taking interest in
our progress!).

Post by Jeff Martin
Warning: small rant is ahead and this is in no way aimed at you Ilja, I
value everyone's advice on this mailing list. I've done a significant
amount of reading on agile and Scrum in particular and I read most of
the messages that come through this mailing list. There seems to be
this contingent of the community that believe anything more than index
cards and hand drawn charts are sacrilege. Now, I agree that
concentrating more on the tools than the actual development of the
product is definitely not a good thing. And the first value of agile is
"Individuals and interactions over processes and tools." But it even
states that there is value in the processes and tools, just more value
in the individuals and interactions. If the individuals involved prefer
to track their tasks in a software tool rather than on an index card,
then that's what they should do. If the product owner prefers to see
the burndown as an Excel chart that can be printed, copied and pasted
and emailed over a hand drawn chart, then that's what should happen. I
don't understand the aversion to using software in the process. We
spend our entire career telling companies that we can write software to
improve their businesses and processes, but we're saying we can't
improve our own? That our process is better with index cards and cork
boards? It's very true that most of the "agile" tools on the market are
not agile and either have too much or not enough. But that doesn't mean
that any use of software is A Bad Thing(c).

Long quote, but that's exactly what I've seen happen in our projects.
There are teams that prefer the visual wall boards and teams that like
to use some tool, even when all those teams are co-located. Dispersed
teams are a different matter, obviously. Tools are often necessary;
e.g. you can't automate testing without appropriate and effective tools.

Post by Jeff Martin
Isn't the entire point of agile development to do what works for your
team? This thought process that thinks you can't be agile if you are
using a software package to track tasks or you aren't collocated or if
you don't follow the rules to the letter or you have fewer or more than
5-9 people on the team. I'm calling bull on that. Agile is about doing
what works the best.

Exactly, but that doesn't stop me from recommending every collocated
team to test out the wall chart technique. Of course I say that there
are also tools, which they can then try out if the manual technique
doesn't suit them. Even then I've seen teams go to tools immediately
:), which is fine of course.


Petri Heiramo
Process Improvement Manager
SYSOPENDIGIA Plc., Finland




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

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

<*> Your email settings:
Individual Email | Traditional

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

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

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

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

[Ilja Preuss]

Post by Jeff Martin
Except when the CFO emails you and asks you how the project is going,
“walk down to my office and look on the wall” is not the answer he’s
looking for.

Then don't answer that. The team (assuming that it's colocated) still
needs it on the wall, in my experience.

Post by Jeff Martin
Or when he wants to include the development status in his
monthly board meeting, we are a small chart on a page with a lot of
other charts and information.

Then he should somehow get that small chart on the page. Which just
means that he simply can't use the chart the team is using as-is.

Post by Jeff Martin
I’m not going to ask him to drag in a
giant piece of paper with my scribbled drawings on it.

Agreed. I don't know anyone who suggested it.

Post by Jeff Martin
There seems to be
this contingent of the community that believe anything more than index
cards and hand drawn charts are sacrilege.

My impression is that that contingent is *very* small, and that it often
gets confused with those who believe that people who never have tried
index cards and hand drawn charts for a significant amount of time are
in a bad position to assess their importance.

Post by Jeff Martin
Now, I agree that
concentrating more on the tools than the actual development of the
product is definitely not a good thing. And the first value of agile is
“Individuals and interactions over processes and tools.” But it even
states that there is value in the processes and tools, just more value
in the individuals and interactions. If the individuals involved prefer
to track their tasks in a software tool rather than on an index card,
then that’s what they should do.

That's tricky, because there actually is a lot of evidence that software
tools really don't support individuals *and their interactions* as well
as more low tech tools do.

Still, if the individuals have tried the low tech way for a reasonable
amount of time, have seriously tried to make them work, and still prefer
software tools, more power to them. Many that prefer software tools
don't seem to do it out of that much experience, but rather out of what
they imagine how low tech tools would work.

Post by Jeff Martin
If the product owner prefers to see
the burndown as an Excel chart that can be printed, copied and pasted
and emailed over a hand drawn chart, then that’s what should happen.

If my product owner would prefer that, I would still do a low tech
version for the team, because that's what the team needs to be
effective. The product owner, of course, would have the option to
request a high fidelity chart - and he would know exactly what that
costs him, so that he can make the decision sensibly.

Post by Jeff Martin
I
don’t understand the aversion to using software in the process. We
spend our entire career telling companies that we can write software to
improve their businesses and processes, but we’re saying we can’t
improve our own? That our process is better with index cards and cork
boards? It’s very true that most of the “agile” tools on the market are
not agile and either have too much or not enough. But that doesn’t mean
that any use of software is A Bad Thing©.

I'm using a lot of software: compiler, IDE, debugger, profiler, version
control, email, wiki, blog, webbrowser etc. pp. Not using those tools
would be unprofessional.

It's important to note, though, that not for every problem the best
solution is a software solution. Insisting on using a software tool in
those cases, would be as unprofessional.

Post by Jeff Martin
Isn’t the entire point of agile development to do what works for your
team?

No, I don't think that's the entire point of Agile.

Post by Jeff Martin
I am a firm believer in the concept of knowing
why you are breaking the rules before you start breaking them.

I'm a firm believer of trying *very* hard to not break the rules, even
if at first sight it seems like I have to. I think that way I learn much
more about what the boundaries really are...

Post by Jeff Martin
Once again, this is not directed at you Ilja. It’s just the result of a
lot of different emails and blog posts.

Understood. Ditto here... ;)


No hard feelings,

Ilja


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

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

<*> Your email settings:
Individual Email | Traditional

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

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

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

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

[Marco Milone]

Until you start having people working from home or dispersed teams.

Regards,

Marco







________________________________

From: ***@yahoogroups.com
[mailto:***@yahoogroups.com] On Behalf Of Ilja Preuss
Sent: 04 August 2007 18:32
To: ***@yahoogroups.com
Subject: Re: [scrumdevelopment] Release Burndown chart in Excel

Post by Jeff Martin
I've written one using a charting component, but I'm trying to keep
things simple and keeping it in Excel is the simplest path.

In my experience, for those kinds of charts, manually drawn diagrams on
flip chart paper, put on a wall for everyone to see, works even better.

Cheers, Ilja




For the most important conference on Software testing and quality visit www.sqs-conferences.com

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

SQS-UK: SQS Group Limited | Incorporated in England and Wales | Registered No. 2857864 | VAT No. 788 1795 61
SQS-Ire: SQS Software Quality Systems (Ireland) Limited | Incorporated in Ireland | Registered No. 307763 | Vat No. IE6327763G
SQS-SA: South African Branch office of SQS Group Limited | Registered in South Africa | Registered No. 2004/010639/10 | Vat No. 40602176781

[Ilja Preuss]

Well, I simply don't have experience with such teams; and it doesn't
seem to fit my "for everyone to see" constraint - unless you are using a
webcam, an electronic whiteboard, or something similar, in which case I
could imagine it to actually work again...

Post by Marco Milone
Until you start having people working from home or dispersed teams.
Regards,
Marco
------------------------------------------------------------------------
*Sent:* 04 August 2007 18:32
*Subject:* Re: [scrumdevelopment] Release Burndown chart in Excel

Post by Jeff Martin
I've written one using a charting component, but I'm trying to keep
things simple and keeping it in Excel is the simplest path.

In my experience, for those kinds of charts, manually drawn diagrams on
flip chart paper, put on a wall for everyone to see, works even better.
Cheers, Ilja
For the most important conference on Software testing and quality visit
www.sqs-conferences.com
This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.
SQS-UK: SQS Group Limited | Incorporated in England and Wales |
Registered No. 2857864 | VAT No. 788 1795 61
SQS-Ire: SQS Software Quality Systems (Ireland) Limited | Incorporated
in Ireland | Registered No. 307763 | Vat No. IE6327763G
SQS-SA: South African Branch office of SQS Group Limited | Registered in
South Africa | Registered No. 2004/010639/10 | Vat No. 40602176781

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

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

<*> Your email settings:
Individual Email | Traditional

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

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

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

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

[Roy Morien]

I am sometimes amazed, and sometimes puzzled, and sometimes amused at the discussions that occur here. However, the participants are clearly 'seekers after knowledge' and that is good.

But there does seem to be a lot of obsessing about things, unnecessarily.

Take this discussion about the use of project management, or project reporting software.

In all my reading about agile development and lean development, I have never seen anything that is essentially anti-automation, or anti-software use. What I have seen is a clear warning against becoming too enmeshed in the use of apparently sophisticated software packages, when a non-technical, or simple solution is useful. One good example of this is the discussion in various places about the use of sophisticated MRP software, versus simple 'flags' or visual signals indicating the need to replenish the component bin at a workstation, or to inform people of some thing or another.

One of the problems of using 'sophisticated' software packages (maybe read 'complex' packages) is that it is the ability to use the package, and the amount of time and effort needed to keep the package information up to date, that becomes the most important issue, or the most time consuming activity. Some people love the package because it provides lots of reports that make them appear important because of the size of the stack of output that they routinely receive. And that can imply an enormous effort to 'feed the beast' with data that is necessary for those reports.

So it really is a matter of "what works, use", for your environment. Answering a viewpoint that paper wall charts are all that is necessary for small teams, by talking about the needs of large teams that are distributed around the globe in different time zones is just not relevant.


To: ***@yahoogroups.comFrom: ***@iljapreuss.deDate: Wed, 8 Aug 2007 21:31:25 +0200Subject: Re: [scrumdevelopment] Release Burndown chart in Excel




matt gelbwaks wrote:> It is funny to hear some of the > rants people have against modifying Scrum or XP or Agile to suit your > enterprise or organization.Part of that is coming from experience with people who modify the approach without understanding how the original works - see http://www.xprogramming.com/xpmag/jatBaseball.htm for a humorous take on it.Of course there are also valid reasons for modifying the game - if you were playing on the moon, for example, you probably had to apply heavy modifications to make it work at all. I wouldn't be surprised if baseball fans would be kind of upset if the resulting game still would be called baseball.> It is also funny to hear people hold the> line on these methodologies being meant for small collocated teams only What's funny about that???> and therefore you can't use software to automate certain aspects of the > approach.I have never seen the reasoning that way.It's certainly true, though, that to the extent that your team being big or distributed forces you to use software tools, you simply can't be as Agile as smaller, colocated teams. Does that thought trouble you?> I get much mirth out of this last one because it so seems> that people forget what we are doing - we are building software to > automate tasks that people can no longer do without automation.I'm not forgetting that at all. Does that mean that we should blindly use software to automate everything, whithout caring about whether it seems to be effective or not? Or what else are you getting at here?> We are> a global community now, IT is, so we need to automate certain aspects of > it.All Agile proponents are saying, as far as I can tell, is that being distributed will invariably make you less effective - partly because you will have to use software tools instead of more direct forms of communication and collaboration.Is that something you disagree with?> Just like you> can have an excel spreadsheet for your burndown chart (with automated > trend lines!!!!).Sure you can. I deem it to be interesting to talk about the pros and cons of doing so, but that might just be me.Cheers, Ilja


_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE

[Ilja Preuss]

Post by Roy Morien
But there does seem to be a lot of obsessing about things, unnecessarily.

"obsession, noun: a persistent disturbing preoccupation with an often
unreasonable idea or feeling"

I'd suggest that, as long as you label an idea that comes up in a
discussion as an obsession, you are unlikely to learn much about the
real motivations of the other side.

Post by Roy Morien
Take this discussion about the use of project management, or project reporting software.
In all my reading about agile development and lean development, I have
never seen anything that is essentially anti-automation, or
anti-software use.

Not anti, certainly not. But there is this "people over tools" thing in
the manifesto...

Post by Roy Morien
What I have seen is a clear warning against becoming
too enmeshed in the use of apparently sophisticated software packages,
when a non-technical, or simple solution is useful.

I don't think that cards are just useful. I think in many cases, they
have significant benefits (besides just being simple).

Post by Roy Morien
One of the problems of using 'sophisticated' software packages (maybe
read 'complex' packages) is that it is the ability to use the package,
and the amount of time and effort needed to keep the package information
up to date, that becomes the most important issue, or the most time
consuming activity.

That is certainly one problem, but actually not the one I'd worry most
about.

Post by Roy Morien
Some people love the package because it provides
lots of reports that make them appear important because of the size of
the stack of output that they routinely receive. And that can imply an
enormous effort to 'feed the beast' with data that is necessary for
those reports.

Let's face it - most of us are geeks - we just love technology. So when
we see some, we want to try it.

A software developers primary job (and probably what he gets his job
satisfaction from) is making a machine do the work. So they naturally
shy away from doing something manually when there is software that is
supposed to do it.

Still, there are problems for which non-software-solutations are best.
In my experience, most software people won't believe that *their*
problem is one of those, until they've tried the non-software solution
for some time.

Post by Roy Morien
So it really is a matter of "what works, use", for your environment.

To me, that doesn't suffice. I want to find out what works *better* than
what we are currently doing. And in my experience, that includes trying
low-tech solutions - even if sometimes it seems counterintuitive at
first sight.

Post by Roy Morien
Answering a viewpoint that paper wall charts are all that is necessary
for small teams, by talking about the needs of large teams that are
distributed around the globe in different time zones is just not relevant.

Most often, the discussion actually seems to work this way:

A: What tools are best for X? (No mention of a distributed team at all.)
B: Software Y is great!
C: In my experience, index cards work best.
D: But you can't use index cards with distributed teams!

That's what's puzzling *me*...

Cheers, Ilja


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

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

<*> Your email settings:
Individual Email | Traditional

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

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

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

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