Re: How to measure SIP?

Lowell, I think I understand what you mean. Ideally one should deal with 
this kind of situations thanks to an optional scope contract. In my 
experience it helps a lot to ease the negotiation from a sale point of 
view. Therefore, it should be less probable that there are expected 
features that were negotiated under the hood, generating expectations on 
customer side while not being communicated effectively to the team.

Anyway, even with an optional scope contract the risk is still there.

Thanks.
Ciao, Giuliano


Lowell Lindstrom wrote:

> I like to think about it as the extent to which a story becomes a 
> liability.  The simplest way to think about this is effort expended 
> that is not producing value.  In that context, I agree with Kent that 
> 'B' seems appriate.  For an organization that is using XP Planning, 
> that is certainly what I would do.
>  
> I think a more accurate indication of the liability would need to take 
> into account stakeholder expectations.  A story that an influencial 
> stakeholder expects on a certain date carries huge SIP, even if the 
> whole team has never heard the story, let alone written it on a card.  
> A specific example of this would be a commitment that a sales person 
> or executive made in the heat of a negotiation that did not get 
> communicated effectively to the team.  The reason its SIP is huge is 
> that it can extend the SIP of *everything* if a release is delayed 
> until it can be delivered.
>  
> This extends the definition out to the stakeholder community, which 
> gives a full end to end measure.  The difficulty of course is that 
> this complicates the identification of the starting time stamp. 
>  
> So, there's an accuracy/complexity tradeoff here.  I would start with 
> 'B' since it is easier to measure and then look out for missed 
> expectations and try to measure their impact to see if SIP should 
> really include those situations.
>  
> Lowell
>  
> =============
> Lowell Lindstrom
> Object Mentor, Inc.
> [email protected] <mailto:[email protected]>
>  
>
>     -----Original Message-----
>     From: Kent Beck
>     Sent: 6/19/2003 11:17 AM
>     To: [email protected]
>     Subject: RE: [SIP] How to measure SIP?
>
>
>     I "only" have an aesthetic/intellectual argument for when to start
>     the SIP clock, not any experience. You have some capital to
>     invest. At some point, you start applying it towards a particular
>     feature, so you can't apply towards any other feature (opportunity
>     cost). At some future point, you receive revenue, so you have
>     capital again. Symmetry suggests to me that we should start
>     measuring when the capital becomes unavailable and stop measuring
>     when it becomes available again. This suggests B to me, since
>     writing a story on a card doesn't really prevent me from writing
>     100 other stories on other cards.
>      
>     Does that answer your question?
>      
>     Kent
>
>         -----Original Message-----
>         From:
>         sentto-8007113-449-1056007899-kent=threeriversinstitute.org@returns.groups.yahoo.com
>         [mailto:sentto-8007113-449-1056007899-kent=threeriversinstitute.org@returns.groups.yahoo.com]
>         On Behalf Of pgbossi
>         Sent: Thursday, June 19, 2003 12:32 AM
>         To: [email protected]
>         Subject: Re: [SIP] How to measure SIP?
>
>         Kent, thanks for your answers. I'd like to have a few more
>         clarifications.
>
>         First of all, you don't want to consider release 0.0 because
>         it has
>         never been used by end users, do you? I'd agree with you, but
>         there's
>         another element to consider: release 0.0 goal was more to show
>         results
>         to customer's upper management than to really go in production. In
>         this way, wouldn't be appropriate to measure SIP(0.0) ~ 40 days?
>
>         I like the idea to trace SIP release after release and not
>         necessarily
>         as an overall value, it gives much more a sense of what's
>         happening as
>         time goes by.
>
>         Which is the most appropriate way to consider the starting
>         date of a
>         user story?
>         A) when the story is written down on a card
>         B) when the story is planned
>         C) when the developers start working on the story
>
>         I'd vote for B, because we are trying to ask the customer to write
>         acceptance tests right after the planning game: by specifying the
>         acceptance tests a lot of details behind the user story are
>         written at
>         least narratively (we are shifting the customer towards FIT,
>         but this
>         is an entirely different story).
>
>         Ciao, Giuliano
>
>
>
>     To unsubscribe from this group, send an email to:
>     [email protected]
>
>
>
>     Your use of Yahoo! Groups is subject to the Yahoo! Terms of
>     Service <http://docs.yahoo.com/info/terms/>.
>
>
> Yahoo! Groups Sponsor
>
> <http://rd.yahoo.com/M=247865.3456232.4744922.1261774/D=egroupweb/S=1705007181:HM/A=1482387/R=0/SIG=16nu4j53g/*http://ads.x10.com/?bHlhaG9vaG0xLmRhd=1056042717%3eM=247865.3456232.4744922.1261774/D=egroupweb/S=1705007181:HM/A=1482387/R=1=1056042717%3eM=247865.3456232.4744922.1261774/D=egroupweb/S=1705007181:HM/A=1482387/R=2> 
>
>
>
> To unsubscribe from this group, send an email to:
> [email protected]
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service 
> <http://docs.yahoo.com/info/terms/>.