Re: SIP is not Takt Time
"Rachel Davies" <[email protected]> Mon, 10 Feb 2003 09:22:21 +0000
| Newsgroups | gmane.comp.programming.software-in-process |
|---|---|
| Message-ID | <[email protected]> |
I work in an XP team and SIP it seems to me is a measure of the effectiveness of both the Customer and Development team in XP (rather that by the book XP where the main measure is Velocity). Velocity just measures of how good your Development teams estimates are to give the Customer team an idea of likely delivery dates. SIP appears a more embracing measure because it covers the effectiveness of the whole organisation. For example, I can imagine an XP team that delivers the number of stories it promises every iteration quite accurately but a backlog building up due to lack of resource. Also stories may have long SIP because they are of lower business value that others (so they take a long time to get planned in and even then may get booted out of an iteration), thus they are in the queue/pipeline a longer time, so SIP may be an indication of Customer team spending time on specifying low value stories. Rachel Davies Connextra >>> [email protected] 02/08/03 04:06pm >>> Dossy, I agree, takt time is the goal, not the actual time. Say you want 100 cars to roll off your line in an 10 hour day, that means that they need to roll off at the rate of 10 per hour or one every six minutes. So six minutes is the desired takt time. I reluctantly concede that the actual rate at which cars are rolling off the line (say one every 7 minutes) can be called cycle time. By whatever name, this time is not a duration, it is a rate. What I think about, however, is not how many stories per week (or whatever) a team can complete, I worry about how long it takes a story, once articulated, takes to get finished. This time * whatever we call it * is the important time for SIP. I used to call this cycle time, now I call it service time, some people call it lead time. Basically it is the time from when something goes into a queue until the time it comes out. It is a duration, not a rate. I don't think we have a word for the target of this time * but I surely could be wrong. Mary Poppendieck --- In [email protected], Dossy <dossy@p...> wrote: > On 2003.02.08, Mary Poppendieck <mary@p...> <mary@p...> wrote: > > I have decided to use the term *service time* to refer to the time- > > in-queue definition of cycle time and takt time to refer to the line- > > balancing use of the term cycle time. > > It was pretty clear to me that takt time, being a goal, is what the > cycle time needs to be in order for supply to meet demand. > > I can say, "in order to get to work in the morning, I need to drive 26 > miles." This is takt time -- it's the desired goal. > > Now, suppose in the morning I have to run to the post office and drop > off a letter, and stop at the gas station and get gas. This adds a > whole 2 miles to my commute. For that morning, it took me 28 miles to > get to work. This is the cycle time for that morning's commute. > > Am I all washed up here? > > -- Dossy > > -- > Dossy Shiobara mail: dossy@p... > Panoptic Computer Network web: http://www.panoptic.com/ > "He realized the fastest way to change is to laugh at your own > folly -- then you can let go and quickly move on." (p. 70) To unsubscribe from this group, send an email to: [email protected] Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ ------------------------ Yahoo! Groups Sponsor ---------------------~--> Get 128 Bit SSL Encryption! http://us.click.yahoo.com/LIgTpC/vN2EAA/xGHJAA/NhFolB/TM ---------------------------------------------------------------------~-> To unsubscribe from this group, send an email to: [email protected] Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/