Estimating is NOT planning

Estimating is NOT planningDhaval Panchal

Hofstadters law: It always takes longer than you expect, even when you take into account Hofstadters law

2 things are certain about estimatingYou will always be WRONG.You will spend more time estimating, that you could have used to do the work instead.

*Agile* Estimating does not exist!

EstimateGUESSEmpirically derived intelligent GUESSGUESSEmpirically derived, consensus based intelligent

If estimates were accurate we would call them FACTS

Expert Judgement BasedStatistical Analysis BasedExpressed as a RangeExpressed in Probabilities or Percentile ConfidenceGuesses on Known-Knowns and Tolerance for Known-Unknowns

What you know you knowWhat you know you dont knowWhat you dont know, you dont know

I dont know

Author (A) - Brad says: beware of copyright infringement. Dont print or distribute this image in any way.Diminishing ReturnsWhen people are asked to think in detail about how they plan to finish a task, there is an ever greater tendency to underestimate its duration

-Beuhler & Griffin, 2003

AccuracyEffort Spent Estimating

100%

the confidence estimators have in their own estimates is unjustifiably high

- Jrgensen, M., Teigen, K. J., and Mlokken-stvold, K. Better sure than safe? Overconfidence in judgement based software development effort prediction intervals. The Journal of Systems and Software, 70, (2004)

Anchors

When asked to make decision under uncertainty we (humans) grasp at any information offered (the anchor). Further adjustments to arrive at the decision (eg: estimate) are made with reference to this anchor and these adjustments are unable to compensate for negative effects of the anchor.

Anchors operate unintentionally and work even when people are forewarned. Its just . a button

Anchoring and Adjustment in Software Estimation: Aranda & Easterbrook (2005)

Im a Lead, Im better than them

Therefore estimate for lower size

The lead will obviously work on this story

my estimate does not matterI will go with the team .. (lead)

Competence

Your estimate for the work clearly implicates youEstimate is often treated as a reflection of persons ability. People frequently under-estimate to impress.See: The social implications of planning: How public predictions bias future plans : Stephanie P. Pezzoa. Mark V. Pezzob, and Eric R. Stone : Journal of Experimental Social Psychology, 2006

Avoid Irrelevant and Misleading InformationGoldilocks User StoryAs a Goldilocks User Story CardI want to have written on me - Not too little, and not too much, but just rightSo that my author speaks - for not too little, and for not too long, but just enoughHow to Avoid Impact from Irrelevant and Misleading Information when Estimating Software Development Effort : Jrgensen and Grimstad 2008

Temporal DistanceCase 1: Three months from today, you have to write your name on a white index card with blue fountain pen.Estimate: ______ ?Abstract plan that was decontextualized.(find pen, find index card, write name, done!)

Biases estimates to be optimisticIncreased specificity of task, that is contextualized. Thinking in terms of impediments.

(Do I have a blue ink pen?, Where is my white index card?)Case 2: Right now!! you have to write your name on a white index card with blue fountain pen.Estimate: ______ ?

Bye, Bye, Big Upfront Estimating!It is un-safe (intended) to make plans based on estimates of backlog items that are not going to be worked on until further into future (> 2 months)

shorter releases or as Scrum says always be potentially shippable at end of every sprint. Easier said than done!, I know

Dont have large number of backlog items in your product backlog.

Dont blindly believe in the magic of Fibonacci sequence.

But my management wants long term predictions - they have no business being in management

An Ellipse is more similar to a circle THAN a circle is to Ellipse

Myth: research shows people are better at relative than absolute estimation

http://guide.agilealliance.org/guide/relative.html

Relative Size EstimationDirectional Bias- You are likely to get different result if you switch your target story for estimation with reference story for comparison.

Assimilation Effect: Is a 8 point User Story, 8 times more .. than a 1 point User story ?- Remedy: Create a reference story set of 2 or 3 User Stories for each size in your set and refresh your references every few sprints.Sequence Reference Bias : Your previous estimate of task/story acts as implicit reference for the next story/task you estimate.- Relative Estimation of Software Development Effort: It Matters With What and How You Compare : Jrgensen (2013)

Even if they are aware that they did not finish the task when planned, their memory of how long it took to complete the task itself might still be an underestimation of the actual durationRoy and Chesterfield and McKenzie, 2005 : Underestimating the duration of future events - Memory incorrectly used or Memory bias?

benefittime

estimate

expected or accepted tolerance zone

Time spent to estimateCost to estimate

Start Work

Anchoring EffectAwareness of Estimate has pinching effect - Eroding benefits from outcomes when work is completed outside of tolerance zone.

With what you know now, would you still go back and Ask for estimates?

"Teams first struggle with estimation, then get quite good at it, then reach a point where they don't need it - @martinfowler

Expectations from PlanningExposes RiskReduces UncertaintyBetterS decision makingConveys informationReveals OptionsImproves Coordination

Story Points : ApplicabilityFully Cross-Functional TeamsIdea to Delivery can be achieved by a single teamIn Scaled environments: Feature TeamsAll of the above implies that teams have DevOps capability or healthy processes and practices with Operations teams. With of course no manual testing hand-offs.

Story Points are not comparative between teams. (Apple points and Orange points)

Remember

Story points between teams cannot be added to project on overall release.

Analysis

Design & dev

Testing

Ops and Release Ready

Front-End

Middle Tier

Integration tierBack-end

Definition of DoneEnd-to-End Functionality

Potentially Shippable Product Increment5385

21 Story Points

5385

21 Story Points/Sprint

110 Story Points

~ 5-6 Sprints

Alternatively Count Stories/Sprint3-5 Stories/Sprint => 20 stories in 6-4 sprints

Shift from Story Points to Story CountingAgreement on priority of item in product backlogAgreement on acceptance criteriaConversation about User StoriesStrong Definition of Done.Use yesterdays weather techniqueAgreement on priority of item in product backlogAgreement on acceptance criteriaConversation about User StoriesStrong Definition of Done.Use yesterdays weather techniquePlanning poker to arrive at consensus on estimate and ONLY splitting stories when greater than ___ (13) pointsSplit all stories. A sprint has atleast 4-5 User Stories that have discreet business value.

But But.. IN the Real World!

Weak Definition of DoneDefinition of Done < Potentially Shippable Product IncrementExamplesDevelopment team defers many aspects of quality to later sprintsDevelopment Team relies on an Manual QA team for full regression test pass.Business Analysts teams works ahead of Development and Test TeamsBusiness receives functionality from scrum team that is UATed before release to end-user.

Serialization of backlogsNew Items from PO

Product BacklogDelivery Team

Un-tested ProductTestingTeam

Defects/Bugs detected

Potentially ShippableProduct Increment

Backlog Items Remaining Development TeamBacklog Items Remaining Testing TeamSerialization of backlogs

Every Source of Delay between Development and Test whiplashes the final GO-LIVE date.

Development

TestDelay

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

- Principles Behind Agile Manifesto

The most powerful way to reduce variability in forecasts is to shorten our planning horizons- Donald G. Reinertsen: The Principles of Product Development FLOW

Gathering Empirical DataHow many Stories can we develop if we must be shippable at least every two months?Destabilizing Stories (N)

Stabilizing Stories (?)example: 20 stories require 15 stories worth stabilizationImprove planning For Future Releases

Dependencies

2 Laws of Dependency ManagementDo not create dependencies.If you must, then schedule dependent work ONLY with knowledge of dependent service teams PULL schedule and expected cycle time.

But But.. IN the Real World!

Go Look at does not work!How is the project doing?Do you have capacity to take this on?What is the status of Feature/Initiative?Will I get Feature X?When will I get Feature X?

Go look at online toolEasier to answer for single X-functional teamsBlob of many interdependent teams

Team Level MetricsImpediments from daily scrumVelocity (#of Story Points or # of Stories)Cost $$ of funding a sprintetc. etc.ALM Tool?Program LevelTeam Level MetricsTeam Level MetricsTeam Level MetricsTeam Level Metrics

Team Level MetricsImpediments from daily scrumVelocity (#of Story Points or # of Stories)Cost $$ of funding a sprintetc. etc.ALM ToolTeam Level MetricsProgram LevelInter-Connection of dependent teamsSystem throughput capacity Cycle time @ Feature/Epic levelTeam Level MetricsTeam Level MetricsTeam Level MetricsHow many active dependencies can system handle?How many dependencies can a team handle?

Team ATeam BTeam CEpic 1Epic 2Epic 3

Most at Risk EpicMost involved teamDependency BoardI Can see big pictureFirst Order Information

Dependency Board PurposeTo determine if features are being developed too late or too early.To see which features are related to each other so as to make trade-off decisionsTo identify unknown and duplicate work.To identify at-risk features.To allow teams to pick up right work.

Dependency Board PurposeTo determine if features are being developed too late or too early.To see which features are related to each other so as to make trade-off decisionsTo identify unknown and duplicate work.To identify at-risk features.To allow teams to pick up right work.

Epic 3

Team A

Team B

Cycle Time

DelayDelays in resolving dependencies contribute the most to project delivery timeline.

StartShippable

Program Cumulative Flow Diagram (CFD): Queue Sizes

time# of Epics

Epics ShippableCumulative # of EpicsWIPSecond Order Information

Program Cumulative Flow Diagram (CFD) : Time

time# of Epics

Cycle Time

delayTeam B Velocity Team A Velocity

Second Order Information

Epic 3

Team A

Team B

Cycle Time

DelayStartShippableOptimize interconnected team system to reduce this.

Actively Manage delay caused by DependenciesPrioritize Epics at program level. Work in prioritized order.Stop starting, start finishingActively monitor dependency queuesCreate Kanban slots to constrain # of Dependent items for a service team.

Where there is delay there are backlog items

Dependencies Waiting to be resolvedbacklog

Wait Time OR DelayQueue size is leading indicatorThroughput is Lagging Indicator

Controlling Queue Size directly controls cycle timeLittles Law: Average Cycle Time = (Average number of Items in Queue) / (Average Processing Rate)Do not let Dependencies to accumulate.Set Explicit Kanban limits on Dependencies between teams.

CTeam B has Two (fixed) Kanban Slots for Servicing external dependenciesTeam ATeam BKanban Dependency SlotsLets work on these two storiesLook. team B has only one of the two dependency slots open. So we should not create more dependenciesAnd PULL only our highest priority story that requires dependent workWe can now focus on finishing dependent workWe can predict that one more dependent item will be added soonAnd we are always working on high priority for teams.

SummaryAt best, Estimates are educated guessesStory Points are no better than simply counting stories per sprintFor a cross-functional team that produces potentially shippable code every sprint, Velocity is a good forecasting measure.In all other (real-world) cases, focus on getting to shippable state. You will discover that planning is emergent and estimating not necessary any more.Increase action on dependencies by creating team level dependency Kanban limit.To forecast: your Queue (backlog) Size is leading indicator of challenges ahead.End-to-End measurements of Cycle Time are better for forecasting on programs with dependent teams. Team level velocities do not account for wait period in between backlogs

Q&A