worthless story card estimates - agile and beyond 5-6-2016

@MikeKvintus

Worthless Story Card EstimatesMike Kvintus

@MikeKvintus@MikeKvintus

Iteration Manager at LeanDog

http://www.leandog.com/holiday/

Bio


I have nearly 20 years of experience using agile methods to develop software in numerous industries

Bio


Bio

I’m passionate about finding better ways to develop/deliver software and remove waste from software delivery processes


Bio

I’m also an active member of the software development community


Most Importantly

I’ve been collecting data on various ways of tracking the progress of projects and running experiments with estimation


Why I’m Here

I heard about and researched #NoEstimates and was intrigued

But I had a few questions

❏ Is story card estimation really waste?❏ Can projects really work by counting cards instead of using points?❏ I can see how #NoEstimates works for special cases but could it work

for our projects?❏ Are story card estimates really worthless?


Agenda

❏ Agile Estimation Overview❏ Pitfalls of Estimation❏ Review The Collected Data❏ Observations From The Data❏ Experiments and Outcomes❏ Other Considerations❏ Where To Go Next


We need estimates to provide predictability to our teams, customers, and other stakeholders!


Overview of #NoEstimates

❏ Some of the most vocal proponents are Neil Killick, Woody Zuill, Vasco Duarte, and others

❏ #NoEstimates - http://neilkillick.com/category/noestimates/❏ noestimates.org❏ Started as a movement to address the pitfalls and fallacies of estimation❏ The Common Ground of #Estimates and #NoEstimates❏ Two common practices: counting story cards and working on the most

valuable things

http://neilkillick.com/category/noestimates/


Overview of Agile Estimation

1. Identify story cards2. Break work down into bite size stories3. 3 amigos/fab five discussion of the stories

a. Planning poker, etc to estimate work

@MikeKvintus

Seems Simple


Estimation Is Good Right?

❏ Planning fallacy - optimism bias❏ Halo effect❏ Overconfidence❏ We don’t account for the unknown❏ And many more


Even If You Could Estimate Perfectly..

There are still many things that will affect a plan:

You don’t know everything!

People are not machines!

@MikeKvintus

But There Are Good Ways to Estimate


People Have Solved Estimation Problems

Lots of books and software to fix this problem, we just need to use them


People Have Solved Estimation Problems

Track projects and use history to predict future projects


But

Building software is not like building bridges

People inherently are not good at estimation

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law


And Studies Still Show

We don’t know

❏ How to Accurately Estimate the Effort of Mega - large, Complicated Software Projects

❏ How to Measure Software Size and Complexity for Accurate Estimation❏ How to Measure and Predict Productivity

@MikeKvintus

OK, What Else Could Go Wrong?


Estimation Abuse

Work expands to fill the time allocated


Estimation Abuse

Estimates are padded in an attempt to CYA


Estimation Abuse

You finished story X faster than your estimate


Estimation Abuse

It took you much longer to complete a story


I Thought A Lot About These Issues


And Then I Joined LeanDog Studio


We use continuous integration and continuous delivery

LeanDog Studio


We use information radiators to make the data visible to all

LeanDog Studio


LeanDog Studio

LeanDog Studio collects and tracks data on all the projects we execute


LeanDog Studio

❏ Our projects are quite varied in industry domain, tech stack, company type (large corporations to small startups), and size while also having different team members

❏ I wondered if the points on story cards really mattered or could we just count the number of cards


Original LeanDog Studio Project Radiator


LeanDog Studio Project Radiator


Graphs/Data

❏ I compared points vs cards from 2 perspectives❏ Backlog - The amount of work identified to be done❏ Burnup - The amount of work done

❏ I also compared tracking the count of only feature cards vs tracking the count of feature, bug, and chore cards

❏ Comparison of 9 different projects that varied in❏ Team members/sizes❏ Project sizes, types and duration❏ Industry domain and tech stacks

@MikeKvintus

(Backlog)


Graphs/Data

@MikeKvintus

(Completed Work)


Observations From The Data

❏ Counting cards can be a viable replacement for using story points for well defined work in our environment

❏ This works both to track progress and backlog size


But I realized..

Even though the projects were widely varied, there were some consistencies:

❏ The teams were made of highly talented/experienced people❏ Projects follow common practices, including breaking story cards

down into relatively small sizes

Thus YMMV


So We Decided To Experiment

❏ Several new projects starting setting the story card to 1 point after the card was broken down


What Did We Learn?

❏ It works for us and we’ll keep doing it, but…❏ We did need to explain the rationale behind setting all sizes to 1❏ Some developers don’t want to give up their point sizes❏ Some client developers refuse to give up their point sizes❏ In a weekly retro: “Our velocity looks bad because the story cards are only

1 point”❏ Most people love not setting sizes


Experiment Outcomes

❏ The projects were successful❏ We maintained the visibility and predictability our clients needed❏ Kept our practices in check


So Are Story Card Estimates Worthless?

❏ For us, gaining a common understanding of the work through discussion is the true value of story card estimation sessions, not the points that are assigned to a story

❏ Assigning points doesn’t take any substantial additional time, so “waste” is minimal

❏ But for our projects, the story card estimates are worthless!


What Else Do We Need To Consider

❏ Forecasting into the future❏ Can use card sizes❏ Use backlog growth to estimate future work

❏ Bugs/chores


Is Stopping All Estimation the Right Answer?

❏ Doesn’t give you any insight into the future beyond work you’ve broken down into story smallish cards

❏ #NoEstimates acknowledges this


Estimates Give The Illusion Of Predictability

❏ We know estimates are flawed❏ How about we look for other ways to satisfy

the predictability needs of teams, customers, and other stakeholders


We need estimates to provide predictability to our teams, customers, and other stakeholders!


❏ Team instability❏ Big bang releases❏ Bad coding practices❏ Too much WIP❏ Lack of collaboration❏ Lack of transparency and visibility❏ And many more..

What Affects Predictability


How About Focusing On Improving Predictability

❏ Team stability❏ Frequent releases❏ Focus on good coding practices (TDD, Pair Programming,

ATDD)❏ Limit WIP❏ Improve collaboration❏ Improve transparency and visibility


❏ Not all organizations are comfortable not having “estimates” despite the known fallacies❏ Requires you to sell predictability without estimates

❏ You may have to❏ Give in and use estimates❏ Or Walk away

❏ There are times when estimates are appropriate❏ It's reasonable to question why❏ Be clear they are estimates and not commitments


❏ Look at data about your projects❏ Experiment❏ Find out what works for your team

Where To Go Next


Thank You!

Please provide feedback at http://sched.org/ or feel free to talk to me!

@MikeKvintus

https://www.linkedin.com/in/mikekvintus

[email protected]

http://sched.org/

