Re: [OT] Estimating a Struts-based project
for my project I've done from 29 february till now : - 35 view in swing - 12 struts view ~ 100 class -11 500 lines of code -done a complete db schema 28 tables -8 free days -all the stuff as been tested must be finish on 5 may : + 10 views in swing + 6 view with struts + finish all the architecture doc But 5 month of analysis before. I'm not sure if I'm slow for a student ? -- Alexandre Jaquet - Original Message - From: "Chappell, Simon P" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Tuesday, March 25, 2003 5:59 PM Subject: RE: [OT] Estimating a Struts-based project Hmmm. I'll see what I can scrounge up from the QA reject bin. >-Original Message- >From: Nelson, Laird [mailto:[EMAIL PROTECTED] >Sent: Tuesday, March 25, 2003 10:57 AM >To: 'Struts Users Mailing List' >Subject: RE: [OT] Estimating a Struts-based project > > >> -Original Message- >> From: Chappell, Simon P [mailto:[EMAIL PROTECTED] >> Different section of IS. The area that I'm in is responsible >> for distribution operations, so we'll schedule, pick, pack >> and ship your customised LE suit to you, but the Internet >> group will actually take your order. :-) > >So the trick is to talk directly to you guys, and then my suit is free, >right? BTW, I take a 39R. > >Cheers, >Laird > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
> -Original Message- > From: Chappell, Simon P [mailto:[EMAIL PROTECTED] > Hmmm. I'll see what I can scrounge up from the QA reject bin. As long as it can be customized. Extensively. Cheers, Laird - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
Hmmm. I'll see what I can scrounge up from the QA reject bin. >-Original Message- >From: Nelson, Laird [mailto:[EMAIL PROTECTED] >Sent: Tuesday, March 25, 2003 10:57 AM >To: 'Struts Users Mailing List' >Subject: RE: [OT] Estimating a Struts-based project > > >> -Original Message- >> From: Chappell, Simon P [mailto:[EMAIL PROTECTED] >> Different section of IS. The area that I'm in is responsible >> for distribution operations, so we'll schedule, pick, pack >> and ship your customised LE suit to you, but the Internet >> group will actually take your order. :-) > >So the trick is to talk directly to you guys, and then my suit is free, >right? BTW, I take a 39R. > >Cheers, >Laird > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
No. There's plenty of work, enough that LE is accepting resumes from developers. In fact, it's the large volume of work that is causing some of the smaller "nice to have" projects to be pushed to the back-burners for now, while the big strategic stuff gets time front and centre. >-Original Message- >From: Jeff Kyser [mailto:[EMAIL PROTECTED] >Sent: Tuesday, March 25, 2003 10:50 AM >To: Struts Users Mailing List >Subject: Re: [OT] Estimating a Struts-based project > > >Sounds like its time for a new tag: > > > >:^) > >-jeff > >On Tuesday, March 25, 2003, at 10:39 AM, Chappell, Simon P wrote: > >> You guys are wicked! I was trying to be serious (for a change). >> >> Interestingly enough, the 768hr estimate that was in my >original post >> (and that I was worried was too low) has killed the project. The >> resource manager took one look at it and is not even planning to >> submit it for scheduling. >> >> Simon >> >>> -Original Message- >>> From: Andrew Hill [mailto:[EMAIL PROTECTED] >>> Sent: Tuesday, March 25, 2003 10:37 AM >>> To: Struts >>> Subject: [OT] Estimating a Struts-based project >>> >>> >>> btw: be sure you have a scrabble set handy in case they want >>> to see how you >>> calculated it... :-) >>> >>> -Original Message- >>> From: Andrew Hill [mailto:[EMAIL PROTECTED] >>> Sent: Wednesday, 26 March 2003 00:36 >>> To: Struts Users Mailing List >>> Subject: RE: [OT] Estimating a Struts-based project >>> >>> >>> hmm. Then there is but one estimate you can give... >>> >>> 42! >>> >>> If they ask whether thats days or hours tell them it doesnt >>> really make a >>> difference... ;-) >>> >>> -Original Message- >>> From: Chappell, Simon P [mailto:[EMAIL PROTECTED] >>> Sent: Wednesday, 26 March 2003 00:33 >>> To: Struts Users Mailing List >>> Subject: RE: [OT] Estimating a Struts-based project >>> >>> >>> For our initial estimate, we do not have the luxury of >>> use-cases. Hence the >>> need to generate an estimate based on the smallest quantity of >>> known data >>> possible. >>> >>>> -Original Message- >>>> From: Mehra, Vishal [mailto:[EMAIL PROTECTED] >>>> Sent: Tuesday, March 25, 2003 10:05 AM >>>> To: 'Struts Users Mailing List' >>>> Subject: RE: [OT] Estimating a Struts-based project >>>> >>>> >>>> I would break these down to use cases and assign complexity to >>>> each one of >>>> them and then try estimating it that way. >>>> >>>> Regards, >>>> Vishal. >>>> >>>> >>>> -Original Message- >>>> From: Chappell, Simon P [mailto:[EMAIL PROTECTED] >>>> Sent: Monday, March 24, 2003 11:14 AM >>>> To: Struts Mailing List (E-mail) >>>> Subject: [OT] Estimating a Struts-based project >>>> >>>> >>>> I have just completed an initial estimate for a Struts-based web >>>> application. I am curious as to what estimation methods folks >>>> out there use >>>> for their initial estimates. The revised estimate will be >>>> delivered after >>>> more analysis is performed. >>>> >>>> I am fed up with making wild guesses for initial estimates and >>>> wondered if >>>> there was any way to take the small amount of information >>>> available up front >>>> (i.e. the number of screens on the user's initial workflow >>> requirements >>>> document) and extrapolate it into an estimate. I understand >>>> that the margin >>>> of error is gonna be big and hairy on this puppy, but it's >an initial >>>> estimate created with a dearth of information, so what do you >>>> expect? :-) >>>> >>>> What I did was: >>>> >>>> Take the estimated number of application screens: s=13 >>>> Take the number of application user roles: r=3 >>>> Figure which screens are used by which roles and total: sr=32 >>>> Estimate the >>>> number of actions: a = sr * 2 = 64 Application units of work: >>>> auow = a + sr >>>> = 96 Total units of work (including admin screens): tuow = >>>> auow * 2 = 192 >
RE: [OT] Estimating a Struts-based project
> -Original Message- > From: Chappell, Simon P [mailto:[EMAIL PROTECTED] > Different section of IS. The area that I'm in is responsible > for distribution operations, so we'll schedule, pick, pack > and ship your customised LE suit to you, but the Internet > group will actually take your order. :-) So the trick is to talk directly to you guys, and then my suit is free, right? BTW, I take a 39R. Cheers, Laird - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Estimating a Struts-based project
Sounds like its time for a new tag: :^) -jeff On Tuesday, March 25, 2003, at 10:39 AM, Chappell, Simon P wrote: You guys are wicked! I was trying to be serious (for a change). Interestingly enough, the 768hr estimate that was in my original post (and that I was worried was too low) has killed the project. The resource manager took one look at it and is not even planning to submit it for scheduling. Simon -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 10:37 AM To: Struts Subject: [OT] Estimating a Struts-based project btw: be sure you have a scrabble set handy in case they want to see how you calculated it... :-) -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: Wednesday, 26 March 2003 00:36 To: Struts Users Mailing List Subject: RE: [OT] Estimating a Struts-based project hmm. Then there is but one estimate you can give... 42! If they ask whether thats days or hours tell them it doesnt really make a difference... ;-) -Original Message- From: Chappell, Simon P [mailto:[EMAIL PROTECTED] Sent: Wednesday, 26 March 2003 00:33 To: Struts Users Mailing List Subject: RE: [OT] Estimating a Struts-based project For our initial estimate, we do not have the luxury of use-cases. Hence the need to generate an estimate based on the smallest quantity of known data possible. -Original Message- From: Mehra, Vishal [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 10:05 AM To: 'Struts Users Mailing List' Subject: RE: [OT] Estimating a Struts-based project I would break these down to use cases and assign complexity to each one of them and then try estimating it that way. Regards, Vishal. -Original Message- From: Chappell, Simon P [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2003 11:14 AM To: Struts Mailing List (E-mail) Subject: [OT] Estimating a Struts-based project I have just completed an initial estimate for a Struts-based web application. I am curious as to what estimation methods folks out there use for their initial estimates. The revised estimate will be delivered after more analysis is performed. I am fed up with making wild guesses for initial estimates and wondered if there was any way to take the small amount of information available up front (i.e. the number of screens on the user's initial workflow requirements document) and extrapolate it into an estimate. I understand that the margin of error is gonna be big and hairy on this puppy, but it's an initial estimate created with a dearth of information, so what do you expect? :-) What I did was: Take the estimated number of application screens: s=13 Take the number of application user roles: r=3 Figure which screens are used by which roles and total: sr=32 Estimate the number of actions: a = sr * 2 = 64 Application units of work: auow = a + sr = 96 Total units of work (including admin screens): tuow = auow * 2 = 192 Estimate an effort factor per unit: ef = 4hr Programmer work: pw = tuow * ef = 768hrs Some assumptions included in these calculations include: 1. An average of two actions per screen role. 2. The administration facility of an application is about 50% of the work. 3. The effort factor is a figure arrived at from knowledge of the programmer being tasked and the number of new technologies within the project. Your thoughts please. Simon - Simon P. Chappell [EMAIL PROTECTED] Java Programming Specialist www.landsend.com Lands' End, Inc. (608) 935-4526 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
>So no customizemylandsendsuit.com? Different section of IS. The area that I'm in is responsible for distribution operations, so we'll schedule, pick, pack and ship your customised LE suit to you, but the Internet group will actually take your order. :-) >Cheers, >Laird Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
> -Original Message- > From: Chappell, Simon P [mailto:[EMAIL PROTECTED] > Interestingly enough, the 768hr estimate that was in my > original post (and that I was worried was too low) has killed > the project. The resource manager took one look at it and is > not even planning to submit it for scheduling. So no customizemylandsendsuit.com? Cheers, Laird - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
> Interestingly enough, the 768hr estimate that was in my original > post (and that I was worried was too low) has killed the project. > The resource manager took one look at it and is not even planning > to submit it for scheduling. That's why it's important to be as accurate as possible, best that the project be canceled now than half way through. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
You guys are wicked! I was trying to be serious (for a change). Interestingly enough, the 768hr estimate that was in my original post (and that I was worried was too low) has killed the project. The resource manager took one look at it and is not even planning to submit it for scheduling. Simon >-Original Message- >From: Andrew Hill [mailto:[EMAIL PROTECTED] >Sent: Tuesday, March 25, 2003 10:37 AM >To: Struts >Subject: [OT] Estimating a Struts-based project > > >btw: be sure you have a scrabble set handy in case they want >to see how you >calculated it... :-) > >-Original Message- >From: Andrew Hill [mailto:[EMAIL PROTECTED] >Sent: Wednesday, 26 March 2003 00:36 >To: Struts Users Mailing List >Subject: RE: [OT] Estimating a Struts-based project > > >hmm. Then there is but one estimate you can give... > >42! > >If they ask whether thats days or hours tell them it doesnt >really make a >difference... ;-) > >-Original Message- >From: Chappell, Simon P [mailto:[EMAIL PROTECTED] >Sent: Wednesday, 26 March 2003 00:33 >To: Struts Users Mailing List >Subject: RE: [OT] Estimating a Struts-based project > > >For our initial estimate, we do not have the luxury of >use-cases. Hence the >need to generate an estimate based on the smallest quantity of >known data >possible. > >>-Original Message- >>From: Mehra, Vishal [mailto:[EMAIL PROTECTED] >>Sent: Tuesday, March 25, 2003 10:05 AM >>To: 'Struts Users Mailing List' >>Subject: RE: [OT] Estimating a Struts-based project >> >> >>I would break these down to use cases and assign complexity to >>each one of >>them and then try estimating it that way. >> >>Regards, >>Vishal. >> >> >>-Original Message- >>From: Chappell, Simon P [mailto:[EMAIL PROTECTED] >>Sent: Monday, March 24, 2003 11:14 AM >>To: Struts Mailing List (E-mail) >>Subject: [OT] Estimating a Struts-based project >> >> >>I have just completed an initial estimate for a Struts-based web >>application. I am curious as to what estimation methods folks >>out there use >>for their initial estimates. The revised estimate will be >>delivered after >>more analysis is performed. >> >>I am fed up with making wild guesses for initial estimates and >>wondered if >>there was any way to take the small amount of information >>available up front >>(i.e. the number of screens on the user's initial workflow >requirements >>document) and extrapolate it into an estimate. I understand >>that the margin >>of error is gonna be big and hairy on this puppy, but it's an initial >>estimate created with a dearth of information, so what do you >>expect? :-) >> >>What I did was: >> >>Take the estimated number of application screens: s=13 >>Take the number of application user roles: r=3 >>Figure which screens are used by which roles and total: sr=32 >>Estimate the >>number of actions: a = sr * 2 = 64 Application units of work: >>auow = a + sr >>= 96 Total units of work (including admin screens): tuow = >>auow * 2 = 192 >>Estimate an effort factor per unit: ef = 4hr Programmer work: >>pw = tuow * ef >>= 768hrs >> >>Some assumptions included in these calculations include: >>1. An average of two actions per screen role. >>2. The administration facility of an application is about 50% >>of the work. >>3. The effort factor is a figure arrived at from knowledge of >>the programmer >>being tasked and the number of new technologies within the project. >> >>Your thoughts please. >> >>Simon >> >>- >>Simon P. Chappell [EMAIL PROTECTED] >>Java Programming Specialist www.landsend.com >>Lands' End, Inc. (608) 935-4526 >> >>- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >>- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
Come on Andrew, 42 is much too high. Can't you trim that down a bit? > -Original Message- > From: Andrew Hill [mailto:[EMAIL PROTECTED] > Sent: mardi 25 mars 2003 17:36 > To: Struts Users Mailing List > Subject: RE: [OT] Estimating a Struts-based project > > > hmm. Then there is but one estimate you can give... > > 42! > > If they ask whether thats days or hours tell them it doesnt really make a > difference... ;-) > > -Original Message- > From: Chappell, Simon P [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 26 March 2003 00:33 > To: Struts Users Mailing List > Subject: RE: [OT] Estimating a Struts-based project > > > For our initial estimate, we do not have the luxury of use-cases. > Hence the > need to generate an estimate based on the smallest quantity of known data > possible. > > >-Original Message- > >From: Mehra, Vishal [mailto:[EMAIL PROTECTED] > >Sent: Tuesday, March 25, 2003 10:05 AM > >To: 'Struts Users Mailing List' > >Subject: RE: [OT] Estimating a Struts-based project > > > > > >I would break these down to use cases and assign complexity to > >each one of > >them and then try estimating it that way. > > > >Regards, > >Vishal. > > > > > >-Original Message- > >From: Chappell, Simon P [mailto:[EMAIL PROTECTED] > >Sent: Monday, March 24, 2003 11:14 AM > >To: Struts Mailing List (E-mail) > >Subject: [OT] Estimating a Struts-based project > > > > > >I have just completed an initial estimate for a Struts-based web > >application. I am curious as to what estimation methods folks > >out there use > >for their initial estimates. The revised estimate will be > >delivered after > >more analysis is performed. > > > >I am fed up with making wild guesses for initial estimates and > >wondered if > >there was any way to take the small amount of information > >available up front > >(i.e. the number of screens on the user's initial workflow requirements > >document) and extrapolate it into an estimate. I understand > >that the margin > >of error is gonna be big and hairy on this puppy, but it's an initial > >estimate created with a dearth of information, so what do you > >expect? :-) > > > >What I did was: > > > >Take the estimated number of application screens: s=13 > >Take the number of application user roles: r=3 > >Figure which screens are used by which roles and total: sr=32 > >Estimate the > >number of actions: a = sr * 2 = 64 Application units of work: > >auow = a + sr > >= 96 Total units of work (including admin screens): tuow = > >auow * 2 = 192 > >Estimate an effort factor per unit: ef = 4hr Programmer work: > >pw = tuow * ef > >= 768hrs > > > >Some assumptions included in these calculations include: > >1. An average of two actions per screen role. > >2. The administration facility of an application is about 50% > >of the work. > >3. The effort factor is a figure arrived at from knowledge of > >the programmer > >being tasked and the number of new technologies within the project. > > > >Your thoughts please. > > > >Simon > > > >- > >Simon P. Chappell [EMAIL PROTECTED] > >Java Programming Specialist www.landsend.com > >Lands' End, Inc. (608) 935-4526 > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
hmm. Then there is but one estimate you can give... 42! If they ask whether thats days or hours tell them it doesnt really make a difference... ;-) -Original Message- From: Chappell, Simon P [mailto:[EMAIL PROTECTED] Sent: Wednesday, 26 March 2003 00:33 To: Struts Users Mailing List Subject: RE: [OT] Estimating a Struts-based project For our initial estimate, we do not have the luxury of use-cases. Hence the need to generate an estimate based on the smallest quantity of known data possible. >-Original Message- >From: Mehra, Vishal [mailto:[EMAIL PROTECTED] >Sent: Tuesday, March 25, 2003 10:05 AM >To: 'Struts Users Mailing List' >Subject: RE: [OT] Estimating a Struts-based project > > >I would break these down to use cases and assign complexity to >each one of >them and then try estimating it that way. > >Regards, >Vishal. > > >-Original Message- >From: Chappell, Simon P [mailto:[EMAIL PROTECTED] >Sent: Monday, March 24, 2003 11:14 AM >To: Struts Mailing List (E-mail) >Subject: [OT] Estimating a Struts-based project > > >I have just completed an initial estimate for a Struts-based web >application. I am curious as to what estimation methods folks >out there use >for their initial estimates. The revised estimate will be >delivered after >more analysis is performed. > >I am fed up with making wild guesses for initial estimates and >wondered if >there was any way to take the small amount of information >available up front >(i.e. the number of screens on the user's initial workflow requirements >document) and extrapolate it into an estimate. I understand >that the margin >of error is gonna be big and hairy on this puppy, but it's an initial >estimate created with a dearth of information, so what do you >expect? :-) > >What I did was: > >Take the estimated number of application screens: s=13 >Take the number of application user roles: r=3 >Figure which screens are used by which roles and total: sr=32 >Estimate the >number of actions: a = sr * 2 = 64 Application units of work: >auow = a + sr >= 96 Total units of work (including admin screens): tuow = >auow * 2 = 192 >Estimate an effort factor per unit: ef = 4hr Programmer work: >pw = tuow * ef >= 768hrs > >Some assumptions included in these calculations include: >1. An average of two actions per screen role. >2. The administration facility of an application is about 50% >of the work. >3. The effort factor is a figure arrived at from knowledge of >the programmer >being tasked and the number of new technologies within the project. > >Your thoughts please. > >Simon > >- >Simon P. Chappell [EMAIL PROTECTED] >Java Programming Specialist www.landsend.com >Lands' End, Inc. (608) 935-4526 > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
For our initial estimate, we do not have the luxury of use-cases. Hence the need to generate an estimate based on the smallest quantity of known data possible. >-Original Message- >From: Mehra, Vishal [mailto:[EMAIL PROTECTED] >Sent: Tuesday, March 25, 2003 10:05 AM >To: 'Struts Users Mailing List' >Subject: RE: [OT] Estimating a Struts-based project > > >I would break these down to use cases and assign complexity to >each one of >them and then try estimating it that way. > >Regards, >Vishal. > > >-Original Message- >From: Chappell, Simon P [mailto:[EMAIL PROTECTED] >Sent: Monday, March 24, 2003 11:14 AM >To: Struts Mailing List (E-mail) >Subject: [OT] Estimating a Struts-based project > > >I have just completed an initial estimate for a Struts-based web >application. I am curious as to what estimation methods folks >out there use >for their initial estimates. The revised estimate will be >delivered after >more analysis is performed. > >I am fed up with making wild guesses for initial estimates and >wondered if >there was any way to take the small amount of information >available up front >(i.e. the number of screens on the user's initial workflow requirements >document) and extrapolate it into an estimate. I understand >that the margin >of error is gonna be big and hairy on this puppy, but it's an initial >estimate created with a dearth of information, so what do you >expect? :-) > >What I did was: > >Take the estimated number of application screens: s=13 >Take the number of application user roles: r=3 >Figure which screens are used by which roles and total: sr=32 >Estimate the >number of actions: a = sr * 2 = 64 Application units of work: >auow = a + sr >= 96 Total units of work (including admin screens): tuow = >auow * 2 = 192 >Estimate an effort factor per unit: ef = 4hr Programmer work: >pw = tuow * ef >= 768hrs > >Some assumptions included in these calculations include: >1. An average of two actions per screen role. >2. The administration facility of an application is about 50% >of the work. >3. The effort factor is a figure arrived at from knowledge of >the programmer >being tasked and the number of new technologies within the project. > >Your thoughts please. > >Simon > >- >Simon P. Chappell [EMAIL PROTECTED] >Java Programming Specialist www.landsend.com >Lands' End, Inc. (608) 935-4526 > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
I would break these down to use cases and assign complexity to each one of them and then try estimating it that way. Regards, Vishal. -Original Message- From: Chappell, Simon P [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2003 11:14 AM To: Struts Mailing List (E-mail) Subject: [OT] Estimating a Struts-based project I have just completed an initial estimate for a Struts-based web application. I am curious as to what estimation methods folks out there use for their initial estimates. The revised estimate will be delivered after more analysis is performed. I am fed up with making wild guesses for initial estimates and wondered if there was any way to take the small amount of information available up front (i.e. the number of screens on the user's initial workflow requirements document) and extrapolate it into an estimate. I understand that the margin of error is gonna be big and hairy on this puppy, but it's an initial estimate created with a dearth of information, so what do you expect? :-) What I did was: Take the estimated number of application screens: s=13 Take the number of application user roles: r=3 Figure which screens are used by which roles and total: sr=32 Estimate the number of actions: a = sr * 2 = 64 Application units of work: auow = a + sr = 96 Total units of work (including admin screens): tuow = auow * 2 = 192 Estimate an effort factor per unit: ef = 4hr Programmer work: pw = tuow * ef = 768hrs Some assumptions included in these calculations include: 1. An average of two actions per screen role. 2. The administration facility of an application is about 50% of the work. 3. The effort factor is a figure arrived at from knowledge of the programmer being tasked and the number of new technologies within the project. Your thoughts please. Simon - Simon P. Chappell [EMAIL PROTECTED] Java Programming Specialist www.landsend.com Lands' End, Inc. (608) 935-4526 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
>-Original Message- >From: Michael Mattox [mailto:[EMAIL PROTECTED] >Sent: Tuesday, March 25, 2003 9:47 AM >To: Struts Users Mailing List >Subject: RE: [OT] Estimating a Struts-based project >> >This sounds like a perfect scenario for eXtreme Programming. >> >> Actually, the first Struts project we did here, we used elements >> of XP. It went well and was declared a huge success by the CEO at >> the company employee meeting! :-) > >Glad to hear that! I hope you can use even more XP principles >on your next >project. That's the plan. I'm trying to get more testing added in this time around. We used unit testing, but this time there will be more of that and I'm also looking to add in functional, performance and load testing to the mix. >Michael Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
>-Original Message- >From: Andrew Hill [mailto:[EMAIL PROTECTED] >Sent: Tuesday, March 25, 2003 9:00 AM >To: Struts Users Mailing List >Subject: RE: [OT] Estimating a Struts-based project > > >Well given such constraints, your most accurate estimates are >likely to come >from an astrologer - or even an economist - nah! thats going a >bit far. Ill >stick with the astrologer. :-) >Failing that you could do what I do when subjected to the >gnashing of teeth >routine. >These estimates arent worth [one of Mark's this's] but the >proportions are >correct - just not the magnitude: > >First you estimate the times using the method you think would >actually come >up with something thats relatively accurate. This will of >course give you >estimates that the client won't accept. I'm very good at coming up with estimates that make them spit blood. >The client of course already has their own 'estimate' (they call it a >deadline). Yes. Every project starts with an acronym and a deadline. Well known fact. Actually, that's the only well known thing at the start of most projects. >You see how many hours there are until that >deadline, and then >allocate your estimates to add up to that based on the >proportions in the >'real' estimate. So, don't bother creating an estimate. Or create one that you are happy to have ignored. This is why I want to algorithmise (not a real word) the process so that I can easily and with little real effort create a quasi-realistic estimate that management can then safely ignore, but that I could actually work from the 1% of the time that they supprise me and accept the estimate. >Then think of something that sounds quite unlikely to occur >(but is in fact >100% certain (an unexpected windows bug perhaps?)) and make a >small note on >the quote that if this happens it just might possibily in the >worst case >increase the estimates by a factor of x (where of course x is >the value that >the clients estimate of total work needs to be multiplied with >to get the >real estimate of total work...) This is too much like CYA and I never do that. If a project fails after my estimate was ignored, I refuse to feel bad about it. Simon >-Original Message- >From: Chappell, Simon P [mailto:[EMAIL PROTECTED] >Sent: Tuesday, 25 March 2003 22:38 >To: Struts Users Mailing List >Subject: RE: [OT] Estimating a Struts-based project > > >These have all been good suggestions, but I am constrained >here by a number >of factors. > >All our estimates have to be in hours. >There is screaming and wailing and gnashing of teeth if the >estimate is "too >big". >We are not a software house, so the business gets to set schedules. >We are a HIGHLY seasonal business, this forces many scheduling >decisions. >etc. etc. > >Thanks to everyone. > >Simon > >- >Simon P. Chappell [EMAIL PROTECTED] >Java Programming Specialist www.landsend.com >Lands' End, Inc. (608) 935-4526 > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
> >Hours are too fine grained. > > Agreed. But even when I give them estimates in days and weeks, > they ask for them to be resubmitted in hours. The XP approach uses "points" and velocity for scheduling. The problem with calendar time is then the managers expect the programmers to stick to the dates. But in reality no one can predict with absolute certainty how long a project will take. I think XP's approach handles this issue very nicely. > >This sounds like a perfect scenario for eXtreme Programming. > > Actually, the first Struts project we did here, we used elements > of XP. It went well and was declared a huge success by the CEO at > the company employee meeting! :-) Glad to hear that! I hope you can use even more XP principles on your next project. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
>-Original Message- >From: Michael Mattox [mailto:[EMAIL PROTECTED] >Sent: Tuesday, March 25, 2003 9:03 AM >To: Struts Users Mailing List >Subject: RE: [OT] Estimating a Struts-based project > > >> All our estimates have to be in hours. > >Hours are too fine grained. Agreed. But even when I give them estimates in days and weeks, they ask for them to be resubmitted in hours. >> There is screaming and wailing and gnashing of teeth if the >> estimate is "too >> big". >> We are not a software house, so the business gets to set schedules. >> We are a HIGHLY seasonal business, this forces many >scheduling decisions. >> etc. etc. > >This sounds like a perfect scenario for eXtreme Programming. Actually, the first Struts project we did here, we used elements of XP. It went well and was declared a huge success by the CEO at the company employee meeting! :-) >Michael Simon - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
"Nine women can't make a baby in a month"
True - but it could be amusing to watch them try ;-)
Feel free to send them to my
email address to keep the list clutter-free.
On the contrary post them! Sure its a little off topic, but I think many
struts users, myself included, would be interested and could benefit. (Btw:
(ignoring my own vaguely semihumourous but otherwise useless contributions
for a moment) this is IMNSHO the sort of useful off-topic discussion that
makes the struts list much 'better' than more focused special interest
lists...)
-Original Message-
From: Nelson, Laird [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 25 March 2003 23:18
To: 'Struts Users Mailing List'
Subject: RE: [OT] Estimating a Struts-based project
Importance: Low
> -Original Message-
> From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
> There is screaming and wailing and gnashing of teeth if the
> estimate is "too big".
Long post follows, but I find this stuff interesting. I'll shut up after
this. :-)
I've found time estimate discussions are usually proxies for something else.
In right-side-scheduled projects, where the "right side" of the project
timeline is basically fixed, rationally or irrationally, when the project
leader is asking you for an estimate, she's usually asking you for a list of
things that can be cut from the scope (I'm not claiming this is a
revolutionary discovery). The sooner you can get to *that* discussion, the
better the negotiation and management goes from there. In pretty much every
time estimate discussion I've had, it's gone either like this:
Manager: Give me an estimate for the frobnicator piece.
Me: {various calculations} Three months.
Manager: Three MONTHS? That's {however much it is} man hours! That's too
long. Can you do it in five weeks? We need this project done by February.
Me: {honestly thinking} Well, I'm uncomfortable with five weeks;
realistically speaking, I could probably pull it off, but I wouldn't hav--
Manager: Well, what can we do to bring this thing in by February 17th?
[ding ding ding; turns out time estimate is not needed; switch to scope
discussion here]
Me: Hmm; how about trimming back the customizable frobnication interval?
That should knock some time off.
...or like this:
Manager: {looking sad and scared} OK, we signed a contract with BigCo last
week. My hands are tied. I have a wife and child to feed and I'm concerned
about my job. We must deliver this project on May 12 or we all get fired.
How can we do this?
Me: {sympathetically sad and scared} Well, that means that {both of us stare
at project diagram with a big black vertical line on May 12} THIS piece has
to take four weeks, and THIS piece has to take three weeks...
{much playing with crayons or their sophisticated electronic equivalents
ensues; red lines and green milestones and burnt umber critical paths and so
forth are drawn and redrawn}
Both of us: There! A diagram that shows that we can hit May 12!
Manager: Go. Start coding. I'll do what I can to find out what you need to
code. Meanwhile I'll run this vaguely
insulting-to-me-because-it-reduces-my-job-to-drawing-pictures-to-support-som
ething-that-will-not-happen-as-methodically-as-presented diagram up to
senior management so they will continue to employ me. And I will try not to
get in your way.
Me: OK; good luck. I'll try to anticipate requirements and not get angry at
you because it's not really your fault either.
[dynamic scope negotiation occurs hereafter, often referred to as change
management, with varying levels of formality]
Sometimes you'll hear, "But it has to be done by September and we can't cut
*anything*. Can't we just add more people?" The old saw, "Nine women can't
make a baby in a month" usually helps here and adds a bit of humor to the
otherwise dreary process. :-)
Incidentally, engineers (myself included) are at fault on the scope end as
much, oftentimes, as project managers or business types are on the time end:
we often claim that we can't trim scope because hey, that would cripple the
application, or, why bother even *releasing* the application if it can't do
this Great Trick? Usually, I've found that if I swallow hard and dig in
hard enough I can find spots where scope can be cut.
There must be some educational reading out there for *real*-world project
management, where there *can't* be any deadline negotiation because (pick
one):
(a) the business folks have already started marketing the product
(b) a salesman doing his best to help the company has promised something to
a client by a certain date
(c) a multizillion-dollar contract has been signed with a date window as a
necessary condition
(d) a trade show featuring the product is coming up in June
I guess I'm talking about books
RE: [OT] Estimating a Struts-based project
> -Original Message-
> From: Chappell, Simon P [mailto:[EMAIL PROTECTED]
> There is screaming and wailing and gnashing of teeth if the
> estimate is "too big".
Long post follows, but I find this stuff interesting. I'll shut up after
this. :-)
I've found time estimate discussions are usually proxies for something else.
In right-side-scheduled projects, where the "right side" of the project
timeline is basically fixed, rationally or irrationally, when the project
leader is asking you for an estimate, she's usually asking you for a list of
things that can be cut from the scope (I'm not claiming this is a
revolutionary discovery). The sooner you can get to *that* discussion, the
better the negotiation and management goes from there. In pretty much every
time estimate discussion I've had, it's gone either like this:
Manager: Give me an estimate for the frobnicator piece.
Me: {various calculations} Three months.
Manager: Three MONTHS? That's {however much it is} man hours! That's too
long. Can you do it in five weeks? We need this project done by February.
Me: {honestly thinking} Well, I'm uncomfortable with five weeks;
realistically speaking, I could probably pull it off, but I wouldn't hav--
Manager: Well, what can we do to bring this thing in by February 17th?
[ding ding ding; turns out time estimate is not needed; switch to scope
discussion here]
Me: Hmm; how about trimming back the customizable frobnication interval?
That should knock some time off.
...or like this:
Manager: {looking sad and scared} OK, we signed a contract with BigCo last
week. My hands are tied. I have a wife and child to feed and I'm concerned
about my job. We must deliver this project on May 12 or we all get fired.
How can we do this?
Me: {sympathetically sad and scared} Well, that means that {both of us stare
at project diagram with a big black vertical line on May 12} THIS piece has
to take four weeks, and THIS piece has to take three weeks...
{much playing with crayons or their sophisticated electronic equivalents
ensues; red lines and green milestones and burnt umber critical paths and so
forth are drawn and redrawn}
Both of us: There! A diagram that shows that we can hit May 12!
Manager: Go. Start coding. I'll do what I can to find out what you need to
code. Meanwhile I'll run this vaguely
insulting-to-me-because-it-reduces-my-job-to-drawing-pictures-to-support-som
ething-that-will-not-happen-as-methodically-as-presented diagram up to
senior management so they will continue to employ me. And I will try not to
get in your way.
Me: OK; good luck. I'll try to anticipate requirements and not get angry at
you because it's not really your fault either.
[dynamic scope negotiation occurs hereafter, often referred to as change
management, with varying levels of formality]
Sometimes you'll hear, "But it has to be done by September and we can't cut
*anything*. Can't we just add more people?" The old saw, "Nine women can't
make a baby in a month" usually helps here and adds a bit of humor to the
otherwise dreary process. :-)
Incidentally, engineers (myself included) are at fault on the scope end as
much, oftentimes, as project managers or business types are on the time end:
we often claim that we can't trim scope because hey, that would cripple the
application, or, why bother even *releasing* the application if it can't do
this Great Trick? Usually, I've found that if I swallow hard and dig in
hard enough I can find spots where scope can be cut.
There must be some educational reading out there for *real*-world project
management, where there *can't* be any deadline negotiation because (pick
one):
(a) the business folks have already started marketing the product
(b) a salesman doing his best to help the company has promised something to
a client by a certain date
(c) a multizillion-dollar contract has been signed with a date window as a
necessary condition
(d) a trade show featuring the product is coming up in June
I guess I'm talking about books or links that do not tell you to iterate the
schedule (nice, desirable, rarely possible) or to plan in padding time
(absolutely impossible in nearly every case) to get around the issues. Does
anyone know of books or links on this subject? Feel free to send them to my
email address to keep the list clutter-free.
Cheers,
Laird
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
> All our estimates have to be in hours. Hours are too fine grained. > There is screaming and wailing and gnashing of teeth if the > estimate is "too > big". > We are not a software house, so the business gets to set schedules. > We are a HIGHLY seasonal business, this forces many scheduling decisions. > etc. etc. This sounds like a perfect scenario for eXtreme Programming. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
Well given such constraints, your most accurate estimates are likely to come from an astrologer - or even an economist - nah! thats going a bit far. Ill stick with the astrologer. Failing that you could do what I do when subjected to the gnashing of teeth routine. These estimates arent worth [one of Mark's this's] but the proportions are correct - just not the magnitude: First you estimate the times using the method you think would actually come up with something thats relatively accurate. This will of course give you estimates that the client won't accept. The client of course already has their own 'estimate' (they call it a deadline). You see how many hours there are until that deadline, and then allocate your estimates to add up to that based on the proportions in the 'real' estimate. Then think of something that sounds quite unlikely to occur (but is in fact 100% certain (an unexpected windows bug perhaps?)) and make a small note on the quote that if this happens it just might possibily in the worst case increase the estimates by a factor of x (where of course x is the value that the clients estimate of total work needs to be multiplied with to get the real estimate of total work...) -Original Message- From: Chappell, Simon P [mailto:[EMAIL PROTECTED] Sent: Tuesday, 25 March 2003 22:38 To: Struts Users Mailing List Subject: RE: [OT] Estimating a Struts-based project These have all been good suggestions, but I am constrained here by a number of factors. All our estimates have to be in hours. There is screaming and wailing and gnashing of teeth if the estimate is "too big". We are not a software house, so the business gets to set schedules. We are a HIGHLY seasonal business, this forces many scheduling decisions. etc. etc. Thanks to everyone. Simon - Simon P. Chappell [EMAIL PROTECTED] Java Programming Specialist www.landsend.com Lands' End, Inc. (608) 935-4526 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
These have all been good suggestions, but I am constrained here by a number of factors. All our estimates have to be in hours. There is screaming and wailing and gnashing of teeth if the estimate is "too big". We are not a software house, so the business gets to set schedules. We are a HIGHLY seasonal business, this forces many scheduling decisions. etc. etc. Thanks to everyone. Simon - Simon P. Chappell [EMAIL PROTECTED] Java Programming Specialist www.landsend.com Lands' End, Inc. (608) 935-4526 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Estimating a Struts-based project
Two other estimate tips: 1. Give your estimate using a range (preferably one that means something - e.g. soonest to latest around some likely date; you could get fancy and use standard deviations and ...) 2. Don't give overly precise estimates, for example < 10 days, use days < 6 weeks, use weeks <= 5 months, use months > 5 months && < 12 months, use quarters Just some stuff from Steve McConnell's work and also the Pragmatic Programmers (I think, don't have references handy...). --Tim Jeff Smith wrote: What? You don't increment the units as well? If I am looking for a safe estimate and a developer tells me 2 weeks, I automatically plan for 4 months. In all my years of experience I have NEVER gone over estimate with this method and I have been only been over by more than 20% 3 times in about 80 projects. Sad but true. Jefficus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Estimating a Struts-based project
I did, I just worded it poorly. :-) None of the projects ever came in late. And in all but 3 cases, the overestimate was by less than 20%. One has to be careful to clarify what I was estimating. This was usually when asking a developer to estimate his effort to get a feature into a shrink-wrapped (or other) commercial software product. The time includes all design, prototyping and implementation time as well as all bug-fixing time required on that feature to make it "ready for prime time". It also includes programmers documentation and programmers contribution to product documentation for that feature, as well as sick time and acts of God. In other words, there are a lot of schedule costs that simply don't occur to a developer when you ask for an estimate. And these little extra bits of time add up to staggering project overruns if you aren't careful. Of course, you also have to be careful with WHO you apply these estimate corrections to. More senior developers probably factor many of these items into their estimates. But if you're looking for a one-size-fits-all estimating rule, I find this to be a handy upper-bound. BTW, I have never had the courage to recommend that a 2 month project be budgeted for 4 years, although there are times when I wish I had. :-) Jefficus - Original Message - From: "David Graham" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, March 24, 2003 3:51 PM Subject: Re: [OT] Estimating a Struts-based project > But how close were your estimates? You didn't say how far below the > estimate you usually ended up. > > David > > > > >From: "Jeff Smith" <[EMAIL PROTECTED]> > >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > >To: "Struts Users Mailing List" <[EMAIL PROTECTED]> > >Subject: Re: [OT] Estimating a Struts-based project > >Date: Mon, 24 Mar 2003 15:47:27 -0700 > > > >What? You don't increment the units as well? > > > >If I am looking for a safe estimate and a developer tells me 2 weeks, I > >automatically plan for 4 months. In all my years of experience I have NEVER > >gone over estimate with this method and I have been only been over by more > >than 20% 3 times in about 80 projects. > > > >Sad but true. > > > >Jefficus > > > >- Original Message - > >From: "Mark Galbreath" <[EMAIL PROTECTED]> > >To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> > >Sent: Monday, March 24, 2003 10:31 AM > >Subject: RE: [OT] Estimating a Struts-based project > > > > > > > Okay, now double your estimate and you have a starting figure. > > > > > > -Original Message- > > > From: Chappell, Simon P [mailto:[EMAIL PROTECTED] > > > Sent: Monday, March 24, 2003 12:21 PM > > > To: Struts Users Mailing List > > > Subject: RE: [OT] Estimating a Struts-based project > > > > > > > > > > > > > > > >-Original Message- > > > >From: James Mitchell [mailto:[EMAIL PROTECTED] > > > >Sent: Monday, March 24, 2003 11:18 AM > > > >To: Struts Users Mailing List > > > >Subject: Re: [OT] Estimating a Struts-based project > > > > > > > > > > > > >Did you factor in the time for writing/maintaining tests? > > > > > > I'm hurt that you even felt you had to ask! ;-) > > > > > > Yes. As far as is possible, I have people write unit tests for code > >(before > > > if possible) and we are in the process of selecting further testing > >tools > > > for good stuff like functional testing, load testing and performance > > > testing. > > > > > > Simon > > > > > > - > > > Simon P. Chappell [EMAIL PROTECTED] > > > Java Programming Specialist www.landsend.com > > > Lands' End, Inc. (608) 935-4526 > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > >- > >To unsubscribe, e-mail: [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > > > > > _ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
I'm sure they were right on target -- remember the great laws of Brooks and Lubarsky: 1. Thowing manpower at a late software project makes it later. 2. there's always one more bug. And the hypothesis of equal time pressure: Resources consumed will expand to the limits of resources available. -Original Message- From: David Graham [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2003 5:52 PM To: [EMAIL PROTECTED] Subject: Re: [OT] Estimating a Struts-based project But how close were your estimates? You didn't say how far below the estimate you usually ended up. David >From: "Jeff Smith" <[EMAIL PROTECTED]> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >To: "Struts Users Mailing List" <[EMAIL PROTECTED]> >Subject: Re: [OT] Estimating a Struts-based project >Date: Mon, 24 Mar 2003 15:47:27 -0700 > >What? You don't increment the units as well? > >If I am looking for a safe estimate and a developer tells me 2 weeks, I >automatically plan for 4 months. In all my years of experience I have NEVER >gone over estimate with this method and I have been only been over by more >than 20% 3 times in about 80 projects. > >Sad but true. > >Jefficus > >- Original Message - >From: "Mark Galbreath" <[EMAIL PROTECTED]> >To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> >Sent: Monday, March 24, 2003 10:31 AM >Subject: RE: [OT] Estimating a Struts-based project > > > > Okay, now double your estimate and you have a starting figure. > > > > -Original Message- > > From: Chappell, Simon P [mailto:[EMAIL PROTECTED] > > Sent: Monday, March 24, 2003 12:21 PM > > To: Struts Users Mailing List > > Subject: RE: [OT] Estimating a Struts-based project > > > > > > > > > > >-Original Message- > > >From: James Mitchell [mailto:[EMAIL PROTECTED] > > >Sent: Monday, March 24, 2003 11:18 AM > > >To: Struts Users Mailing List > > >Subject: Re: [OT] Estimating a Struts-based project > > > > > > > > >Did you factor in the time for writing/maintaining tests? > > > > I'm hurt that you even felt you had to ask! ;-) > > > > Yes. As far as is possible, I have people write unit tests for code >(before > > if possible) and we are in the process of selecting further testing >tools > > for good stuff like functional testing, load testing and performance > > testing. > > > > Simon > > > > - > > Simon P. Chappell [EMAIL PROTECTED] > > Java Programming Specialist www.landsend.com > > Lands' End, Inc. (608) 935-4526 > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Estimating a Struts-based project
But how close were your estimates? You didn't say how far below the estimate you usually ended up. David From: "Jeff Smith" <[EMAIL PROTECTED]> Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Subject: Re: [OT] Estimating a Struts-based project Date: Mon, 24 Mar 2003 15:47:27 -0700 What? You don't increment the units as well? If I am looking for a safe estimate and a developer tells me 2 weeks, I automatically plan for 4 months. In all my years of experience I have NEVER gone over estimate with this method and I have been only been over by more than 20% 3 times in about 80 projects. Sad but true. Jefficus - Original Message - From: "Mark Galbreath" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> Sent: Monday, March 24, 2003 10:31 AM Subject: RE: [OT] Estimating a Struts-based project > Okay, now double your estimate and you have a starting figure. > > -Original Message- > From: Chappell, Simon P [mailto:[EMAIL PROTECTED] > Sent: Monday, March 24, 2003 12:21 PM > To: Struts Users Mailing List > Subject: RE: [OT] Estimating a Struts-based project > > > > > >-Original Message----- > >From: James Mitchell [mailto:[EMAIL PROTECTED] > >Sent: Monday, March 24, 2003 11:18 AM > >To: Struts Users Mailing List > >Subject: Re: [OT] Estimating a Struts-based project > > > > >Did you factor in the time for writing/maintaining tests? > > I'm hurt that you even felt you had to ask! ;-) > > Yes. As far as is possible, I have people write unit tests for code (before > if possible) and we are in the process of selecting further testing tools > for good stuff like functional testing, load testing and performance > testing. > > Simon > > - > Simon P. Chappell [EMAIL PROTECTED] > Java Programming Specialist www.landsend.com > Lands' End, Inc. (608) 935-4526 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ Add photos to your messages with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Estimating a Struts-based project
What? You don't increment the units as well? If I am looking for a safe estimate and a developer tells me 2 weeks, I automatically plan for 4 months. In all my years of experience I have NEVER gone over estimate with this method and I have been only been over by more than 20% 3 times in about 80 projects. Sad but true. Jefficus - Original Message - From: "Mark Galbreath" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> Sent: Monday, March 24, 2003 10:31 AM Subject: RE: [OT] Estimating a Struts-based project > Okay, now double your estimate and you have a starting figure. > > -Original Message- > From: Chappell, Simon P [mailto:[EMAIL PROTECTED] > Sent: Monday, March 24, 2003 12:21 PM > To: Struts Users Mailing List > Subject: RE: [OT] Estimating a Struts-based project > > > > > >-Original Message- > >From: James Mitchell [mailto:[EMAIL PROTECTED] > >Sent: Monday, March 24, 2003 11:18 AM > >To: Struts Users Mailing List > >Subject: Re: [OT] Estimating a Struts-based project > > > > >Did you factor in the time for writing/maintaining tests? > > I'm hurt that you even felt you had to ask! ;-) > > Yes. As far as is possible, I have people write unit tests for code (before > if possible) and we are in the process of selecting further testing tools > for good stuff like functional testing, load testing and performance > testing. > > Simon > > - > Simon P. Chappell [EMAIL PROTECTED] > Java Programming Specialist www.landsend.com > Lands' End, Inc. (608) 935-4526 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
W-H-A-A-T? I can't hear you. Can you speak up?! -Original Message- From: Chappell, Simon P [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2003 12:39 PM To: Struts Users Mailing List Subject: RE: [OT] Estimating a Struts-based project I usually triple them, but there's the damage to my hearing to take into account from listening to managers scream when they see my estimates. >-Original Message- >From: Mark Galbreath [mailto:[EMAIL PROTECTED] >Sent: Monday, March 24, 2003 11:31 AM >To: 'Struts Users Mailing List' >Subject: RE: [OT] Estimating a Struts-based project > > >Okay, now double your estimate and you have a starting figure. > >-Original Message- >From: Chappell, Simon P [mailto:[EMAIL PROTECTED] >Sent: Monday, March 24, 2003 12:21 PM >To: Struts Users Mailing List >Subject: RE: [OT] Estimating a Struts-based project > > > > >>-Original Message- >>From: James Mitchell [mailto:[EMAIL PROTECTED] >>Sent: Monday, March 24, 2003 11:18 AM >>To: Struts Users Mailing List >>Subject: Re: [OT] Estimating a Struts-based project > > > >>Did you factor in the time for writing/maintaining tests? > >I'm hurt that you even felt you had to ask! ;-) > >Yes. As far as is possible, I have people write unit tests for >code (before >if possible) and we are in the process of selecting further >testing tools >for good stuff like functional testing, load testing and performance >testing. > >Simon > >- >Simon P. Chappell [EMAIL PROTECTED] >Java Programming Specialist www.landsend.com >Lands' End, Inc. (608) 935-4526 > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
I usually triple them, but there's the damage to my hearing to take into account from listening to managers scream when they see my estimates. >-Original Message- >From: Mark Galbreath [mailto:[EMAIL PROTECTED] >Sent: Monday, March 24, 2003 11:31 AM >To: 'Struts Users Mailing List' >Subject: RE: [OT] Estimating a Struts-based project > > >Okay, now double your estimate and you have a starting figure. > >-Original Message- >From: Chappell, Simon P [mailto:[EMAIL PROTECTED] >Sent: Monday, March 24, 2003 12:21 PM >To: Struts Users Mailing List >Subject: RE: [OT] Estimating a Struts-based project > > > > >>-Original Message- >>From: James Mitchell [mailto:[EMAIL PROTECTED] >>Sent: Monday, March 24, 2003 11:18 AM >>To: Struts Users Mailing List >>Subject: Re: [OT] Estimating a Struts-based project > > > >>Did you factor in the time for writing/maintaining tests? > >I'm hurt that you even felt you had to ask! ;-) > >Yes. As far as is possible, I have people write unit tests for >code (before >if possible) and we are in the process of selecting further >testing tools >for good stuff like functional testing, load testing and performance >testing. > >Simon > >- >Simon P. Chappell [EMAIL PROTECTED] >Java Programming Specialist www.landsend.com >Lands' End, Inc. (608) 935-4526 > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > > > >- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
Okay, now double your estimate and you have a starting figure. -Original Message- From: Chappell, Simon P [mailto:[EMAIL PROTECTED] Sent: Monday, March 24, 2003 12:21 PM To: Struts Users Mailing List Subject: RE: [OT] Estimating a Struts-based project >-Original Message- >From: James Mitchell [mailto:[EMAIL PROTECTED] >Sent: Monday, March 24, 2003 11:18 AM >To: Struts Users Mailing List >Subject: Re: [OT] Estimating a Struts-based project >Did you factor in the time for writing/maintaining tests? I'm hurt that you even felt you had to ask! ;-) Yes. As far as is possible, I have people write unit tests for code (before if possible) and we are in the process of selecting further testing tools for good stuff like functional testing, load testing and performance testing. Simon - Simon P. Chappell [EMAIL PROTECTED] Java Programming Specialist www.landsend.com Lands' End, Inc. (608) 935-4526 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] Estimating a Struts-based project
>-Original Message- >From: James Mitchell [mailto:[EMAIL PROTECTED] >Sent: Monday, March 24, 2003 11:18 AM >To: Struts Users Mailing List >Subject: Re: [OT] Estimating a Struts-based project >Did you factor in the time for writing/maintaining tests? I'm hurt that you even felt you had to ask! ;-) Yes. As far as is possible, I have people write unit tests for code (before if possible) and we are in the process of selecting further testing tools for good stuff like functional testing, load testing and performance testing. Simon - Simon P. Chappell [EMAIL PROTECTED] Java Programming Specialist www.landsend.com Lands' End, Inc. (608) 935-4526 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [OT] Estimating a Struts-based project
On Mon, 2003-03-24 at 12:14, Chappell, Simon P wrote: > I have just completed an initial estimate for a Struts-based web application. I am > curious as to what estimation methods folks out there use for their initial > estimates. The revised estimate will be delivered after more analysis is performed. > > I am fed up with making wild guesses for initial estimates and wondered if there was > any way to take the small amount of information available up front (i.e. the number > of screens on the user's initial workflow requirements document) and extrapolate it > into an estimate. I understand that the margin of error is gonna be big and hairy on > this puppy, but it's an initial estimate created with a dearth of information, so > what do you expect? :-) > > What I did was: > > Take the estimated number of application screens: s=13 > Take the number of application user roles: r=3 > Figure which screens are used by which roles and total: sr=32 > Estimate the number of actions: a = sr * 2 = 64 > Application units of work: auow = a + sr = 96 > Total units of work (including admin screens): tuow = auow * 2 = 192 > Estimate an effort factor per unit: ef = 4hr > Programmer work: pw = tuow * ef = 768hrs > > Some assumptions included in these calculations include: > 1. An average of two actions per screen role. > 2. The administration facility of an application is about 50% of the work. > 3. The effort factor is a figure arrived at from knowledge of the programmer being > tasked and the number of new technologies within the project. > > Your thoughts please. Did you factor in the time for writing/maintaining tests? > > Simon > > - > Simon P. Chappell [EMAIL PROTECTED] > Java Programming Specialist www.landsend.com > Lands' End, Inc. (608) 935-4526 > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- James Mitchell Software Developer/Struts Evangelist http://www.open-tools.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
