Presented at GDG MAD in July 2020.
Pratul Kalia@PRXTL • OBVIOUS.INSIMPLIFYINGSOFTWARE ESTIMATION
View Slide
SOFTWARE ESTIMATIONSTEVE MCCONNELL2006, MICROSOFT PRESS
WHAT IS AN ESTIMATE?
LET’S DRIVE FROM ONE END OF THE CITY TO ANOTHER!“How much time will ittake to finish all thesethings?”
Estimates alwayshave a probability.
Targets are notestimates!
THE TRAIN LEAVES AT 4.40 PM!“Here are a bunch ofthings we have to getdone by X”
Are you chasing atarget or an estimate?
PRESSURE& BAD ESTIMATES
— ALL ENGINEERS“Okay, that is a bit ofwork but I’m sure I cando it in 3 days.”
Stop putting yourselfin unreasonablesituations.
There are no prizesfor getting there fast!
— PARKINSON’S LAW“Work will expand to fillall available time.”
(that is…if teams have lots of extra time,more work will magically getcreated.)
— GOLDRATT’S STUDENT SYNDROME“Given lots of time,students will delaystudying until the lastpossible moment”
Underestimation is worse thanOverestimation!Stastically reduced chanceof on-time completion.
Engineers are toooptimistic already.
OTHER SIDE EFFECTS…Poor technical foundation,worse in the long run.
OTHER SIDE EFFECTS…Unproductive,emotionally drainingbehaviours.
OTHER SIDE EFFECTS…- more status meetings!- frequent re-estimation!- interim releases!
OTHER SIDE EFFECTS…- meetings to cut scope!- fix bugs arising from hacks!
THE CONE OFUNCERTAINTY
“As the projectprogresses, estimatesbecome moreaccurate.”
(yes that’s quite ,isn’t it.)
It is easily possible todo worse… but notbetter.
The Cone does notnarrow itself.
Stop doingfirst-number-in-your-headestimates!It sets the wrongexpectation!
⏱
Even a 15-minuteestimate isexponentially betterthan an instant one.
INCLUDE EVERYTHING.Some requirements arestated.Others are implied.
INCLUDE EVERYTHING.Deployment setupMaintaining build scriptsCode reviews
INCLUDE EVERYTHING…Writing documentationOnboarding new teammembers
INCLUDE EVERYTHING!Creating test dataUpgrading dependencies
FACTORS THATINFLUENCE ESTIMATES
Size of the software!The biggest contributor toproject effort and schedule.
As size increases, effortgoes up exponentially.Exponentially. Not linearly.
Programmer capability.Time constraints.Team continuity.Required reliability.
COCOMO-2 softwareestimation model.
IMPROVINGYOUR ESTIMATES
I hope you use storypoints of some type.
STORY POINTS.Mark of complexityThey don’t (necessarily)represent time!
STORY POINTS.(for e.g.A team using 1/2/3 pointsfor a project.)
STORY POINTS.A junior engineer takes5 days to finish a 3-pointtask.
STORY POINTS.A senior engineer takes2 days to finish a 3-pointtask.
The time taken isdifferent.But the complexity issimilar!
NOT COMPLEX…Create a “lint step” on theCI server
NOT COMPLEX…Add “patient has alreadyvisited” option toOverdue list
COMPLEX?Allow Blood Pressuremeasurements to bedeleted
The Lawof Large Numbers
“If you create one BigEstimate, your error(s) willeither be completely on thehigh side, or the low side”
“but if you create multipleSmall Estimates, somewill be on high side,some on the low side.”
“… so the errors willcancel each other out,to some extent.”
ALSO COMPLEXSync Protocol Drugsacross all facilities anddisplay in the app
Some tricks!
TRICKS!Do a detailed taskbreakdown: spend sometime!
TRICKS!Think of the “worst case”while estimating.
TRICKS!Compare different storiesof similar complexity.
TRICKS!Use a projectmanagement tool thatunderstands “velocity”.
TRICKS!Engineers should breakdown tasks and estimatethem.
TRICKS!Look at past data for yourteam, for similar type ofwork.
TRICKS!Measure yourselfprivately
NEGOTIATIONS& AGREEMENTS
An estimate is aconversation, and anegotiation.
Engineers “own” theestimate… butManagement “owns” thetarget.
The goal of estimation isNOT pinpoint accuracy!
People want tounderstand VALUE incomparison to EFFORT.
Do t-shirt-sizing withall stakeholders.
VALUE EFFORTA: S MB: M SC: S LD: XL M
Separate people from theproblem.
Focus on interests, not onpositions.
Come up with optionsthat benefit everyone.
Either everyone wins,or everyone loses.
GO FORTHAND ESTIMATE!