Scot Mcphee | 1 Mar 2009 02:36
Picon
Gravatar

Re: Re: Tracking number of passed story acceptance criteria during the sprint


On 01/03/2009, at 9:12 AM, Robert Biddle wrote:
>
> I have seen this happen with developers as well, where they are
> reluctant to do
> "the same" stories again, even when the PO has used the software to  
> find
> it should be better.

Isn't embracing this sort of iterative change the whole *point* of  
agile development? That up-front specification is bad because it  
precludes discovery and learning about the process? Shouldn't then the  
team be taken back to first principles - or see if they can learn them  
themselves - if things get that bad?

It's not succeed or fail. Failure is OK. It's succeed or learn to  
succeed.

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

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! 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:
(Continue reading)

Malapine | 1 Mar 2009 03:22
Picon
Favicon

Re: Tracking number of passed story acceptance criteria during the sprint

davenicolette <dnicolet <at> ...> wrote:

> > Suppose the PO, rather than whining, says that its the team's
> > responsibility to devise acceptance criteria, because they
> > have domain expertise that the PO and the executive sponsors
> > don't. 

> [...] I think you just contradicted yourself in your
> description of the hypothetical situation. Previously you
> explained that the company's management doesn't know anything
> about their own business domain.

They know the existing domain, but we can't just keep on
re-packaging and re-selling the existing product forever.
And they don't know the proposed new domains at a detailed
technical level, they're delegating that to us.

> Now you're saying they have prioritized the stories.
> Based on what?

Sales teams suggest new stories and priorities, based on
$$$ worth of future deals they could close if we add some
new feature X suggested by a customer. Customers typically
don't tell them what business problem X will solve or what
acceptance criteria they would use to detect whether we
actually implemented X.

Maintenance teams also suggest stories and priorities,
based on $$$ worth of existing deals we may lose if we
don't fix customer issue Y. They can give us basic
(Continue reading)

Ron Jeffries | 1 Mar 2009 03:48
Picon
Favicon
Gravatar

Re: Re: Tracking number of passed story acceptance criteria during the sprint

Hello, Robert.  On Saturday, February 28, 2009, at 6:26:08 PM, you
wrote:

> It's a wording issue: I find some people who think that
> "acceptance" means "now and forever". This all also concerns
> tracking, because some people think that changing accepted stories
> indicates a bad problem, and so on and so on...

Yes ... though I think one has to consider that changing stories
does constitute a kind of waste. It'd be better, obviously, to get
everything right the first time. Just not possible.

I like to use concrete acceptance tests because it clarifies the
meaning of Done (for now), and helps the customer recognize that the
has spent extra through changing her mind. Presumably the awareness
will help her decide how much to invest in being right, and how to
find out more cheaply when she just doesn't know.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Attend our CSM Plus Course!
http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
The opinions expressed here /are/ necessarily those of XProgramming.com.
But I might change my mind.

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

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links
(Continue reading)

Robert Biddle | 1 Mar 2009 04:03
Picon
Picon

Re: Re: Tracking number of passed story acceptance criteria during the sprint

Ron Jeffries wrote:
>
> Hello, Robert. On Saturday, February 28, 2009, at 6:26:08 PM, you
> wrote:
>
> > It's a wording issue: I find some people who think that
> > "acceptance" means "now and forever". This all also concerns
> > tracking, because some people think that changing accepted stories
> > indicates a bad problem, and so on and so on...
>
> Yes ... though I think one has to consider that changing stories
> does constitute a kind of waste. It'd be better, obviously, to get
> everything right the first time. Just not possible.
>

I think you and agree on the result here, but maybe not on the reasoning.
In my view, it's not just that it is not possible to get it right:
it's that there is no such thing as right.
The truth is like puppies, a bunch of 'em runnin' around and you pick 
your favorite.
But I suspect we disagree on that.
:-)

Robt

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

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

(Continue reading)

George Dinwiddie | 1 Mar 2009 04:02
Favicon

Re: Re: Tracking number of passed story acceptance criteria during the sprint

lindgrenf wrote:
> My experience is that it's quite straight forward to split stories 
> vertically to a certain point, but then the tendency is that the team 
> suggest horizontal splitting if further break down is needed. At that 
> point I prefer a slightly bigger story than a bunch of horizontal 
> slices. 

Why does the team jump to horizontal splitting?

> In practice we have never accepted a single story that is bigger than 
> half of the average team velocity, and when taking on one of these 
> larger stories we always try to swarm around the big story in the 
> beginning of the sprint to reduce the risk of having a failed sprint 
> with a partially done story. In such a case, I think that showing the 
> partial, but real, progress could help us to discover problems 
> earlier.

Oof!  That's a huge story, to me.

> When it comes to improving the acceptance criteria for stories 
> accepted by the team I prefer a more pragmatic approach aproach than 
> just refusing the story. The truth is that our current stories are 
> not all that bad, but every once in a while there's a high priority 
> story with fluffy or incomplete acceptance criteria coming up in 
> sprint planning. We typically discuss it on the spot with the PO, we 
> get a fairly good understanding, and someone is appointed as 
> responsible to work out the details with the PO in the beginning of 
> the sprint. An acceptance criteria burndown graph would show this 
> situation and could be a remonder to bring up the issue in the 
> retrospective.
(Continue reading)

Ron Jeffries | 1 Mar 2009 04:13
Picon
Favicon
Gravatar

Re: Re: Tracking number of passed story acceptance criteria during the sprint

Hello, Robert.  On Saturday, February 28, 2009, at 10:03:11 PM, you
wrote:

> I think you and agree on the result here, but maybe not on the reasoning.
> In my view, it's not just that it is not possible to get it right:
> it's that there is no such thing as right.
> The truth is like puppies, a bunch of 'em runnin' around and you pick
> your favorite.
> But I suspect we disagree on that.
> :-)

Do you think it is possible to order dinner and not send it back?

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
Attend our CSM Plus Course!
http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back
of his head. It is, as far as he knows, the only way of coming downstairs,
but sometimes he feels that there really is another way, if only he could
stop bumping for a moment and think of it. And then he feels that perhaps
there isn't. -- A. A. Milne

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

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! Groups Links

<*> To visit your group on the web, go to:
(Continue reading)

Roy Morien | 1 Mar 2009 05:03
Picon
Favicon

RE: Re: Tracking number of passed story acceptance criteria during the sprint

As said elsewhere, one major point about iterative development is to have frequent opportunities to learn, and if the user learns something and that triggers a request for change, then that just means the iterative approach is successful. The reason for the change can, of course, be investigated to see if there are any lessons to be learned, but the very act of asking for changes is an indicator of success.
 
Why are developers and PO's reluctant to want change? Perhaps this is seen as indicating a failure on their part, which they do not wish to acknowledge. Maybe they just don't want to re-do something. Maybe they feel that it will disrupt their well detailed and Gantt Charted Project Plan. But the better and I suggest correct response is to see the change purely in terms of new knowledge acquired and acted upon. The change would be stated as a User Story (or whatever) and put on the Product Backlog and prioritized and estimated in exactly the same way as any other newly discovered requirement. It is actually not correct ot see it in terms of 'the same user story'. It is not! It cannot be, because presumably new knowledge is now available and being applied to the situation.
 
I would even go so far as to say What right do they have to be reluctant to accept change?
 
Every change requested and incorporated into the system is one step closer to a useful and useable system. Every change requested and rejected is one step further away from having a system that is acceptable to the user. 
 
Of course, there is always a danger of design thrashing, which is a wasteful activity. But that is actually quite easy to control, I think.
 
Regards,
Roy Morien
To: scrumdevelopment <at> yahoogroups.com
From: Robert_Biddle <at> Carleton.Ca
Date: Sat, 28 Feb 2009 18:12:58 -0500
Subject: Re: [scrumdevelopment] Re: Tracking number of passed story acceptance criteria during the sprint

Hi Dave:

Yep, that was exactly my thinking: this is the way it is supposed to work.

It troubles me a bit that sometimes "acceptance" seems to be interpreted as
"final acceptance", which means that at the early points the PO is
reluctant to specify and anxious
about the result, and at the later points they are reluctant to want
change.
I have seen this happen with developers as well, where they are
reluctant to do
"the same" stories again, even when the PO has used the software to find
it should be better.

The idea of "tracking" and the word "acceptance" might be involved in
all this.
We have to be careful with this all, lest we end up with lots of little
waterfalls,
rather than one big one.

Robt

davenicolette wrot e:
>
> Hi Robert,
>
> Sounds like two stories to me. Also sounds very positive. Customers
> get a solution increment in hand and work with it, and based on that
> they gain a better understanding of the problem. Now they can ask for
> different functionality that meets their needs better. The revised
> functionality is a new story and it has acceptance tests. That's good
> news! It means they're paying attention to the incremental results and
> learning as they go. I don't see a problem. If anything, it's an
> example of the sort of value agile methods can deliver that are not
> possible with traditional methods.
>
> Cheers,
> Dave
>
> --- In scrumdevelopment <at> yahoogroups. com
> & lt;mailto:scrumdevelopment%40yahoogroups.com>, Robert Biddle
> <Robert_Biddle <at> ...> wrote:
> >
> > So, just to check different understandings of this,
> > does it still count as an "acceptance test" if the PO
> > specifies it, the code is developed and passes the test,
> > and then the PO decides to change their mind?
> >
> > For example, say they have story, they specify the test, the code
> > is developed and passed. Then the software goes out
> > to some users and the PO decides they want it to work differently.
> > So they come back and tell a different story, and give a different test.
> >
> > Are these both acceptance tests?
> >
> > Robt
> >
> > Ron Jeffries wrote:
> > >
> > > Hello, Malapine. On Saturday, February 28, 2009, at 5:19:57 PM,
> > > you wrote:
> > >
> > > > Suppose the PO, rather than whining, says that its the team's
> > > > responsibility to devise acceptance criteria, because they
> > > > have domain expertise that the PO and the executive sponsors
> > > > don't. They also point out that management won't tolerate the
> > > > team's refusal to work on the highest priority stories...
> > >
> > > Well, then the PO isn't serving as the responsible person she's
> > > supposed to be serving as. What should we do about that?
> > >
> > > Ron Jeffries
> > > www.XProgramming. com
> > > www.xprogramming. com/blog
> > > Attend our CSM Plus Course!
> > > http://hendricksonx p.com/index. php?option= com_eventlist& Itemid=28
> > > <http://hendricksonx p.com/index. php?option= com_eventlist&
> Itemid=28
> <http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28>>
> > > To tolerate a problem is to insist on it. -- Software for Your Head
> > >
> > >
> >
>
>


.ExternalClass #EC_ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;padding:0px 14px;} .ExternalClass #EC_ygrp-mkp hr {border:1px solid #d8d8d8;} .ExternalClass #EC_ygrp-mkp #EC_hd {color:#628c2a;font-size:85%;font-weight:bold;line-height:122%;} .ExternalClass #EC_ygrp-mkp #EC_ads {margin-bottom:10px;} .ExternalClass #EC_ygrp-mkp .EC_ad {padding:0 0;} .ExternalClass #EC_ygrp-mkp .EC_ad a {color:#0000ff;text-decoration:none;} .ExternalClass #EC_ygrp-sponsor #EC_ygrp-lc {font-family:Arial;} .ExternalClass #EC_ygrp-sponsor #EC_ygrp-lc #EC_hd {font-weight:bold;font-size:78%;line-height:122%;} .ExternalClass #EC_ygrp-sponsor #EC_ygrp-lc .EC_ad {margin-bottom:10px;padding:0 0;} .ExternalClass #EC_ygrp-mlmsg {font-size:13px;font-family:arial,helvetica,clean,sans-serif;} .ExternalClass #EC_ygrp-mlmsg table {font-size:inherit;font:100%;} .ExternalClass #EC_ygrp-mlmsg select, .ExternalClass input, .ExternalClass textarea {font:99% arial,helvetica,clean,sans-serif;} .ExternalClass #EC_ygrp-mlmsg pre, .ExternalClass code {font:115% monospace;} .ExternalClass #EC_ygrp-mlmsg EC_* {line-height:1.22em;} .ExternalClass #EC_ygrp-text {font-family:Georgia;} .ExternalClass #EC_ygrp-text p {;} .ExternalClass dd.EC_last p a {font-family:Verdana;font-weight:bold;} .ExternalClass #EC_ygrp-vitnav {padding-top:10px;font-family:Verdana;font-size:77%;} .ExternalClass #EC_ygrp-vitnav a {padding:0 1px;} .ExternalClass #EC_ygrp-mlmsg #EC_logo {padding-bottom:10px;} .ExternalClass #EC_ygrp-reco {margin-bottom:20px;padding:0px;} .ExternalClass #EC_ygrp-reco #EC_reco-head {font-weight:bold;color:#ff7900;} .ExternalClass #EC_reco-category {font-size:77%;} .ExternalClass #EC_reco-desc {font-size:77%;} .ExternalClass #EC_ygrp-vital a {text-decoration:none;} .ExternalClass #EC_ygrp-vital a:hover {text-decoration:underline;} .ExternalClass #EC_ygrp-sponsor #EC_ov ul {padding:0 0 0 8px;} .ExternalClass #EC_ygrp-sponsor #EC_ov li {list-style-type:square;padding:6px 0;font-size:77%;} .ExternalClass #EC_ygrp-sponsor #EC_ov li a {text-decoration:none;font-size:130%;} .ExternalClass #EC_ygrp-sponsor #EC_nc {background-color:#eee;margin-bottom:20px;padding:0 8px;} .ExternalClass #EC_ygrp-sponsor .EC_ad {padding:8px 0;} .ExternalClass #EC_ygrp-sponsor .EC_ad #EC_hd1 {font-family:Arial;font-weight:bold;color:#628c2a;font-size:100%;line-height:122%;} .ExternalClass #EC_ygrp-sponsor .EC_ad a {text-decoration:none;} .ExternalClass #EC_ygrp-sponsor .EC_ad a:hover {text-decoration:underline;} .ExternalClass #EC_ygrp-sponsor .EC_ad p {;} .ExternalClass EC_o {font-size:0;} .ExternalClass .EC_MsoNormal {;} .ExternalClass #EC_ygrp-text tt {font-size:120%;} .ExternalClass blockquote {;} .ExternalClass .EC_replbq {;} .ExternalClass dd.EC_last p span {margin-right:10px;font-family:Verdana;font-weight:bold;} .ExternalClass dd.EC_last p span.EC_yshortcuts {margin-right:0;} .ExternalClass div.EC_photo-title a, .ExternalClass div.EC_photo-title a:active, .ExternalClass div.EC_photo-title a:hover, .ExternalClass div.EC_photo-title a:visited {text-decoration:none;} .ExternalClass div.EC_file-title a, .ExternalClass div.EC_file-title a:active, .ExternalClass div.EC_file-title a:hover, .ExternalClass div.EC_file-title a:visited {text-decoration:none;} .ExternalClass #EC_ygrp-msg p {clear:both;padding:15px 0 3px 0;overflow:hidden;} .ExternalClass #EC_ygrp-msg p span {color:#1E66AE;font-weight:bold;} .ExternalClass EC_div#ygrp-mlmsg #EC_ygrp-msg p a span.EC_yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;} .ExternalClass #EC_ygrp-msg p a {font-family:Verdana;font-size:10px;} .ExternalClass #EC_ygrp-mlmsg a {color:#1E66AE;} .ExternalClass div.EC_attach-table div div a {text-decoration:none;} .ExternalClass div.EC_attach-table {width:400px;}
Combine your email accounts here! Want to marry your mail?
__._,_.___


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



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Roy Morien | 1 Mar 2009 05:13
Picon
Favicon

RE: Re: ScrumMaster as facilitator vs. ScrumMaster as coach

'little cartooney icons' ... great idea and very successful often. One of the best (as in well received) presentations I ever made, to a group of user area people, including high level managers, was made by using a white board, some coloured markers, and free hand drawn images of telephone lines across the country, factories, stick figures in various colours for different users, badly drawn little cars and trucks and stuff like that. In the eyes of the 'Powerpoint Brigade' it may have been considered highly unprofessional and untidy, but the audience loved it. The comment was 'This is the first time I've ever really understaood a presentation about our systems. Usually we get snowed with a lot of technical jargon and beautiful diagrams that we don't understand'.
 
This is somewhat reminiscent of the 'Rich Picture' that is part of the Soft Systems methodology, and could even be seen almost as a mind mapping diagram. 
 
As someone once said, it doesn't have to have sharp corners to be useful. The 'cloud' or 'potato' is ok too.
 
Regards,
Roy Morien
 
To: scrumdevelopment <at> yahoogroups.com
From: dnicolet <at> hotmail.com
Date: Sat, 28 Feb 2009 13:07:06 +0000
Subject: [scrumdevelopment] Re: ScrumMaster as facilitator vs. ScrumMaster as coach

I like the IRiC idea. Sometimes I use little cartooney icons to
represent various stakeholders when explaining these concepts to
people unfamiliar with them. The one I like to use to represent the
ScrumMaster role is Ganesha, the god of removing obstacles.

I don't think everyone has the same notions of what the plain English
words "coach" and "mentor" mean, and that further complicates
discussions of the difference between SM and "coach."

Words get in the way, eh?

Cheers,
Dave

--- In scrumdevelopment <at> yahoogroups.com, "Joseph Little"
<jhlittle <at> ...> wrote:
>
> To the subject line and one comment below...
>
> My experience is that the most import ant thing an SM does is remove
> impediments (get impediments removed). He is the "Impediment Remover
> In Chief". All the other things fall under this. ("All" is perhaps too
> simplistic.)
>
> My experience is that "facilitator" (as I use that term) is a minor
> role in Scrum. (Others might define it more broadly than I do.)
>
> "Coach" again has different meanings to different people. If one means
> "coaching the team and those around the team to help remove
> impediments so that the team becomes more effective" then, it means
> about what I mean by Impediment-Remover-In-Chief.
>
> The IRiC phrase wants to emphasize an aspect parallel to the PO. It is
> key that the SM prioritize (do final prio ritization) and own the
> Impediment List. And drive them, one-by-one to completion. (Drive's
> connotation of being Command & Control not intended.)
>
> My 2 cents.
>
> Thanks, Joe
>
>
>
> --- In scrumdevelopment <at> yahoogroups.com, "jens.meydam"
> <jens.meydam <at> > wrote:
> >
> > Hi Jaideep
> >
> > > Sustainable success can never be forced or imposed, it has to be
> > inculcated
> > > and groomed. If as soon as the ScrumMaster is gone, the impact is
> > also gone
> > > then it is the failure of SM. SM as facilitator or Coach, whatever
> > role he
> > > adopts, its sole purpose is to mature the team in such a manner to
> > be able
> > > to achieve success at the same pace, even if SM is gone.
> >
> > I don't really disagree with this. However, I think that often -
> > perhaps paradoxically - the best way to achieve this maturity quickly
> > is to do what Jeff Sutherland describes.
> >
> > "Forceful and mandatory" may sound politically incorrect to some
> > people here, but a "total [...] immersion experience" is exactly what
> > I want if I want to learn fast. This also applies to things like
> > learning a foreign language.
> >
> > Regards
> >
> > Jens
> >
> > _____
> > >
> > > From: scrumdevelopment <at> yahoogroups.com
> > > [mailto:scrumdevelopment <at> yahoogroups.com] On Behalf Of jens.meydam
> > > Sent: 27 February, 2009 11:49
> > > To: scrumdevelopment <at> yahoogroups.com
> > > Subject: [scrumdevelopment] Re: ScrumMaster as facilitator vs.
> > ScrumMaster
> > > as coach
> > >
> > >
> > >
> > > Hi Dave
> > >
> > > > I definitely agree the role of coach is responsible for making the
> > &gt ; > team successful. To me, that doesn't mean successful in meeting
> their
> > > > immediate commitments. It means helping them develop into the best
> > > > team they can be, over the long haul.
> > >
> > > I agree that ultimately, sustainable success cannot be forced.
If the
> > > team - even after a couple of months of success - is still likely to
> > > abandon everything the ScrumMaster introduced as soon as the
> > > ScrumMaster is gone, the success that might have been achieved
is not
> > > sustainable.
> > >
> > > On the other hand, I really like what Jeff Sutherland describes
in the
> > > blog post I referred to earlier> > > (http://jeffsutherla
> > >
> >
>
<http://jeffsutherland.com/scrum/2008/09/shock-therapy-bootstrapping.html>
> > > nd.com/scrum/2008/09/shock-therapy-bootstrapping.html).
> > >
> > > Let me quote two paragraphs:
> > >
> > > "I heard similar stories from an Agile leader at JayWay in Sweden.
> > > Using a forceful and mandatory way of implementing Scrum and good
> > > engineering practices, that Agile leader got similar results to
> MySpace.
> > >
> > > Rob Mee at Pivotal Labs in San Francisco uses a forceful total XP
> > > immersion experience to bootstrap teams. They do everything exactly
> > > his way for three months. After that they have full body
understanding
> > > of the Agile motion and he can send them on their way. It has worked
> > > well on 40 startups so far."
> > >
> > > Regards
> > >
> > > Jens
> >
>


.ExternalClass #EC_ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;padding:0px 14px;} .ExternalClass #EC_ygrp-mkp hr {border:1px solid #d8d8d8;} .ExternalClass #EC_ygrp-mkp #EC_hd {color:#628c2a;font-size:85%;font-weight:bold;line-height:122%;} .ExternalClass #EC_ygrp-mkp #EC_ads {margin-bottom:10px;} .ExternalClass #EC_ygrp-mkp .EC_ad {padding:0 0;} .ExternalClass #EC_ygrp-mkp .EC_ad a {color:#0000ff;text-decoration:none;} .ExternalClass #EC_ygrp-sponsor #EC_ygrp-lc {font-family:Arial;} .ExternalClass #EC_ygrp-sponsor #EC_ygrp-lc #EC_hd {font-weight:bold;font-size:78%;line-height:122%;} .ExternalClass #EC_ygrp-sponsor #EC_ygrp-lc .EC_ad {margin-bottom:10px;padding:0 0;} .ExternalClass #EC_ygrp-mlmsg {font-size:13px;font-family:arial,helvetica,clean,sans-serif;} .ExternalClass #EC_ygrp-mlmsg table {font-size:inherit;font:100%;} .ExternalClass #EC_ygrp-mlmsg select, .ExternalClass input, .ExternalClass textarea {font:99% arial,helvetica,clean,sans-serif;} .ExternalClass #EC_ygrp-mlmsg pre, .ExternalClass code {font:115% monospace;} .ExternalClass #EC_ygrp-mlmsg EC_* {line-height:1.22em;} .ExternalClass #EC_ygrp-text {font-family:Georgia;} .ExternalClass #EC_ygrp-text p {;} .ExternalClass dd.EC_last p a {font-family:Verdana;font-weight:bold;} .ExternalClass #EC_ygrp-vitnav {padding-top:10px;font-family:Verdana;font-size:77%;} .ExternalClass #EC_ygrp-vitnav a {padding:0 1px;} .ExternalClass #EC_ygrp-mlmsg #EC_logo {padding-bottom:10px;} .ExternalClass #EC_ygrp-reco {margin-bottom:20px;padding:0px;} .ExternalClass #EC_ygrp-reco #EC_reco-head {font-weight:bold;color:#ff7900;} .ExternalClass #EC_reco-category {font-size:77%;} .ExternalClass #EC_reco-desc {font-size:77%;} .ExternalClass #EC_ygrp-vital a {text-decoration:none;} .ExternalClass #EC_ygrp-vital a:hover {text-decoration:underline;} .ExternalClass #EC_ygrp-sponsor #EC_ov ul {padding:0 0 0 8px;} .ExternalClass #EC_ygrp-sponsor #EC_ov li {list-style-type:square;padding:6px 0;font-size:77%;} .ExternalClass #EC_ygrp-sponsor #EC_ov li a {text-decoration:none;font-size:130%;} .ExternalClass #EC_ygrp-sponsor #EC_nc {background-color:#eee;margin-bottom:20px;padding:0 8px;} .ExternalClass #EC_ygrp-sponsor .EC_ad {padding:8px 0;} .ExternalClass #EC_ygrp-sponsor .EC_ad #EC_hd1 {font-family:Arial;font-weight:bold;color:#628c2a;font-size:100%;line-height:122%;} .ExternalClass #EC_ygrp-sponsor .EC_ad a {text-decoration:none;} .ExternalClass #EC_ygrp-sponsor .EC_ad a:hover {text-decoration:underline;} .ExternalClass #EC_ygrp-sponsor .EC_ad p {;} .ExternalClass EC_o {font-size:0;} .ExternalClass .EC_MsoNormal {;} .ExternalClass #EC_ygrp-text tt {font-size:120%;} .ExternalClass blockquote {;} .ExternalClass .EC_replbq {;} .ExternalClass dd.EC_last p span {margin-right:10px;font-family:Verdana;font-weight:bold;} .ExternalClass dd.EC_last p span.EC_yshortcuts {margin-right:0;} .ExternalClass div.EC_photo-title a, .ExternalClass div.EC_photo-title a:active, .ExternalClass div.EC_photo-title a:hover, .ExternalClass div.EC_photo-title a:visited {text-decoration:none;} .ExternalClass div.EC_file-title a, .ExternalClass div.EC_file-title a:active, .ExternalClass div.EC_file-title a:hover, .ExternalClass div.EC_file-title a:visited {text-decoration:none;} .ExternalClass #EC_ygrp-msg p {clear:both;padding:15px 0 3px 0;overflow:hidden;} .ExternalClass #EC_ygrp-msg p span {color:#1E66AE;font-weight:bold;} .ExternalClass EC_div#ygrp-mlmsg #EC_ygrp-msg p a span.EC_yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;} .ExternalClass #EC_ygrp-msg p a {font-family:Verdana;font-size:10px;} .ExternalClass #EC_ygrp-mlmsg a {color:#1E66AE;} .ExternalClass div.EC_attach-table div div a {text-decoration:none;} .ExternalClass div.EC_attach-table {width:400px;}
Let ninemsn property help! Need a new place to rent, share or buy?
__._,_.___


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



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Roy Morien | 1 Mar 2009 05:22
Picon
Favicon

RE: Doubt in scrum and xp from the trenches, daily scrum

Isn't 'remaining time' a given? If you are considering remaining time in a sprint, then the calculation of remaining time is simple arithmetic: number of developers X number of days left in the sprint X number of development hours per day.
 
And how is 'effort' measured? That is the purpose of User Stories and calculations of Velocity and stuff.
 
But Story Points completed is only measured on completed User Stories ... 'Done!'. So therefore we can assume that remaining effort can be measured by the number of user stories not done, and tallying their story points. It is extemely difficult to estimate the proportion of any user story completed so far. Remember the old saying 'The first 90% takes half the time, and the other 10% takes the other half' (or something, but the point is made about measuring partially done work and partially remaining work).
 
Regards,
Roy Morien 
 
To: scrumdevelopment <at> yahoogroups.com
From: joakim.h.karlsson <at> gmail.com
Date: Fri, 27 Feb 2009 16:57:25 +0100
Subject: Re: [scrumdevelopment] Doubt in scrum and xp from the trenches, daily scrum


On Feb 27, 2009, at 13:24, Amanda Varella wrote:
>
> My question is: what we should track? Remaining effort or remaining
> time?
>

I guess Henrik's book mentions a few alternatives for tracking.

There's no prescribed way I'm afraid.

You need your team to be able to get a sense of whether they're on the
way to meet their commitment for the sprint or not. They might do that
by estimating time for tasks, estimating size of stories, or just
count what's left.

In your current situation - what do you think you need to track, if
anything?

Regards,
Joakim Karlsson
http://www.jkarlsson.com/blog


.ExternalClass #EC_ygrp-mkp {border:1px solid #d8d8d8;font-family:Arial;padding:0px 14px;} .ExternalClass #EC_ygrp-mkp hr {border:1px solid #d8d8d8;} .ExternalClass #EC_ygrp-mkp #EC_hd {color:#628c2a;font-size:85%;font-weight:bold;line-height:122%;} .ExternalClass #EC_ygrp-mkp #EC_ads {margin-bottom:10px;} .ExternalClass #EC_ygrp-mkp .EC_ad {padding:0 0;} .ExternalClass #EC_ygrp-mkp .EC_ad a {color:#0000ff;text-decoration:none;} .ExternalClass #EC_ygrp-sponsor #EC_ygrp-lc {font-family:Arial;} .ExternalClass #EC_ygrp-sponsor #EC_ygrp-lc #EC_hd {font-weight:bold;font-size:78%;line-height:122%;} .ExternalClass #EC_ygrp-sponsor #EC_ygrp-lc .EC_ad {margin-bottom:10px;padding:0 0;} .ExternalClass #EC_ygrp-mlmsg {font-size:13px;font-family:arial,helvetica,clean,sans-serif;} .ExternalClass #EC_ygrp-mlmsg table {font-size:inherit;font:100%;} .ExternalClass #EC_ygrp-mlmsg select, .ExternalClass input, .ExternalClass textarea {font:99% arial,helvetica,clean,sans-serif;} .ExternalClass #EC_ygrp-mlmsg pre, .ExternalClass code {font:115% monospace;} .ExternalClass #EC_ygrp-mlmsg EC_* {line-height:1.22em;} .ExternalClass #EC_ygrp-text {font-family:Georgia;} .ExternalClass #EC_ygrp-text p {;} .ExternalClass dd.EC_last p a {font-family:Verdana;font-weight:bold;} .ExternalClass #EC_ygrp-vitnav {padding-top:10px;font-family:Verdana;font-size:77%;} .ExternalClass #EC_ygrp-vitnav a {padding:0 1px;} .ExternalClass #EC_ygrp-mlmsg #EC_logo {padding-bottom:10px;} .ExternalClass #EC_ygrp-reco {margin-bottom:20px;padding:0px;} .ExternalClass #EC_ygrp-reco #EC_reco-head {font-weight:bold;color:#ff7900;} .ExternalClass #EC_reco-category {font-size:77%;} .ExternalClass #EC_reco-desc {font-size:77%;} .ExternalClass #EC_ygrp-vital a {text-decoration:none;} .ExternalClass #EC_ygrp-vital a:hover {text-decoration:underline;} .ExternalClass #EC_ygrp-sponsor #EC_ov ul {padding:0 0 0 8px;} .ExternalClass #EC_ygrp-sponsor #EC_ov li {list-style-type:square;padding:6px 0;font-size:77%;} .ExternalClass #EC_ygrp-sponsor #EC_ov li a {text-decoration:none;font-size:130%;} .ExternalClass #EC_ygrp-sponsor #EC_nc {background-color:#eee;margin-bottom:20px;padding:0 8px;} .ExternalClass #EC_ygrp-sponsor .EC_ad {padding:8px 0;} .ExternalClass #EC_ygrp-sponsor .EC_ad #EC_hd1 {font-family:Arial;font-weight:bold;color:#628c2a;font-size:100%;line-height:122%;} .ExternalClass #EC_ygrp-sponsor .EC_ad a {text-decoration:none;} .ExternalClass #EC_ygrp-sponsor .EC_ad a:hover {text-decoration:underline;} .ExternalClass #EC_ygrp-sponsor .EC_ad p {;} .ExternalClass EC_o {font-size:0;} .ExternalClass .EC_MsoNormal {;} .ExternalClass #EC_ygrp-text tt {font-size:120%;} .ExternalClass blockquote {;} .ExternalClass .EC_replbq {;} .ExternalClass dd.EC_last p span {margin-right:10px;font-family:Verdana;font-weight:bold;} .ExternalClass dd.EC_last p span.EC_yshortcuts {margin-right:0;} .ExternalClass div.EC_photo-title a, .ExternalClass div.EC_photo-title a:active, .ExternalClass div.EC_photo-title a:hover, .ExternalClass div.EC_photo-title a:visited {text-decoration:none;} .ExternalClass div.EC_file-title a, .ExternalClass div.EC_file-title a:active, .ExternalClass div.EC_file-title a:hover, .ExternalClass div.EC_file-title a:visited {text-decoration:none;} .ExternalClass #EC_ygrp-msg p {clear:both;padding:15px 0 3px 0;overflow:hidden;} .ExternalClass #EC_ygrp-msg p span {color:#1E66AE;font-weight:bold;} .ExternalClass EC_div#ygrp-mlmsg #EC_ygrp-msg p a span.EC_yshortcuts {font-family:Verdana;font-size:10px;font-weight:normal;} .ExternalClass #EC_ygrp-msg p a {font-family:Verdana;font-size:10px;} .ExternalClass #EC_ygrp-mlmsg a {color:#1E66AE;} .ExternalClass div.EC_attach-table div div a {text-decoration:none;} .ExternalClass div.EC_attach-table {width:400px;}
Let ninemsn property help! Need a new place to rent, share or buy?
__._,_.___


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



Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe

__,_._,___
Joakim Karlsson | 1 Mar 2009 09:14
Picon

Re: Doubt in scrum and xp from the trenches, daily scrum


On Mar 1, 2009, at 05:22, Roy Morien wrote:
> Isn't 'remaining time' a given? If you are considering remaining  
> time in a sprint, then the calculation of remaining time is simple  
> arithmetic: number of developers X number of days left in the sprint  
> X number of development hours per day.
>
> And how is 'effort' measured? That is the purpose of User Stories  
> and calculations of Velocity and stuff.
>
I was interpreting the terms used by the OP as:

Remaining time: the sum of the time estimates for all non-completed  
tasks.

Effort: the sum of the point estimates for all non-completed stories.

I might have been too hasty in doing that interpretation, though.

Regards,
Joakim Karlsson
http://www.jkarlsson.com/blog

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

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.comYahoo! 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-digest <at> yahoogroups.com 
    mailto:scrumdevelopment-fullfeatured <at> yahoogroups.com

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

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


Gmane