DO YOU WANT TO DELIVER ALL YOUR PROJECTS ON TIME? • •
•
Are you losing money because you deliver projects late? Are you frustrated and depressed at the “on-time” delivery rate of your projects? Do you want to avoid burn-out and make your projects reach the mythical “sustainable pace”?
With the #NoEstimates practices we focus on understanding REAL progress in a project. Not the progress against an estimate, which only tells you if you are already late or not. But the kind of progress information that tells you WAY IN ADVANCE if you will be late. Are you confused by Monte Carlo simulations? Me too! They are overly complicated to do right, and in the end you don’t have the luxury of running the same project twice or even a 1000 times! You need to deliver THIS project on time! Here’s the thing, in this book I explain how to know (a long time in advance) how to know if you are going to be late. But the key part of the process is what you do once you know that! Here’s a deal. I’m offering you a free one hour call to review your current project, and devise a strategy to deliver it on time, no matter what the current situation is!
The call is free, and you will get a very good idea on how to “reign in” any project, and delivery on time. Best case? I’ve helped my customers save millions by delivering projects on time, and I believe I can do the same for you. But you will see it, first-hand, in our call. If you are not convinced, no worries! You don’t need to pay.
Worst case? You spent one hour asking questions and understanding better progress in your project, which will help you make the right decisions. Schedule Your 1h Call With Me Right Now And (Potentially) Save Thousands Or Hundreds Of Thousands In Late Projects . PLUS: help your projects reach that sustainable pace, that ensures you will be able to continue to deliver projects in the future without burn-outs and loss of talent!
Schedule your call at the http://bit.ly/schedule_a_call_with_vasco
following
link:
NO ESTIMATES HOW TO MEASURE PROJECT PROGRESS WITHOUT ESTIMATING
VASCO DUARTE
NO ESTIMATES Copyright © 2015 by Vasco Duarte. All rights reserved. This book or any portion thereof may not be reproduced or used in any manner whatsoever without the express written permission of the publisher except for the use of brief quotations in a book review. Publisher: Oikosofy Series, www.oikosofyseries.com Illustrations by Ángel Medinilla Cover design by Sebastian Hermida
.
Welcome to the #NoEstimates book. Join the conversation on twitter under the #NoEstimates hashtag. This book is part of a larger project that includes video interviews with some of the early adopters of the ideas described in this book. Sign-up at www.NoEstimatesBook.com/print_gift to get an exclusive essay on Capacity Planning with #NoEstimates. Visit oikosofyseries.com/noestimates-book-order to find the following extra material: Two mini e-books on contracts and planning ! !
The Ultimate Guide to Capacity Planning with NoEstimates by Tomas Rybing How Much Does it Cost?: A Guide to Agile Contracts by Evan Leybourn
The #NoEstimates Pioneers on Video: ! ! !
Woody Zuill, the creator of the #NoEstimates hash tag on twitter Neil Killick, the creator of the Slicing Heuristic, a great way to reach #NoEstimates quickly Henri Karhatsu, greatly experienced #NoEstimates practitioner with many stories to share
Four video interviews with #NoEstimates practitioners ! ! ! !
Chris Chapman, inventor of the #NoEstimates game Clinton Keith, game developer using #NoEstimates in his projects Marcus Hammarberg, author of Kanban in Action Allan Kelly, author and #NoProjects movement founder
Two interviews with CEO’s applying #NoEstimates ! !
Sven Ditz, CEO of Sitegeist.de in Germany Diego Cenzano, CEO of biko2 in Spain Visit oikosofyseries.com/noestimates-book-order to know more
WHAT OTHERS ARE SAYING ABOUT NOESTIMATES, THE BOOK “The way this book was written helped me not only to understand the main ideas behind #NoEstimates but to internalize the concept with the real examples behind the story.” – Hermes Ojeda Ruiz, LogicalBricks “Finally! The most meaningful text book about project management and governance! This piece of project fiction will become the real “don’t panic” guide to project management!” – Tapio Järvenpää, Beer Executive Officer, Hops United OÜ "Anyone interested in deliver their projects on time should read this book. It´ll make you forget the idea that you can predict the future with a crystal ball. Instead of that you´ll learn to use your data and be more effective. Take of red pill!" – Emiliano Sutil, Project Manager al Xeridia S.L “You’re doing it wrong. Estimates that is, and #NoEstimates tells you why. Most importantly, however, the book tells you what you should be doing instead. The compelling mix of theory with story means you’ll quickly learn the lessons and start benefiting from the book. Read, think and apply #NoEstimates today." – Dr. Bruce Shcarlau, Senior Teaching Fellow at University of Aberdeen “I was sold on this book after reading the table of contents of the first chapter.” – Nick Mein, Engineering Manager, Trimble Navigation. “Do the most important thing is not a startup thing only! In my 15 years of experience with software development I've seen a lot of patterns of projects failing. I've experienced myself every example described in #NoEstimates. I've worked for a startup, where it is obvious what's important without estimating. With the help of the #NoEstimates book I can do the same within a multinational corporate organization.” – Jeroen Knoops, Software Developer
CONTENTS !"#$%"#& ((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( )* +,$ -."$/+012+$/ 3#$10/$ (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( 4) +,$ 3#"56$1 %0+, $/+012+$/ ((((((((((((((((((((((((((((((((((((((((((((((((((((((( 47
"# $%&'()&$% *#+,- ........................................................................... /0 *12 "#34& $%&'()&$% *#+,- ............................................................... 55 1#6%&)"&$+4% 7)* ................................................................................ 55 8)+,'3%#34% 7)* .................................................................................. 59 )::'"$3&)7 :#(87':)&'#3 ..................................................................... 59 (#+$ &1)3 ($$&% &1$ $2$; *12 $%&'()&$% )+$ ):&'<$72 1)+(6=7 6#+ 2#=+ 8+#>$:& ....................................................................................... 5? $3&)3@7$"; 1#* :#(87$A'&2 "$%&+#2% 8+$"':&)B'7'&2 ........................... 50 :1)3@$ +$C=$%&%D :1)3@$ $<$+2&1'3@.................................................. 9/ )77 #+ 3#&1'3@; "$)&1 ()+:1 8+#>$:&% ............................................... 99 '% &1$+$ 1#8$ 6#+ %#6&*)+$ 8+#>$:&%- ................................................. 9E %,2+ 2#$ $/+012+$/8((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( 9:
F3#$%&'()&$% )% F3#'3<$3&#+'$% ........................................................ G5 $%&'()&'3@ <%. 6#+$:)%&'3@ .................................................................. GG &1$ '+#3 &+')3@7$ ................................................................................ G? &1$ %&)+& #6 ) 8+#>$:& '% &1$ *#+%& &'($ &# $%&'()&$ '&% "=+)&'#3 #+ :#%& .................................................................................................... EH =3:$+&)'3&2 )3" B=66$+% ..................................................................... E/ :7)%%': ($&1#"% 6#+ :+)6&'3@ $%&'()&$% ............................................. EG $%&'()&'3@ '3 &1$ )@'7$ *#+7" ............................................................ E0 #$+,0.;0.< $/+012+$/ (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( 7*
&1$ I)77$@$"J 3$$" 6#+ $%&'()&$%; "$)"7'3$%D :#%&% )3" %:#8$ ............ ?G *12 "# *$ 3$$" $%&'()&$%- ............................................................... ?? 8+#>$:& "+'<$3 "$<$7#8($3& ............................................................... K/ %$&LB)%$" "$%'@3 <%. 8#'3&LB)%$" "$%'@3 ............................................. KG <)+')B'7'&2 ........................................................................................... K? $%&'()&'#3 <%. 8+'#+'&'M)&'#3 ............................................................... 0/ %#N +$&1'3,'3@ $%&'()&$% ................................................................... 0E
&1$ 8+$"':&)B'7'&2 8)+)"#A .................................................................. 0? ,"% ."$/+012+$/ =2. ,$63 >"? 12.2<$ 2 3#"@$=+ 0. =#0/0/ )AA
<'%'B7$ 8+#@+$%% ................................................................................ HOG ):&'#3)B7$ '36#+()&'#3 .................................................................... HHO *1)& )+$ '3"$8$3"$3& %&#+'$%- ......................................................... HHH +,$ !2/+ +#2=; +" ."$/+012+$/ ((((((((((((((((((((((((((((((((((((((((((((((((( )4A
%7':'3@ =%$+ %&#+'$% &# )%%$%% 8+#@+$%% )3" ()3)@$ %:#8$ ............... H/G #&1$+ %7':'3@ 1$=+'%&':% .................................................................... H5H "$&$+('3'3@ 8+#@+$%% 6+#( 1'%&#+':)7 ")&) ..................................... H5G (=7&'87$ 7$<$7% #6 @+)3=7)+'&2 ......................................................... H5? 1#* "# ' ()3")&$ &1$ %'M$ #6 ) 6$)&=+$ #+ ) =%$+ %&#+2- ................. H5K *12 %1#=7" ' ()3")&$ &1$ %'M$ #6 ) =%$+ %&#+2 #+ 6$)&=+$- ............. H9O $A&+)8#7)&'3@ 6+#( =%$+ %&#+2 &# #<$+)77 8+#>$:& 8+#@+$%% ........... H9H HL/L5; %&$8 B2 %&$8 &#*)+"% F3#$%&'()&$% ........................................ H9G +,$ !0#/+ /+$3 +" &$60B$# 2 3#"@$=+ ". +01$ 0/ +" #$="<.0C$ +,2+ %$ 2#$ 62+$ (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( )*A
1#* &# +$:#<$+ 6+#( ) 7)&$ 8+#>$:&- ............................................... HG5 67$A'B7$ +$C='+$($3&% ()3)@$($3& 6#+ ()A'(=( %:#8$ <'%'B'7'&2 .... HG? :+$)&'3@ #8&'#3% B2 %7':'3@ 6$)&=+$%................................................. HE9 1#* &# :#((=3':)&$ 8+#@+$%%- ...................................................... HEG <20. +,$ =?/+"1$#/ +#?/+ %0+, #"660.< %2B$ !"#$=2/+0.< )D:
&1$ 3$<$+L$3"'3@ 8##7 #6 '"$)% ........................................................ HE0 +$8#+&'3@ 8+#@+$%% *'&1 3#$%&'()&$% .............................................. H?O +#77'3@ *)<$ 6#+$:)%&'3@ )77#*% 2#= &# )")8& 2#=+ 87)3%D :#3%&)3&72 ........................................................................................ H?G 8+$%$3&'3@ &1$ +#77'3@ *)<$ 6#+$:)%& &# ) :7'$3& ............................ H?K 2=;."%6$&<$1$.+/(((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((( ):9
FOREWORD "Transformation comes more from pursuing profound questions than seeking practical answers." Peter Block I’m pretty good at getting comfortable in my ways. Perhaps we all are. Still, I'm certain this is not a good thing so I work hard to keep an open mind about making things better. I suspect that our biggest problems are hidden within the things we trust the most. A few years back I noticed there are a number of practices and techniques used in the management of software development done "by default". That is, we do them without question. Perhaps we assume that this must be the "right way" since everyone does it this way. Maybe it's how we were trained for our job, or that we've been doing it so long we don't even remember why we started. It could be it is a practice someone has documented in a textbook, or we learned through some training sessions at a conference on "how to manage software development." The problem for me isn't whether the practice is good or not, but rather that many often accept it as the only way and don't question its applicability. Simply following a practice or methodology by default indicates to me that there are likely some hidden problems we might not be willing to uncover. Are we being willfully ignorant, or are we unaware that we are missing something here? When the feeling of control and certainty is more important to us than knowing the truth, and the fear of change holds us back from seeking better, it's time to do some questioning. It's time to face our fears. "Humans are allergic to change. They love to say, 'We've always done it this way.' I try to fight that." - Adm. Grace Hopper Although I love that quote from Admiral Hopper, I'm not so sure that humans are allergic to change. I actually think we are pretty good at it, and in some things we welcome change once we get the idea that change is needed. Estimates are one of those things where "we've always done it this way", and there is little scrutiny of the use of estimates. When estimates don't seem to be serving us as we wish they would, the natural or common approach is to simply try to get better at estimates. As business people (and as humans), we need to have confidence in the methods we
use - "getting better" is a less than meaningful approach unless we have sufficient faith in the thing we need to get better at. And even still, we must keep a close watch on whether things are getting better overall, and not just the estimates themselves. So naturally, I want to dig a bit deeper. Estimates themselves are not bad, and in some situations they can be very helpful. However, estimates are often part of an unquestioned process of managing software development, so I want to learn more. When I become aware of a situation like we have with estimation I want to question, explore, and validate (or invalidate) the practice or method. Is it suitable for the purpose to which it is put? To accomplish this, I start by asking questions of myself. I want to find the "profound questions" that will lead to a better understanding. I have a number of questions I've posed to myself about estimates. Here are a few examples of the sort I find useful to ponder as a starting point: "If I found estimates are not informing the decisions they are meant to inform, what would I change about the way I use them?" "If I found estimates are not useful for a purpose, in what way could that be the fault of the estimates themselves? In what way is that an issue with the purpose?" "In what way would getting better at estimates help if the estimates themselves are of questionable use?" "What ways can we meaningfully validate decisions we've made based on estimates?" "If we believe that getting better at estimates is our only choice, what are the possible pitfalls?" "If the decisions that we currently think are important are not as important as we think they are, what should we do?"
Early October, 2012: I had just met Neil Killick in Twitter, and read a blog post of his named "Should We Estimate Software Projects… At All?" After a few Tweets back and forth, Neil introduced me to Vasco Duarte. I believe that the first blog post from Vasco that I read on this topic was "A better way to predict project release date!" What a great starting place. Alone, I had my suspicions about estimates, but with others such as Neil and Vasco also questioning the practices of estimation and use of estimates I was encouraged that some real progress can be made. So now there were three: Neil, Vasco, and myself. Little did I know how much I would learn from my on-going conversations with these two. Even more wonderful was that new folks were joining the conversation daily. One notable luminary is Ron Jeffries who has now written extensively on the topic, and over time many others such as Allen Holub and Kent Beck have shared their ideas on the topic. But I'm jumping ahead. I noticed an interesting thing very early on: While we were all questioning the "de facto" use of estimates in managing software development, we had different ideas about what the core problems might be, and what to do about them. I took this as a good sign. I seek a broad spectrum of ideas, especially at the beginning. We were all noticing that something was amiss. If the use of estimates and estimation are suspect, I'm more interested in learning all about that than what to do about it. The "how" reveals itself when we understand the "why" about the "what." This is where the power of pursuing profound questions comes into play for me. The "how" of estimates is a moot point if they are not serving us well. It's of little value to solve a problem we don't yet understand; we are just a likely to be addressing a symptom rather than the underlying problem. Let's get that settled first, and then explore the alternatives. Getting better at estimates (which the entire industry has been trying to do for a long time) doesn't help if the underlying motivation for using them is not valid. Rather than jump to the possible solution of getting better at estimates, I want to do whatever it takes to understand the underlying reasoning and purpose of the estimates. That is an area worth exploring.
Along the way it became apparent to me that some decisions we make when managing software development efforts are probably not the right decisions to be making. Why do we feel that knowing the cost of something "up front" is useful? Is that really important, or simply just something we've convinced ourselves that we can't do without? Why is it that we think we have "limited funds" for software development? If we are good at generating income from the work we do, are these limits even meaningful at all? What if there are alternative models that lessen or eliminate the need for knowing the cost? Consider that it might be better to become great at creating software, and delivering it into actual, meaningful use early and often, and earning a return almost immediately. Would knowing the cost be as important if we can start re-cooping whatever costs there are almost immediately? Maybe by following this model the desire and interest in estimates will simply fades away. Maybe not. Let's find out. Estimates are used in many ways, and there are seemingly countless methods of estimation for devising those estimates. What if we could forecast some aspects of our project without estimates at all? This is something I find interesting, and it's a possible game-changer. Vasco has been exploring one such alternative that is of particular interest to me, and he covers it nicely in this book. His ideas about forecasting based on the data collected in the doing of a project eliminate the need for certain estimates for that project, and the results are easily verified. If we find that forecasts are helpful, what if we could find a way to forecast without estimates that works at least as well as estimating does? What if it is actually better? And easier? How would that change our dependence on estimates? How would that change our regard of estimates? Should we at least experiment with ideas like this? What if we could try this and prove it for ourselves while still working in the same way we always have? Powerful stuff. I'm glad you are reading this book, and exploring along with Vasco. While this is still a very new effort, many people are gathering around these ideas and questions, and exploring for themselves the method that Vasco shares in the #NoEstimatesBook. Business people, Managers, "Customers", Developers, Analysts, and just about anyone will find this book useful.
We all see a need for better, and insist that regardless how well entrenched the "way things are" might be, it's time for a change. And we welcome it. Woody Zuill #NoEstimates Pioneer, and Software Industry veteran www.MobProgramming.org, http://zuill.us/WoodyZuill/
THE #NOESTIMATES PREMISE If you have been around Agile and Lean for some time you might be familiar with the Japanese-born concept of “no inventories”. Between the sixties and the eighties, Japanese companies – Toyota being one of the most prominent examples – embraced a new paradigm of production founded on the premise of maximizing value for the customer and seeking continuous improvement. In order to maximize value, all activities and investment that were not directly adding value to the customer were labeled as “waste”. In this sense, moving materials from one place to another is waste; reworking, overworking or overproduction are waste; fixing defects is, of course, waste; and unfinished materials waiting in a queue to be used (inventories) are waste. The golden rule to determine if something in your organization falls in the category of waste is: “do we want to have more of this? Like double or triple it?” Companies seldom want to ask this question. If you ask it too much, you’ll find that Managers are waste - you don’t want more of them. Meetings are waste. Code is waste. But, if mostly everything around us is labeled as waste, shall we get rid of it? The answer, of course, is no. The premise is that you want to have as little waste as possible, and not more. Once you reach the state of minimum waste, you should try to go even further and reduce it a little bit more – continuous continuo us improvement improve ment or Kaizen. K aizen. Of course, you don’t want to double or triple your inventories. Inventories are a hidden bank account, money lying around doing nothing but deteriorate. Even worse, it requires investment in the form of space, maintenance, rotating stocks, security… You even lose inventory pieces due to aging, bad storage or warehouse mismanagement misman agement.. You have to maintain stock records and reconcile inventory periodically – and if you’ve ever done something similar, you know how soul crushing this process can c an be. So what’s the only reason we keep inventories? Organizational dysfunction, or so believed the Japanese companies. People need inventories so they have access to materials between resupplies. These resupplies were separated by several hours, sometimes days. Each resupply needed to be huge so workers would have materials until the next resupply. Huge resupply needed space, storage, management, rotation, movement… Waste everywhere. The Japanese breakthrough was to imagine a company where
resupplies were happening constantly, Just In Time. By imagining how work would look like in a world with no waste, they could forge new production paradigms paradigm s like one-piece-flow, one-piece -flow, single-minute-ex single-m inute-exchange-ofchange-ofdie, zero-defects or total-quality. Of course, you could be picky and observe that each worker on a Lean factory might have a small inventory of pieces around, maybe a handful, maybe a dozen. You could then claim “Look! Look! That’s inventory! It is not actually true that they work with #NoInventories!” The point is that these Lean factories have been able to reduce the resupply period from days to minutes, and their stock, inventory or storage needs from stadium-sized warehouses to drawers. So, #NoEstimates… It is obvious to me that estimates do not provide more value to the customer than inventories. People who find value on estimates are just addicted to a practice (estimation) to get something they find valuable: plans, comfort, uncertainty uncertai nty reduction, reduction , financial financia l projections, projecti ons, sales proposals… But, again, these are not customer custome r value. Applying the golden question, you don’t want to triple plans, estimates, reports and proposals. Hence, you want as few as possible – not less, but not more. So they immediately fall under the label of waste. Of course, you will always find someone that defends that inventories are in fact customer value, the argument being that inventories protect the customer against accidents and company dysfunctions. No serious Lean discussion can be forged around this argument nowadays. Interestingly enough, when it comes to reducing the need and dependency on estimations, people can be quite belligerent – you just have to wander around the twitter conversations around #NoEstimates to get a taste of it. I imagine that, in the early days of Lean, when Womack and Jones were just starting to spread the news about this crazy Japanese production system, several people would be as baffled as some are nowadays with the #NoEstimates movement. I can clearly imagine western managers protesting, “just in time production? Resupplies every few minutes? Are you CRAZY? Why are you trying to debunk the proven practice practic e of accumulating accumul ating inventories? inventori es? What are you, smarter smarte r than th an all of us, than all managers that have been promoting stocks and inventories for the last four-plus millennia?” Ah, human beings… ‘gotta love ‘em. I have faith and patience. When some people in the Agile community started talking about zero defects or continuous delivery, more than a few voices rose against such concepts stigmatizing them as ‘delusional’ and ‘misleading’. Even the ideas behind the manifesto, which are
enthusiastically defended nowadays, were difficult to promote mostly everywhere just ten years ago. I feel there’s a natural learning curve towards #NoEstimates. It is common nowadays to hear from teams that moved from WorkBreakdown-Structure (WBS) like estimation – estimating each and every task, then adding up all estimates – to story estimates, point-based estimates, t-shirt sizes and counting stories and finally dropped the estimation-based conversations to focus on throughput, cadence and flow. I did my first public talk on #NoEstimates at Agile Lean Europe Berlin 2011. Many well-known European Agilists were in attendance, and I could metaphorically hear the sound of their neurons crashing into each other while I presented the idea of reducing the estimation effort and focus on stabilizing the team throughput and using past information to drive forecasts. People rapidly organized an Open Space around the topic, and the usual question was “yeah, but… You need estimates, right?” Not a question, in fact, more of a desperate cry in the middle of a withdrawal syndrome. My answer was direct – no, you don’t need estimates. You are using estimates to produce some other stuff, so the question is, can we produce that other stuff in a better way that using estimates? Unfortunately, several people still ask for better ways to estimate. It is a flawed question. For me, it is like asking for better ways to win the lottery, or better ways to guess what team is going to win a sports match. But I have faith in the capacity of human beings to change, and patience to watch that change happen. A year ago I decided I wanted to push this change a little further and I asked my good friend Vasco Duarte if he was up to the job of writing a first book on #NoEstimates. Vasco had enthusiastically defended this approach based on his own experience. A few months after my talk at ALE2011, he presented a similar topic at OOP2012, and have been very active on the #NoEstimates debate since the very start. We started this work together, but I had to quit after some months – my job engagements and workload were keeping me behind the intended pace, and I was basically basical ly endangering endangeri ng the project. To be honest, we also had “creative differences”, as artists say, and decided to “pursue our own careers and personal projects”. No problem. We are still good friends, and I kept illustrating Vasco’s work - sort of – and providing my feedback and insights. We still collaborate on some other projects, and I’m sure we’ll keep finding opportunities to promote innovation on the Agile world. My final word to you, reader of this book, would be to remember the
fact that mind is like a parachute, it only works when it is properly open. Too many people have lost the track of the #NoEstimates premise to dig into inane details. For instance, some people would say “oh, but you are forecasting results based on past information – isn’t that an estimate?” Or maybe “oh, but you are breaking big stories into small, one-or-two day sized stories, but in order to do that, won’t you need to estimate the story size?” Remember that #NoEstimates is not about no estimation ever, but about the minimum amount of estimates that will do, and then look carefully at ways to reduce that need even more. In that sense, I love J. B. Rainsberger concept of #MehEstimates, like in “Oh, estimates… Meh!... Yeah, I guess we’re doing some, we are just not very concerned or serious about them.” So, here’s to life, the #NoEstimates book. Enjoy. Ángel Medinilla Agile Coach, #NoEstimates practitioner, Book illustrator http://www.proyectalis.com/
CHAPTER 1
THE PROBLEM WITH ESTIMATES Carmen came into the office bright and early in the morning. She was surprised when her boss unexpectedly called her into his office. Any other day he would greet her; invite her into the break room for coffee; have a friendly one-on-one chat with her, and talk about life… But not this time. This time her boss looked nervous. He made sure the door was closed the door before saying a word. Carmen appreciates her boss because she has learned a lot from him. But his behavior made her feel nervous. What could her boss possibly want that required them to meet behind closed doors? What could be so secretive that it couldn’t be overheard by anyone else in the office? “Carmen, we have a big project coming in. This is potentially the largest software project our company has ever won.” “A big project you say?” Carmen’s interest grew. “It’s about time they consider me for a big project” she thought. “Yes! This project alone could finally make us profitable! And I want you on it. I trust you and appreciate your work greatly. I know you can pull it off…”
Do Estimates Work?
Carmen was surprised. She had heard of a new, secret client project that they called Big Fish, but she did not expect to be assigned to this project. After all, she still had the Telemark project going on. Carmen shifted in her chair and tried to think of something to say. Something didn’t feel right. “Well… That’s a surprise. I still have the Telemark project, which will be landing soon. I thought you wanted me to finish that before moving on to other projects…” “I did, but his came up suddenly.” Carmen’s boss interrupted, “I only just heard about it yesterday. Our CEO was able to find a way for us to bid on this project. It will be huge!” “Errr, Okay. What should I know about this project before I take this assignment?” Carmen was unsure about this. Her boss seemed almost too eager for her to say yes. “Well… Basically nothing. It’s just another software project. The only difference is that this project is bigger than the others you’ve worked on.” “How much bigger are we talking about?” Carmen asked. “Well…” She felt uncomfortable. Her boss wasn’t being upfront with her. “Is it twice as big as the Telemark project?” She asked, but her boss didn’t reply. “Five times bigger?” Still no comment. “Ten times bigger?”
The Problem with Estimates
“Actually, it is a public sector project, so I guess you could say that it’s several orders of magnitude bigger than your Telemark project….” He finally admitted. “Oh…” Carmen was speechless. This could potentially be the largest software project in the country, and she was being lined up to manage it. “And we’ll need to present a bid by the end of next week!” Her boss looked excited. “So get your team on it. We need to close this deal now Carmen; it could change our company’s future! We need to submit our proposal as soon as possible!”
Do Estimates Work? If you were Carmen, you’d probably feel nervous too! I know I would. Estimating a software project is never an easy task, and the situation gets even worse when you have to do it without first understanding the context or the requirements well enough. Add that to the pressure to create a winning bid, and you have an explosive mix! And not in a good way.
Do Estimates Work?
When I talk about #NoEstimates I get the most serious questions from people like Carmen. Questions such as, “How can I win a bid if I don’t estimate?”, or “My customers will not award me the contract unless I give them an estimate!” Fair questions, but before we tackle them, let’s tackle the real question here. A key question for both you and Carmen is “ Do estimates work?” Some researchers have already proposed what a “good” estimate should be. In 1986 1, they proposed that a good estimation approach would provide estimates “within 25% of the actual result, 75% of the time”. What this means is that, for all the projects you estimate, you should complete those projects within 25% of the original estimate for 75% of the time. Another way to put this is that you don’t have to always be within 25% of your estimate, but that you should be for 75% of all of your projects. Let’s examine the track record in the IT industry to see if we’re consistently able to estimate correctly. First we look at the Chaos report, a study that is run every few years to assess the “success” of software projects worldwide:
Figure 1 – Project success rate over the many CHAOS report surveys from 1994 to 2004. Graph adapted from Steve McConnell's book, Software Estimation: Demystifying the black art
1 Steve McConnell, Software Estimation: Demystifying the Black Art
The Problem with Estimates
This picture looks grim. If Carmen works for an “average” company her chances of success are slim, about 25% if you believe in the accuracy of the Chaos report. Not good. You can improve your chance of success by using certain software development practices like Agile, but even then the success rate is a poor 42%2. But let’s look at this from another angle. Even if you agree that being within 25% of the original estimate is a good result, what about the outliers? The tasks and projects that exceed the original estimates by so much that they run the chance of jeopardizing the entire project or portfolio? You may think that your projects don’t include such tasks. …Bad news…
Figure 2 - Project estimates vs. Actuals (in days), track record for one organization. Graph adapted from Steve McConnell's book: Software Estimation, Demystifying the Black Art.
2 CHAOS report for 2011-2012 shows 42% successful agile projects.
Do Estimates Work?
Look at the project on the top-left of the chart. That project was estimated to last 7 days, but ended up taking more than 250 days to complete. This is a difference of 1 week to nearly 9 months! While this is only one outlier, the potential impact on the company is tremendous. A project like this can drive a company bankrupt. There are several examples in our industry that look like this. In a famous UK contract walk out, Accenture avoided up to £1bn in penalties3 in a contract with the National Health Service (NHS) in the UK. Some will argue that this is an extreme case, an outlier. But do you want to bet your company on one project if the possible result is obliteration? I don’t think so! Beyond the problem with outliers, let’s look at examples of sustained performance. Here’s the project delay (in % from original estimate) for 17 different projects from one single company spanning a period of 4 years.
Figure 3 Percentage delay to estimates at approval, and estimates at requirements completed phase for one organization. Adapted from data collected by me in one company between 2001 and 2003 for 17 different projects. 3 Accenture avoids £1bn penalty for walking out of a contract with the NHS http://www.theregister.co.uk/2006/09/29/accenture_nhs_penalty/
The Problem with Estimates
This company had an average (yes, average) delay of 62% for their projects. This means, for every project that should have lasted 3 months, it lasted nearly 5 months! As I look at the graph above I can’t help but ask: “Can we really trust estimates as a reliable tool to manage our companies?” Would you bet your entire company on a work-method (estimates) that delivers 60% to 80% of the projects late or over budget? This is the question that Carmen had to ask herself in the scenario above. Can she, in all honesty, risk her company’s future on a method that has that large a failure rate?
Why Don’t Estimates Work? “Carmen, I want you to know that you have my full trust. I know that you can pull this project off.” “Thank you sir, that means a lot to me.” Carmen said, while thinking: “and I may need to call on that trust. Hopefully you are not bluffing.” Estimates don’t really work. Specifically, not in the way the software industry practices estimation. And not in the way that many, including in the Agile community, propose estimates should be done. There are three clear, intuitive, and proven reasons as to why that is so.
Hofstadter’s Law Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law. Douglas Hofstadter 4 Douglas Hofstadter observed that, no matter how much work went into developing computer programs to play chess against Grand Masters, the winning program always seemed to be 10 years away. Even though Hofstadter was referring to chess programs, this observation was picked up by several other writers, such as Brooks in The Mythical Man-Month and Beck in Extreme Programming Explained , as a way to highlight just how difficult it is to estimate programming, or other software development related tasks. However, Hofstadter’s Law is only one of several explanations for the continued failure to correctly estimate software development work. 4 Gödel, Escher, Bach: An Eternal Golden Braid. 20th anniversary ed., 1999, p. 152. ISBN 0-465-02656-7.
Parkinson’s Law
Parkinson’s Law Work expands so as to fill the time available for its completion. Parkinson’s Law Parkinson observed that bureaucracies seemed to expand and therefore create more work for themselves. He was commenting on the British colonial bureaucracy, but the rule was picked up later by Alessandro Natta in Italy and Mikhail Gorbachev in the Soviet Union who famously stated that “Parkinson’s Law works everywhere5”. Indeed, it works everywhere; even in software development environments where the modern formulation of Parkinson’s Law is “work always expands so as to fill all the time available for its completion”. Another way to put it is: “If you wait until the last minute to complete a task, it only takes a minute”... Or does it? Parkinson’s Law is a description of the phenomenon that work will consistently expand to use all the time allocated to it. In other words, projects that get delayed, rarely catch-up. This, in turn means that if you have one task that is delayed, you should consider all subsequent and dependent tasks to take at least the time they were allocated, meaning that they will end after the originally scheduled time. Therefore, having one task late can potentially derail the whole project. How about that for a shot in the dark?
Accidental Complication Another reason why estimation is so hard goes by the name of accidental complication. J.B. Rainsberger introduced this concept at Oredev 20136. The gist of the argument is this: every feature or functionality added to an existing project has two cost elements (what you’ll want to estimate): •
Essential complication or g(e): How hard a problem is on its own. For example, implementing tax handling is hard, because the tax code is complex in itself. That is what J.B. Rainsberger calls essential complication or g(e).
5 O'Sullivan, John (June 2008). "Margaret Thatcher: A Legacy of Freedom". Imprimis (Hillsdale College) 37 (6): 6. 6 Watch the full video here (duration ~8 min): http://vimeo.com/79106557.
The Problem with Estimates
Accidental complication or h(a): The complication that creeps into to the work because – as J.B. Rainsberger puts it – “we suck at our jobs”. Or more diplomatically, the complication that comes from our organizational structures (how long does it take to get the approval for a new test environment?) and from how programs are written (no one is perfect, therefore some things need to be changed to accommodate the new functionality). The cost of a feature is a function of both essential complication and accidental complication: •
cost of feature = f(g(e), h(a)) In software, estimates of cost are often done by analogy. If features A and B are similar, then if feature A took 3 weeks, feature B will take 3 weeks. But then J.B. Rainsberger asks: “When was the last time that you worked on a perfect code base, where the cost of the accidental complication (how messy the code base was) was either zero or the same multiple of g(e) as when you implemented feature A?” He concludes that often the cost of accidental complication – dealing with organizational and technical issues specific to that code, and that organization – dominates (yes, dominates!) the cost of a feature. So, if h(a) is much larger than g(e) the cost of a feature cannot be determined by relative estimation. In turn, this means that the most common estimation approach, Story Point estimation, cannot work reliably. What this means for you is: you can only determine the real cost of a feature by recognizing and measuring accidental complication, or – like I suggest in this book – by using the #NoEstimates approach.
Accidental Complication
As Troy Magennis 7shared with me in an email conversation: When we ask someone to estimate how long it will take to develop a feature or project they think about how long it would take hands-on, with perfect hand-off between teams and other staff with the specialist skillsets. This never happens. Work sits in queues; people work on more than one project at a time; people take vacations. We estimate the work, when we need to estimate how long that work takes to go through a complex system given all of its foibles. Systems thinkers like Goldratt, Reinertsen, and Deming understood this well. Work spends considerable more time idle and blocked by system constraints than progressing towards completion. Given that for inventive knowledge work the handson time through a system is considered exceptional at 30%, even if we were PERFECT at estimating that 30% of the time, we would be off by a factor of 70% without compensating. Even the commonly used doubling what you are told method would still be 20% low. The delays involved in a complex system are unknowable in advance. Just like travelling to work along the same highway each day, you can't know there is going to be an accident blocking all lanes three weeks from now, you can't know that the test environment will “catch fire” three months from now blocking all testing work. It's these unknowable system delays that make forecasting software projects exceptionally difficult. The only way to estimate and forecasting a system is by estimating the system impacts and the easiest way to do that is by observing prior history of work flowing through that system. #NoEstimates is a strategy that considers the system on its own terms, allowing some ability to predict completion times in advance. What Troy refers to is a critical insight: work flows through a system. Without understanding how that system works through metrics like cycle-time, lead-time, etc., the best we can do is estimate a “perfect” 7 Troy Magennis writes about software projects in his blog: http://focusedobjective.com/news/
The Problem with Estimates
engineering day. You and I both know how many of those “perfect” engineering days we’ve enjoyed in our lives. Not many.
More Than Meets the Eye: Why Estimates Are Actively Harmful for Your Project “Carmen, one more thing,” her boss said as she was about to leave the office. “Yes?” “We have a lot riding on this project. It is important that we give them the right estimate for this project!” Carmen did not fully understand the meaning of this statement. “What does right estimate mean? Why would it be important to have the right estimate instead of whatever else he thinks I may give? Does he want to set me up?” Carmen’s thoughts nearly spiraled out of control. She decided to keep them quiet for now, and answered: “of course!”
I would not like to be in Carmen’s shoes. What should she do? The average person would first find out what the right estimate for the project was, and then deliver that. And at first they would be hailed as heroes. But, what if the right estimate at the time of the project bid is actually the wrong estimate in the end?
More Than Meets the Eye: Why Estimates Are Actively Harmful for Your Project
Deming8 was quoted as saying that “if you give a manager a target he will do anything to meet that target, even if he has to destroy the company in the process”. This is why targets are so important, but at the same time so dangerous. Carmen will probably go to her team, do the best job she can, knowing full well that the goal is not to give the customer a realistic expectation of how much time and money is needed to complete the project, but rather that she is responsible for winning a contract – no matter what it takes. Wanting to meet the target is a very strong pattern in organizations. So much so that at the end of every quarter we see a frenzy of meetings and busy people trying to meet that quarterly target, be it sales or operations. Estimates are no different and help make projects prisoners of the targets they set. And this is one reason why estimates can transform from useless but harmless, to influential and harmful targets. Look at what happened at Enron in 2001 9 where the “compensation and performance management system [that] was designed to retain and reward its most valuable employees, [...] contributed to a dysfunctional corporate culture that became obsessed with short-term earnings to maximize bonuses.” But there are more reasons and tempting shortcuts that make estimates actively harmful in certain situations. Below are 4 situations that are possible because of the use of estimates in software development: Internal politics become a problem when deadlines are set because top management wants something done by a certain date, with fixed scope and fixed resources. Despite advice to the contrary, in these cases the HIPPO (Highest Paid Person’s Opinion) overrules any potentially “good” estimate created by the team. Estimate bargaining occurs when a team has created the estimate and defined a possible release date, and then they suffer pressure from stakeholders to change their estimates. Symptoms of this dysfunction include calls for “more efficiency”, or “more commitment”, generally followed by phrases such as “we are all •
•
8 W. Edwards Deming, American writer, author and coach that helped propel Japan to the most productive nation status with his work after the Second World War. 9 For details on the Enron scandal, visit http://en.wikipedia.org/wiki/Enron_scandal
The Problem with Estimates
in this together”. Blame shifting happens when people outside the project team estimate the work (e.g. experts), and then the project team members are blamed for not meeting those estimates. Late changes are a form of Estimate bargaining, whereby changes are added to the project, but the schedule is not allowed to change for whatever reason. These are only some of the possible dysfunctions associated with estimates. This list is an illustration of how estimates can be used and abused for purposes other than actually understanding the project and the work that needs to be completed. •
•
Entangled: How Complexity Destroys Predictability The biggest conundrum of all however, is how to deal with complexity. How complex dependencies in software projects hide the really big risks. Software projects present challenges that are unique to the software development domain. Unfortunately, many in the software industry still fail to recognize this. I often hear that “a good software project must, like a house, start on strong foundations of good architecture and good requirements”. My usual answer is: “sure, if you consider that you can start by building a tent, then evolve it into a hut, then increment it into a trailer, and later on deliver a castle, then yes, you could say that building software is the same as building a house.” Clearly, software is far more flexible and susceptible to evolution than a house. And that leads to creating a Complex 10 environment where simple A causes B causality links are not always possible to determine. Software does not follow simple causality links. Rather, it follows complex causality links. A complex link is, for example, when a small change (like a single line) can cause a catastrophic failure. Take Apple’s famous “goto fail” debacle11, where one simple line of code completely 10 For the remainder of the book we will use the term ”complex” to define an environment where the relationship between cause and effect can only be perceived in retrospect, but not in advance. This definition comes from the Cynefin model (https://en.wikipedia.org/wiki/Cynefin) developed and popularized by Dave Snowden. 11 For more details on the Apple Goto Fail details, visit: http://www.digitopoly.org/2014/02/26/apples-goto-fail-is-pretty-interesting-and-worthreading-about/ Read also Uncle Bob’s take on the “sensitivity problem” that software development suffers from: http://butunclebob.com/ArticleS.UncleBob.TheSensitivityProblem
Entangled: How Complexity Destroys Predictability
destroyed all the hard work to keep their product safe. No matter how strong the foundations of Apple's products were, this single line addition was enough to completely destroy that foundation. How about that for a house project? Apple’s example above illustrates one additional property of software systems: non-linear causality, i.e. when a small change can have very large impact. When it comes to estimates, and estimation in general you have to be aware that no matter how thorough you are at estimating the work you must complete, it is unlikely you will uncover all the small problems with disproportionally large impacts. And there’s a very good reason for that: we wrongly perceive these examples of extreme non-linear causality to be rare12. We perceived to be so rare we usually call them outliers. The problem is: in software, an outlier may completely destroy all the effort that went into creating credible, solid estimates. Does this mean that we cannot estimate? No. But it does mean that our estimates are built on quicksand, no matter how strong we think the foundations are. Don’t believe me? Check out this collection of quotes that emphasize how unstable the ground underneath estimates is.
Berard’s Law13 Walking on water and developing software against a written specification is easy if both are frozen. Humphrey’s Law The user of the software won’t know what she wants until she sees the software. Ziv’s Law Requirements will never be completely understood. Wegner’s Lemma An interactive system can never be fully specified nor can it ever be fully tested
12 In Black Swan, Taleb describes how often we ignore extreme conditions because we don’t consider the nature of systems we analyze. He describes 2 types of systems: ”mediocristan” where linear causality rules; and ”extremistan” where non-linear causality is prevalent. He then explains how we tend to classify the systems we study in ”mediocristan” because we don’t consider the potential for non-linear effects which should drive us to classify those systems as ”extremistan” systems. 13 From: http://en.wikiquote.org/wiki/Edward_V._Berard
The Problem with Estimates
Langdon’s Lemma Software evolves more rapidly as it approaches chaotic regions. Medinilla’s Law for Software Contracts The 80 000 lines of code won’t fit into a 20-page contract. Do you have some more quotes to share? Send them over, I would like to collect them. Email me at
[email protected]
Quotes about late changes in projects • •
•
Thank you Andres Lundsgård for the following quotes. “A late change in requirements is a competitive advantage.” Mary Poppendieck “The only thing certain in life is change.” Anonymous
Change Requests, Change Everything
Change Requests, Change Everything
And then there were changes. You have been there before. You work hard to try and plan a project to the best of your knowledge. The team starts to get the hang of the project and is able to deliver some software, only to see the changes start flowing in. First they flow in at a trickle, one by one. But later on, as the testing progresses, changes come in like an avalanche.
The Problem with Estimates
Figure 4 Number of cumulative open defects and the daily rate for closed and submitted defects during a project. Includes indication of development and testing phases. This is an illustration based on data collected during the lifecycle of a project where I worked as project manager.
Hopefully you have some margin (aka buffer) in your project. Right? Sure, but how much of a margin is margin enough? According to the definition of a good estimate cited earlier in this chapter, you should count on at least a 25% margin - assuming the estimation was “good” to begin with. Are you safe if you add a 25% margin to your project? The answer is no. And if you believe it helps, just re-read Hofstadter’s Law again. In software development, changes have (sometimes very large) side effects. As you discover problems you find that the consequences of those problems go beyond what some call “bugs”, you discover blind spots: complete sets of functionality that require rewriting; or new functionality that was missing. As a friend once described to me: “building software is like when you try to unclog the pipes in your bathroom and end up having to build three more houses just to get the toilet working again”. Can you predict all the significant changes you will get, and the impact of those changes? If you answer yes please send me your CV. But you will probably answer “no”, just like many people do when asked the
All or Nothing: Death March Projects
same question. The bottom line is that estimation is a very poor method to predict the future, and change requests only amplify that problem.
All or Nothing: Death March Projects Estimations can become a life or death game for teams and companies alike. But nowhere is the effect of bad estimation more visible than in the statistics of mental health problems in overworked and overstressed IT industry folk 14. The idea of the death-march project15 can be summarized like this: you estimate that you need five days to cross a desert, so you pick five water containers, one for each marching day, and you start walking. But, at the end of day five, you are out of water and you are still in the middle of the desert. What can you do? You cannot go back, as you know that it will mean five days walking through the desert and you don’t have any water for that. All you can do is keep walking until you either find more water, reach your destination, or die.
14 Article on the incidence of burn out and stress related illnesses in IT http://www.netsecurity.org/secworld.php?id=14666 15 The idea of death-march projects was made popular by Edward Yourdon in his popular book Death March: The Complete Software Developer's Guide to Surviving 'Mission Impossible' Projects http://www.amazon.com/dp/0130146595/
The Problem with Estimates
In a similar way, some projects follow an “all or nothing” strategy. This strategy borrowed from poker means that a team either delivers everything (“all”) or the project has no value (“nothing”). In this context, the estimation process becomes a battleground between the teams and the customers for that project. The teams want to survive at the end, and the customers want the certainty they will get everything they want – and when they want it. At the end of the estimation process the project will start, and the people trapped in that project can easily fall into a death-march mentality. They battle everyday to get the project on track, but a combination of estimation problems with constant change requests transform that project into a constant struggle. You work every day to the best of your ability and deliver concrete work. But instead of feeling confident and enjoying the progress, you feel like Sisyphus16 : pushing a boulder up a hill that will invariably slide down, again and again. Making you - and the team - feel that there is no hope. A death-march project is caused by the all or nothing mentality and a utopian faith in estimation. 16 The myth of Sisyphus: http://en.wikipedia.org/wiki/Sisyphus
Is There Hope for Software Projects?
Is There Hope for Software Projects? If it is so hard to estimate software work, can you predict when a particular project will end? Yes, you can. And that is the right question. Instead of asking how long the project will take, ask instead: “given the rate of progress so far, and the amount of work still left, when will the project end?” Or, a similar question: “Given the rate of progress, how much of the work can be finalized by date X?” These are much more powerful questions. Here’s why: These questions don’t assume an all or nothing mentality because, for example, you can remove work from what is left. These questions don’t assume that it is possible to predict the future. Instead to answer them, you can use data about past progress and constantly update your answer to the questions. To answer these questions, you can use available data that the project team has already collected (aka actuals) in the form of “rate of progress”, instead of having to guess at future events without considering the current rate of progress. In this book we will cover how Carmen will answer the question “when will X be done?” using something other than estimates in Story Points or hours. We will also cover the main challenges that come from the traditional approach to project estimation, and how to avoid, or reduce the impact of those challenges. But before exploring how a #NoEstimates practitioner would predict an end date for a project or how much work can be done by any given date, let’s review some of what the software industry today considers “best practice” methods for software estimation. This review will be essential for us to clarify the stark contrast between Estimates and #NoEstimates.
CHAPTER 2
WHAT ARE ESTIMATES? “The right estimation for this project.” The boss’ words were still on Carmen’s mind as she walked down the hallway to her desk. This was not Carmen’s first project, but until now she had managed to give fair estimates on her projects because they were small and somehow similar. Take this system we already installed here, then install it there. Create a customized copy of that other system for a new client. But this was a different kind of beast. New technologies, new client, new domain, new product. Until now, Carmen had just looked at how long things took in the past, then added some contingency buffer that could be accepted by the client. So far, so good. Of course, she also knew that keeping estimates ‘good’ during the project involved a strong management of the project. She was known to be very kind and empathic with clients, but 110% uncompromising when it came to scope creep and project changes. “Carmen delivers.” That was the usual comment of managers when they talked about her, and she liked it. Now, her reputation had put her in a tight spot. For the Big Fish project there was no useful historic information she could rely on, and still she was asked to give ‘the right estimate.’ Anyway, what was the ‘right’ estimate, or the ‘wrong’ estimate? Was this a game of guessing? Carmen sat silently for some minutes trying to assimilate it all. One thing she knew: once she would cast a number, an estimate, it wouldn’t matter if it was ‘right’ or ‘wrong’. That number would instantly become known as ‘the plan’ and for the following months she would be measured against it. But on the other hand, if that number was ‘too large’ the company might lose the contract and she would be held accountable. Carmen opened a drawer and pulled her old project management books in search of something she hoped would help her find the ‘right estimate’. If she failed to produce the right estimate, at least she wanted to have the opportunity to say “hey, I did it by the book! Literally!” It might seem like an obvious question. Everyone involved in some kind of project-oriented environment will have much experience using,
WHAT ARE ESTIMATES?
producing or asking for estimates. Because of that experience, most people tend to form paradigms, models and pre-conceived ideas about estimates. In order to fully understand the #NoEstimates principles, let’s contrast them with the inherent meaning of the term estimates. What are estimates and what are they not? The Merriam-Webster Dictionary provides a good starting point, defining ‘Estimate’ (transitive verb) as ‘to give or form a general idea about the value, size or cost of something ’. From this, we can deduce that estimates are ideas. Sometimes those ideas are vague, and other times they are very precise or accurate, but they are ideas nonetheless. Hence, estimates are guesses, not facts.
Every single time you provide an estimate, you are basically saying “I don’t know”. If you were 100% sure of what something is going to take in terms of time, resources or effort, then you wouldn’t be estimating you would be providing concrete facts. This is not the case with estimates. When you estimate, you rely on task description, past experience and other available information to form a general idea and provide what feels likely to be a reasonable number.
Is There Hope for Software Projects?
This number usually takes the form of a precise quantity, like in ten days or five thousand dollars. As soon as the human mind understands this number, it will likely tend to stick to it and give it the category of a fact, in an interesting form of grasping and clinging. As an interesting piece of trivia, Buddhists believe that grasping, wanting and clinging are the source of suffering – but that is a topic for a whole other book. Every estimate has an undetermined amount of uncertainty included. When you estimate ten days you would better be saying “roughly ten days on average; it could be eight days if we’re lucky, and it shouldn’t be more than thirteen days unless all hell breaks loose.” Hence, every estimate is also a probability cloud17.
Figure 5 - Probability distribution for meeting a specific estimate. Note how the cumulative probability (area of the curve) of being late is much higer than the cumulative property of being earlier.
Another important fact to understand about estimates is that, once you place an estimate on something and there’s someone interested in that something – for example: your client – the clock usually starts ticking and will not stop. It’s Monday, you are asked for an estimate, you say “four days”, and your client automatically starts to expect something 17 Probability cloud is used figuratively in this context to help the reader visualize an estimate as a fuzzy construct, just like the position of an electron around the nucleus of an atom. We know the region, but not the absolute position, and the position is constantly changing in time.
WHAT ARE ESTIMATES?
delivered by Thursday. But estimates are not commitments, nor are they a promise. Estimates will need to be carefully placed in a plan for them to make any sense at all. An estimate of three days depends on when we are be able to spend three days on the task. It also depends on many other facts like, for instance, if we will be able to focus on the task full time or we will need to split our attention between several projects. For now, we just need to make the difference between an estimate: “It will take three days”; and a commitment: “It will be done on Thursday.” Imagine that I provide an estimate of five days. Then, I show up early at work every day with my best smile, I do the best I can, I work harder and smarter than ever, I even stay a little bit later every day… And, after five days, the task is not done. Would you say that is my fault? Of course, it might be my fault that I provided a guess and I did not make clear to you that it was not a commitment or a given fact. Hence, many people tend to think “oh, what we need are better estimates; if we have good enough estimates, then all deadlines will be met”. Given that estimates are probability clouds, the statement above is like playing lottery and saying “oh, what we need is to choose the right number”, or investing in the stock market and saying “what we need is to invest in the right stocks.” Estimates in some very controlled and determined domains might come from a carefully developed mathematical model, and in this case all people involved will agree to these estimates because they agree on the model. In some other domains, people will observe the system, notice that there is a small variance or deviation from an average behavior and then use that behavior to forecast18 future outcomes – provided that there are no unknown changes to that behavior in the future. But for complex environments, where estimates come mostly from personal experience and knowledge, these estimates will be different for every person. Experts might estimate some work as easy and fast, while novices might estimate the same work as difficult and long lasting. Some team members may see risks and estimate the impact on the schedule, while others may ignore those risks. Hence, in most environments estimates are personal . Because estimates are ideas and they are personal, there are several psychological aspects that affect them. For instance, if you are bound by your estimate and you will be judged, even fired because of the outcome, 18 Editor’s note: Please notice the difference used here between forecast and estimate. This difference is further discussed later in the book.
Is There Hope for Software Projects?
you will tend to be more conservative. On the other hand, if winning a project or making a sale depends on your estimate, you might be tempted to make a more aggressive estimate. If you add uncertainty, missing information, unknown factors that will affect the project, personal and psychological aspects, what you have left is a very inaccurate number that will sometimes result in an overestimation19 and, most of the time, in an underestimation. The usual difference between the estimated duration of a task and the actual duration of that task varies greatly depending on many factors. Some authors draw a cone of uncertainty 20 with 60% variability at the beginning of the project, meaning that anything could happen between 0.4 times and 1.6 times the original estimate. In some cases, however, the difference between estimate and actual can be closer to 400%. This means that sometimes, the cost, time or size of the actual product ends up being four times bigger than the original estimate. Given the wide variation of between estimated and actual values, it is impossible not to cringe when some companies ask their people for estimates that are 10% accurate or 25% accurate. The only way to produce such accurate estimates, we have discovered, is to actually build the thing, then report the actual cost, size and duration as our 100% sure estimate. Another possible strategy to create the perfect estimate is to create a huge buffer for uncertainty. For example: estimating one month for something that shouldn’t take more than a week. Note, however that this approach will destroy your competitiveness: your direct competitors might be offering one or two weeks as estimates for the same work. And you shouldn’t forget Parkinson’s Law: once the one month estimate is approved, people will tend to use the whole month to add scope and functionality to the project – therefore increasing the risk of being late after all!
19 Overconfidence as a very common bias leading to underestimation of task duration: https://en.wikipedia.org/wiki/Overconfidence_effect Thanks to Pier Lorenzo Parachinni for the reference. 20 Cone of Uncertainty by Barry Boehm, as described by Laurent Bossavit in Leprechauns of Software Development: How folklore turns into facts and what to do about it, LeanPub, 2013. Note that Cone of Uncertainty idea has been discredited in the software industry by the work of Todd Little and Laurent Bossavit.
WHAT ARE ESTIMATES?
#NoEstimates as #NoInventories Estimates are seen as useful by many, but even those that want to continue to use estimates do not advocate that we spend as much time as possible estimating a project. This type of activities, where more is not necessarily better, is labeled as waste in Lean Manufacturing (Lean). Lean defines waste as any activities that don’t directly add value to the product from the client’s perspective. Companies that adopt Lean work to eliminate or reduce waste to a minimum. Inventories, for example – partially produced or fully produced products not being delivered and instead kept in the warehouses – are a well known example of waste in Lean Thinking. But meetings are also waste. Consider this: if we double the amount of meetings, we are probably not giving a proportional amount of more value to the client. Use this heuristic to label waste: anything that we don’t want to do more of in order to make our customer happier is waste. Some people say “oh, but meetings add value, and inventories are valuable in some situations” - and they might be right. But from a Lean perspective, you don’t want to have as many managers as possible, as many meetings as
#NoEstimates as #NoInventories
possible, as much inventory as possible. You want the bare minimum, and then you should try to figure out ways to operate with even less. You don’t want to spend double, three times or even five times more effort in estimates. You want to make as few estimates as possible. And, if possible at all, eliminate them. Hence, estimates are waste in the Lean mindset. This is the main premise behind #NoEstimates: estimates do not directly add value to your process, so we want to find ways to reduce the estimation process or even stop it where possible. #NoEstimates does not mean that there are no estimates at all, just like in Lean environments ‘zero inventories’ does not mean that there is no inventory at all. It is very usual in Lean factories to find small inventories of unfinished goods or pieces on every production cell, but compared to the old production paradigm these inventories have dropped close to zero. The same is true for #NoEstimates – do as few estimates as possible, ideally none. In an attempt to make this this concept even more clear, J.B. Rainsberger has suggested the hastag # MehEstimates as a possible alternative to #NoEstimates. However, the goal is clear: reduce estimation work to the minimum necessary, and then reduce it a bit more. Reduce it until you find it painful to work without those estimates, then adapt and reduce the use of estimates even more. For ideas on how to do this and be successful just keep reading.
WHAT ARE ESTIMATES?
Estimating vs. Forecasting Although these two words are used many times as if they are synonyms, they are significantly different. The Merriam Webster dictionary defines forecasting as “to calculate or predict (some future event or condition) usually as a result of study and analysis of available pertinent data ”. If you compare this with the definition of estimates (“to give or form a general idea about the value, size or cost of something”) you can see that there is a fundamental difference between the terms: in the case of forecast, we use actual data to make calculations instead of using experience and other information to guess at something. Hence, when you study estimation methods you can divide them into pure estimates and forecasting methods – those that use specific data, correlation and system dynamics to predict future outcomes. Another way of looking at the difference between estimates and forecasts is that forecasting is viable only when uncertainty and variability are understood. For instance, let’s say that you are trying to predict the behavior of a system that is bound by certain physical variables. Some examples could be: •
•
•
The properties of an electrical system, which are determined by the properties of its components, each of these properties with its own tolerances or variability. The robustness of a physical structure, which is determined by the strength of its materials, which again have certain tolerance or variability. A simpler example, let’s say you want to predict how many lemons will your crew collect this morning from your lemon tree plantation, which depends on the man-power of your crew and the amount of lemons each tree produces.
In the examples above, and under normal conditions, you can inspect existing data and find maximum values, minimum values, average, deviation and variability. You can then use that data to predict what is going to happen in the future with some accuracy. On the other hand, tomorrow may change the conditions substantially, it might rain, or some people might stay at home ill, and you should then react and update your forecast. This inspection of the existing data, together with building a model to predict future performance is what we call forecasting.
Estimating vs. Forecasting
As a counter example, if you used your own data on how fast you collect pumpkins as a basis to predict how many lemons a group of five people would pick, that would be estimating. You would have to make many assumptions: the walking distances are different; picking lemons from a tree is different from finding and collecting one pumpkin at a time, etc. The reason for this is that you don’t have available data on the same task and you don’t understand the possible performance when five different people are given this new task, you assume that it will be relatively similar to picking lemons. However, estimation is possible and relatively easy in some domains. Let´s say that my friend and illustrator for this book, Ángel Medinilla is an average motorcycle-racing aficionado (editor’s note: which he is!), and he can race around the Jerez fast track in 2:15 (editor’s note: ahem!), which is pretty fast for most street bikers. When you compare that to the usual Spanish Motorbike Championship times that range from 1:50 to 1:42, it means that the Spanish Champion is roughly 25% faster than Angel. And then you have the world record for the track, which is Jorge Lorenzo’s 1:39 (only 10% better than the average championship race lap). In this domain we observe that there is not much difference between ‘average’ race lap and ‘world’s best’ (at least when it comes to percentages). You could forecast the time Ángel would take to complete two hundred laps with a relatively small margin, not more than 20 or 30%. In this domain estimation would be relatively simple and accurate. In software projects, however, the situation is different. Even if you don’t believe that the best developers are 20 to 50 times more productive than average, just consider the following story: Jon arrives at the office, energized after a good night’s sleep. He is focused, and is ready to get into the groove of delivering high-quality software. A few minutes later Karl, a star programmer, with many years experience arrives as well. However, he just spent the crappiest night of his life. His daughter was sick all night and he had to take care of her. He basically slept a few minutes during the whole night and is feeling like he was steam rolled. Which of these people will complete the tasks they had estimated with less variation to the original estimates? Whatever your answer was: can you be sure of your answer? In software development there are many factors affecting performance on the job, and those factors are not predictable nor do they exhibit ‘predictable’ variation. Karl’s daughter had not been sick for the last 5 years, now she is. Jon just lost a dear friend to cancer, and he is trying to come back to his full potential with the help of friends and doctors. Life is not predictable, and life is the key ingredient in software projects: our intellectual performance is the key-determining factor of
WHAT ARE ESTIMATES?
our productivity and many factors affect us. Finally, estimation is affected by the expert knowledge fallacy. Experts are asked to estimate the average time a task will take and some understanding of the possible variation (in some cases). But experts can’t factor in the performance of other processes. A programming expert (e.g. an architect) cannot predict the time it takes to allocate testing staff to a particular task. Experts are good at predicting certain aspects of work, but you need to consider the whole flow of work before you can have reliable data to help forecast (data from several iterations for example). When you base estimates solely on expert estimation you fail to account for many aspects that affect directly the performance of the project. When you use data from the project to update your forecast, you are factoring in all aspects of the current project, and will be able to detect when the project performance changes (more on that later).
The Iron Triangle Carmen realized that she had no way to forecast results for this project. There was no team selected, so there was no past information on performance. There was also no previous experience with this client, technology, product, or domain… There simply wasn’t any historical data. Undoubtedly, the amount of uncertainty in this project was too big to create an accurate estimate, if that was even possible. According to her experience, uncertainty would find it’s way into the project, usually in the form of delayed deliveries or increased costs. On top of that, she knew most of the time many of the requested features were never used, so maybe having some sort of variable scope would be a better way to deal with uncertainty; but as usual this was out of the question: this was a government contract after all. Old school. Closed contracts, up-front definition, zero tolerance to deviations from the original plan once this plan was given the GO-decision. As Carmen thought about the best approach to this project she doodled a triangle on a blank page. A discussion on the topic of estimation is incomplete without some mention of the well-known figure of the Iron Triangle. The Project Management Institute, in their Project Management Body of Knowledge (PMBOK), described nine domains for project management. Those are integration, scope, time, resources, risk, quality, communication, human resources and procurement. But it is commonly understood that there are three main variables that will place your project in the ‘project space’, and those are:
The Iron Triangle •
•
•
Time: when will the full scope of the project be completed given the investment and people assigned, or how much time is needed in order to finish the project given those constraints. Cost: How many people, investment and resources are assigned to the project, or how many people, investment and resources are needed in order to complete the full scope in the projected time. Scope: the work that must be completed in order to consider the project finished.
These three variables are linked together: once you define scope, there will be a non-linear equation that will give you different possibilities on time and cost - the more cost, the less time, but with certain ‘crash points’ where spending more won’t cut time down, and using a longer schedule won’t reduce costs.
These three variables define the so-called Iron Triangle. In the center of the triangle lays a big question mark that symbolizes uncertainty. Once you understand these three variables as a single equation, you will understand the iron law of the triangle, which is that you can fix one or two of those variables, but you can’t fix all three of them. As a corollary, when you fix two of those variables, the third one will absorb all the
WHAT ARE ESTIMATES?
uncertainty on the project, and expand as necessary.
Imagine that you want to print the complete Wikipedia. You fix scope by downloading the Wikipedia content to a massive storage device. Then you decide to print it in the next 50 days. At this point you have fixed scope and time, so you can start calculating how many pages, printers and people you need to successfully print the whole of Wikipedia in 50 days. Let’s say you calculate 9.6 million pages, 20 pages per minute with one printer, you’ll print eight hours a day, with infinite resources of paper, toner and people, and a simple calculation will give you an amount of just 20 printers to get the job done. Of course, this sounds like a very reasonable, and simple calculation. What could go wrong? But again, this is your estimate. You defined an Iron Triangle of 9.6 million pages; 50 days; 20 printers. In the center of the triangle, uncertainty will find a way to get into your project... Let’s say you start printing on day one, and on day five you decide to look at the numbers… And they show you that you are behind schedule! You call a meeting with your people and they tell you that, yes, paper and toner are infinite, but they need to stop a printer for two minutes in order to change paper, which happens after every 400 pages (20 minutes), and that every day they have to change the toner, and that takes another ten minutes. So, on average, every day there are 58 minutes where you are not printing. And, multiplied for 20 printers, that means 1
The Iron Triangle
160 minutes, or 23 200 pages lost every day! In the next weeks, several other unknown factors will affect your project - printers will stop working, unplanned vacations and holidays, power outages, urgent tasks that will need the attention of your people, the list goes on. What you did when planning the printing of Wikipedia was estimation - you tried to predict what was going to happen, taking into account some nominal values and trying to imagine how the project progress would look like. On the other hand, once you started managing actual progress data you were forecasting. At this point in the Wikipedia printing project, you have committed scope, time and people and resources with your client. What can you do? You cannot add more printers, as your contract does not allow you to. You cannot add more time, as you would miss the deadline. And you cannot cut scope down and print the Wikipedia only from A to U, you need the whole A to Z. The common answer in the software industry would be to drop quality: print in lower definition or make printers print two 50% size pages on every paper; or make your people stay longer every day to meet their planned printing quota. The latter is a terrible idea both morally and rationally. It is reprehensible from a moral point of view as you are asking your people to give more than they are paid for, as they were not responsible for your failure to properly estimate this project. From a rational point of view it will make your people angry, frustrated, demotivated and will probably increase your turnover as people leave. In knowledge work environments – like software development – motivation is crucial to productivity, performance, creativity and innovation. By asking people to reduce their standards or stay over time, you destroy their motivation because of a commitment made based on an estimate! As this is a simple, repeatable project, the experience you gained the first time will help you reduce uncertainty in the future. The next time you are asked to print Wikipedia very few things will change when compared to the previous time you tried to complete that project: the content of the document will change, but you will have the same printers, same people, same time schedule, etc. Armed with a deeper understanding of the project: you will plan for paper change, toner change and maybe check the ‘Mean Time Between Failure’ (MTBF) 21 21 Mean Time Between Failure, Wikipedia: http://en.wikipedia.org/wiki/Mean_time_between_failures
WHAT ARE ESTIMATES?
statistics of your printers so you can plan for malfunctions. You can even create a risk management plan that involves some spare parts and a limited inventory of spare printers. Still, even the second time around, there will be some uncertainty that Unknowns, all the things that could go wrong involves all the Unknown Unknowns, and you could not know about. And when the domain of the project goes beyond a simple, simple , repetitive, repetit ive, algorithmic algorith mic tasks, and involves even rudimentary knowledge skills, the task of providing an accurate estimate proves to be really reall y challenging, challe nging, if at all possible.
The Start of a Project Is the Worst Time to Estimate Its Duration or Cost “How can I estimate the cost of the project or the time it will take? I don’t even have a team yet!” “Carmen, I think you understand how critical this project is for our company. Our CEO gave his personal commitment that this project would be done before the next election. Carmen, we can’t fail our company or our CEO!” “I understand sir, but I don’t even have a team yet. You can surely understand that these are not ideal conditions to make an estimate for a project that is this critical.” cri tical.” “Carmen, I chose you for this project from all of our project managers. I know you can pull this off. I’ve seen how well you tackle crisis situations. This is just another one. I expect your bid ready by the end of this week. Now I have to take a call with w ith the board of directors.” Carmen turned to leave, but her boss had one more thing to say. “Oh and Carmen, don’t forget. This is our chance; one strike and we are out. Don’t let us down!” “Tell me something I don’t know!” She thought. At the start of a project is when we know the least about the project. Yet, in many cases it is when we make the most important decisions. We decide on timelines, functionality, technology, architecture, and other critical variables for the project. Many questions went through Carmen’s mind: •
•
•
Can one developer estimate a project that other developers will work on? How many people do I have to assign to this project? Will other projects be starved starve d of people? peopl e? I need to balance price (part of the bid) with assigned people,
Uncertainty and Buffers
•
resources and time. How do I do that? – In estimating we have two variables, cost and time, that are interdependent, but how? How do we quantify that dependency? Is a larger team more productive than a smaller s maller team? What if the team changes during the project? – Other projects will be started during this project. What if some of the people in this project’s team get assigned to another project? How will that affect the project?
Uncertainty and Buffers Carmen had a just a couple of facts to work with. Fact 1 was the expected delivery date: this was a fixed date, as the system should be ready for a major integration event with another project – which of course was out of Carmen’s control. Fact 2 was the scope defined in the request for quotations. The scope was particularly problematic because of the way it was written. Just like any other written document, there were many ways to interpret that document. For example, in some paragraph you y ou could read ‘the ‘th e system syste m shall be able to export expo rt information infor mation to the most common data interexchange formats’. Of course, if this meant to create comma-delimited files, this wouldn’t be a problem, but she could recall projects where similar clients client s asked for PDF, Excel, OpenOffice, XML and even some really arcane formats. How could she tell up-front what was the meaning of this high-level scope definition? One way to try to limit the impact of the lack of scope understanding was to make some assumptions on the proposal and try to delimit what was included and what was not, but anyway there would always be a certain level of uncertainty and lack of definition. So no matter how many disclaimers she added, at the end the successful mutual understanding of the scope would be down to feature-by-feature negotiation, customer collaboration, win-win relationship and good will. w ill. “How likely is this client to behave this way? Not much…”, she had to acknowledge. Carmen realized that she needed more ways to deal with this project’s uncertainty. uncertain ty. She needed new ne w ideas. ideas . Every project has some uncertainty in it. In some domains, this uncertainty can be constrained in a way that ensures the project should (under certain conditions) not be off by more than a predictable margin – for example: plus or minus 20%. But in other domains the deviation from the estimated time can be orders of magnitude larger. In some cases the
WHAT ARE ESTIMATES?
estimation errors can be the 300% or 400% range, i.e. projects that take 3 to 4 times more than estimated. Most projects, at the advice of planning textbooks, build into the schedules and plans an uncertainty absorbing device, device , also known as a buffer . The idea is: we can’t know everything, so let’s add some buffer. A buffer adds some security margin to your project’s estimate. It can take many forms, although all of them are closely related by the Iron Triangle rule: •
•
•
Time Buffers: once we estimate a deadline, we add some more time to deal with project uncertainty (which also means more cost, as people will be assigned to the project for a longer period of time). Scope Buffers: instead of planning for N features, we plan for N + X%, where X% is the ‘scope creep’ expected, i.e. changes, new features, unexpected requests, feature size deviations, etc. Planning for more features means of course that you will need more time and money. Cost, investment and people assignment Buffers: if you think you need a group of people or an amount of money Y to get the project done by some s ome given deadline, deadline , you y ou will w ill plan for assigning a ssigning Y+Z% money or people so you have a better chance to meet the deadline.
Equally important to buffer definition is to decide how to manage that specific buffer. The buffer should not be just some extra time added to each task. Instead of that, every small deviation on the original plan should immediately be logged against the buffer, so we have constant metrics on project completion / progress rate and buffer consumption rate. Eli Goldratt described this approach in his Critical Chain Project Management22. Goldratt noticed that when every task estimate has some specific mini-buffer (padding), Parkinson’s Law would kick in and all tasks would expand to consume the available buffer. Tasks that take shorter than estimated will take advantage of the buffer and extend a little bit, or people will see that the next task is not supposed to start until next week 22 See Critical Chain by Goldratt, more information at: http://www.goldratt.co.uk/resources/critical_chain/
Uncertainty and Buffers
and will take care of other pending tasks (HR policies, old projects, etc.) until it is time to start on the new task. Even worse: tasks that take longer than expected will consume their buffer and a little bit more. This phenomenon will affect the whole project. That’s the reason Eli Goldratt proposed using a single buffer for the whole project, instead of individual buffers for every estimate.
Buffers are dangerous as they give implicit permission to be late, as stated in Parkinson’s Law. Eli Goldratt noticed this, and suggested hiding the buffer from the project team. In fact, he even proposed to cut all estimates by half in an attempt to fight the negative effects of Parkinson’s Law, and then use the other half as a project buffer. Success is unlikely if your project management strategy consists of hiding information, scheming, conspiring and deceiving. And by the way, the project team will soon find out your strategy and will balance things out by doubling their estimates. The sad truth is that buffers don’t solve all estimation errors. Buffers can help you balance the expected schedule impact of bugs, rework, scope creep and other predictable risks. The type of risks that can affect software projects go far beyond slips of schedule or unplanned down-
WHAT ARE ESTIMATES?
time. Hence why instead of managing risks, you should design strategies to reduce their impact when they materialize. One such strategy includes having a working product (potentially shippable increment or PSI) as early as possible. This PSI can work as an interim or ‘beta’ solution until you finish the whole product. Later we will discuss other ways in which you can use a PSI to actively reduce the impact of risks on your project.
Classic Methods for Crafting Estimates As Carmen worked on the project plan, things started to make some sense, but as understanding increased, her intuition told her that the overall size of the project was getting bigger and bigger. Even if she were to improve her skills as a project manager and as a leader, she wasn’t sure that there was a way to comply with all the project constraints and requests. She thought of just calling it quits and rejecting the project, but this would be a bad career move. Rejecting responsibility just when everyone was relying on her to save the day would definitely force her to look for work somewhere else. Carmen had a reputation for facing problems head-on and being open about finding solutions. So she resorted to the oracle of all project managers: Google. She sighed deeply, typed “how to save a failing project” on Google and started browsing. All she could find was the good old “get better at estimating” advice, which obviously was not an option for her. Her project did not have more time, or more people, or some magic silver bullet to help her find the “better” estimates all project management specialists were suggesting she should find. Estimation continues to be the preferred method for project definition and planning. The Project Management Institute (PMI) has been the powerhouse for Project Management in the last decade. They issue the reputed Project Management Professional (PMP) certification, based on their Guide to the Project Management Body of Knowledge, the PMBOK 23. The PMBOK has a full chapter for Project Scope Management, another for Project Time Management and yet another for Project Cost Management. Interestingly enough, the chapter on scope management 23 A Guide to the Project Management Body of Knowledge (PMBOK Guide) Third Edition
Classic Methods for Crafting Estimates
does not talk about estimates – in other words, scope is implicitly considered fixed and defined. Both time and cost management chapters have several pages on how to estimate against this fixed, up-front defined scope. In practice most project management practitioners will face a flexible scope in their projects, whether by design or necessity. This difference between the prescribed approach and the actual practice creates a dilemma for all project managers practicing their craft in software projects. They can either accept a fixed scope approach or look for an alternative, for example, the value centered approach. The value centered approach accepts a fixed time and cost which are most likely to be determined by contract and availability of people and money, and accepts that scope will be variable. In practice, this is translated into a practice of adding or removing scope from the project as needed to compensate for unplanned work or risk events. In other words: to compensate for uncertainty. The value approach focuses on specific practices, like prioritizing scope and delivering the most valuable and necessary part of the scope early, leaving all the ‘nice to have’ and ‘bells and whistles’ for the last part of the project, where uncertainty is more likely to affect the project.
After some hours of writing high-level work packages on a Gantt chart, Carmen decided to ask for help estimating all of those work packages. She was looking for dependencies by dividing work into smaller work packages and analyzing their dependencies. She needed
WHAT ARE ESTIMATES?
some experts to help her. During the following days, Carmen desperately tried to book some time with the architects and technical leads in the company. Unfortunately, they were all too busy with ongoing projects. Other project managers even asked her not to disturb ‘their people’. She managed to gather some insights on the technical side of the project, but barely enough to understand the meaning of some terms – not even close to craft a meaningful estimate. “Darn, I need to continue to dive deeper into this project. I’ll go and interview the Business Analysts (BA) at the client site. Maybe they can answer the questions I have from reading the requirements document.” Carmen picks up her jacket and starts walking to leave the office. She dials the number of the contact person at the client. “Caroline, hi! It’s Carmen from Carlsson and Associates. I’d like to come in and interview the BA’s for project Big Fish. Is it ok if I drive over and meet with them after lunch?” “Hi Carmen, nice to hear from you. Yes, you can come over but I’m afraid that the BA’s have already been assigned to other projects and are out of the office during this week for kick-offs. Oh wait, Travis is still here. Let me check if he is available…” Carmen hears Caroline ask something. Silence. After a few seconds: “Carmen? Still there?” “Yes, Caroline. I’m here.” “Yes, so you can come in and meet with Travis, but he is very new on the project and may not be able to answer all your questions.” “It’s better than nothing,” – Carmen thought to herself. “Ok, I’ll be there at 13:00. Talk soon.” As Carmen drives to the client’s offices, she starts thinking about uncertainty. “What is the uncertainty level in this project? If I could quantify it, how large would it be?” She decided that the uncertainty level for this project is a solid 5 on a scale of 1 (no uncertainty) to 10 (complete unknown). Usually this would mean that she would give a margin of 50% to the project estimate. But she knew it would not be acceptable this time. She thought about it and decided that a margin of 20% was all her stakeholders would accept. A few hours later, on the way back to her office and after having spent 2 hours grilling Travis the Business Analyst, Carmen reflects on the questions she could not get answered and concludes: “If this is how sure they are of the requirements of this project, then it is clear that the requirements are going to change a lot during the project.” “With this level of expected changes and the uncertainty on our side,
Classic Methods for Crafting Estimates
the uncertainty level should be raised to a 7 or 8, but that is not sustainable sustainabl e in the current situation. situatio n. I’ll have to spend a lot of time breaking down those requirements with our Senior Architect. We must win this bid.” As Carmen enters the office her boss calls her into an empty meeting meetin g room. “Carmen, I just got word that Accent Partners delivered their bid for Big Fish. You have an email with the details of their bid. Make sure we win this bid. I have faith in you.” Back to the PMBOK, the cost and time estimation sections provide several tools for crafting estimates. A short summary of those techniques is: •
•
•
•
•
•
Expert judgement: as the name suggests, you find someone who is an expert on the domain and ask about his or her estimate – which is the expert’s e xpert’s guess. gu ess. Analogous Estimation: consists on using information from past, similar projects or tasks and assume that this project won’t be very different from past projects. Published Estimation Data, Vendor Bid Analysis: the study of similar projects from other organizations can provide data that we can use to refine our estimates. Bottom-up Estimating: the idea is to divide the whole project in small, estimable work packages or tasks and then add them all together to obtain a whole-project estimate. Parametric Estimation: also known as sampling. If there are simple, repetitive tasks, then you can estimate the duration or cost of one or a few of those tasks and multiply by the total amount of tasks in the whole project. Group Decision-Making Techniques: the main rationale for this approach is that a group of experts can produce a better estimate than one individual on his own. Brainstorming (producing several ideas and then analyzing them) or Delphi and Wideband Delphi (asking several people separately and then putting their estimate es timatess in common co mmon and discussing discussi ng them) are some som e of the known approaches.
WHAT ARE ESTIMATES?
Estimating in The Agile World Agile practitioners have suggested several agile specific practices and tools. Possibly, one of the first approaches was the Extreme Programming planning game, which used a group decision technique to decide on how much work to take on into an iteration. Team members would discuss and collaborate to describe the work they were considering undertaking, and finally decide on what they could commit to. The discussion and conversations during the planning game helped build a common c ommon understandi u nderstanding ng among the team tea m members. memb ers.
Poker planning and estimating Another well-known technique is the planning using cards with numbers, in which team members will select and later discuss around the size and complexity of work the team wants to plan for a particular iteration. This approach is often called planning poker, and helps the team discuss each work item (typically user story), followed by a blind estimation vote to avoid team members from being influenced by other’s votes. Once the vote is completed, the team will discuss the highest and lowest estimates to try and reach a consensus or, if needed they will estimate again. Once the team agreed on a particular size and complexity for a user story, they would assign a story point value to the user story and discuss the next, until they felt they had reached the limit of possible work for the next iteration. Planning poker is typically used by agile teams to do relative size estimation: the relative effort necessary to one work item, when compared to other items in the team’s backlog. This gives the team a measure of size and complexity in the form of a story point value assigned to each story. All stories of similar size and complexity will have a similar story point value associated with them. Using past velocity to estimate future capacity The Scrum framework also introduced the term velocity as velocity as a measure Done) work in each of the team’s capability to deliver completed (aka Done) iteration. After collecting some data from several sprints, then teams can use the average velocity to analyze a prioritized and estimated backlog and forecast delivery dates and costs. The caveat is that the understanding of the work to be done changes over the course of a project, which in practice practic e means that some teams end up re-estimating re-esti mating their backlog items several times during the project. Prioritization vs. estimation These tools and techniques assume that some kind of prioritized
Estimating in The Agile World
backlog has been created with the customer or their representative. represent ative. However, most frameworks fail to establish a prioritization technique, they just assume that the client will know what is more important and valuable. This is a major flaw, but fortunately frameworks and tools – like the Lean Startup ideas – were developed to formalize prioritization methods. These prioritization methods are very much in line with the ideas in this book. Most noticeably Kanban and Lean Startup place a greater emphasis on the prioritization process than on having estimates of the backlog items. The rationale rational e is that once you know which is the one single most important thing in the universe for universe for your company right now, now, there is little value in knowing how much is it going to cost when compared to other items in the backlog. For these methods the value of the work in the backlog is the driver for decision-making.
WHAT ARE ESTIMATES?
Estimation vs. flow Lean, and Kanban highlight the importance of limiting the work in progress and helping the system flow. Flow improves as we reduce the number of work items in progress, which in turn reduces the time to complete each individual work item. Once there is a prioritized list of work items, the Kanban ideal is to be able to process work items one at a time, non stop, and do that with as little delay as possible. As a way to help the work items flow from backlog to production, variability in the work and/or processes should be addressed, understood and, if possible reduced. The use of historical data for flow metrics can then be used to forecast results, deadlines and projected costs, without having to estimate every individual work item. Selection method: riskiest assumptions first Lean Startup focuses on identifying the most important assumptions about your business model: those that, if proven wrong, would invalidate your whole project. It then urges you to define experiments to prove those assumptions right or, if they are wrong, create new assumptions through a pivot 24. These validated learning cycles should be performed as quickly as possible, ideally several times a day. If you are able to perform this series of strategically critical experiments so quickly, then spending time trying to estimate the length or cost of each experiment is pointless. When are estimates reliable? Estimates are often used in agile projects to provide information that helps prioritize the backlog of work items. However, those estimates are so often wrong that the only appropriate use is to separate clearly the items that are sufficiently different from each other. This clear difference would help us with the decision to drop one of them. For example, if one item is estimated to last one week, and another item is estimated to last for 10 weeks, then it is easy to believe the first item will be delivered faster. However, if the difference in estimation is small (e.g. 10 weeks vs. 12 weeks), the errors in estimation can easily defeat the purpose of making a decision based on the estimated duration of that item. Focusing on value Additionally, experience shows that only a fraction of all product features deliver the bulk of customer valuable functionality. Identifying 24 Pivot is a structured course correction designed to test a new fundamental hypothesis about the product, business model, and engine of growth.
Estimating in The Agile World
which features are the ones that deliver most value is therefore more important than finding which of them are small and which are big . In essence, cost is not proportional to value. Once the cost difference between features is reduced (by splitting the work into small, verifiable work items focusing on value), prioritization based on customer value for each work item provides better results than deciding which are the cheapest or the most expensive work items. But don’t we need to estimate to know when the project will be done? This is the most common objection to #NoEstimates that I hear over and over again. In the next chapter we explore the reasons why this question is asked. In other words: why do we really need estimates?
CHAPTER 3
RETHINKING ESTIMATES The (Alleged) Need for Estimates: Deadlines, Costs and Scope Carmen was exhausted. She had been working 14 hours a day for the entire week in order to produce a document that made sense. She had highlighted all the risks she could think of, all technical dependencies, all sources of uncertainty and interpretation, and all key boundaries and constraints. Still, she couldn’t think of a good way to define a vision of success without actually asking the client about it. Of course, the client was not available to clarify. Carmen’s boss started to gently press her to produce an estimate three days ago. Two days ago he had started to send her e-mails and copying all relevant stakeholders up the corporate ladder. The day before, he had started to phone her almost every hour to ask about the progress with the document, and drop last minute recommendations such as “oh, by the way, it is absolutely mandatory that you find a way to introduce our Business Analysis, Automated Testing and Architectural Support consulting services into the proposal”. This was not what Carmen needed a few hours before the proposal was to be ready. At that moment, looking at her nightmare-ish document that already counted 300 pages, Carmen felt as if her life was a Dilbert cartoon. “Maybe it is because I’m exhausted,” Carmen thought, “but right now I cannot think of a reason we are producing this monster of a document. There are too many loose ends - it will just never work the way it is described here. Worse: everyone knows that! Very probably, even the client knows that, at this point any fixed definition of what the future will look like is just W.A.G. – Wild A** Guess. So what’s the reason everyone is so excited about having it as soon as possible?” “Why don’t we just start working on it and find out what really needs to be done?” Carmen shook her head, took a sip of her coffee and thought, “wow, I’m just losing it… I need to go on and finish this as soon as possible. I need to focus on how we can win this contract and move on to the next problem as soon as possible.” It was 22:00 and she could hear the distant sound of young people partying the night away at the pubs nearby.
The (Alleged) Need for Estimates: Deadlines, Costs and Scope
Let’s review for a moment the situation Carmen is in: •
•
•
•
She is responsible for a bid on a very important project for her firm. She is being pressured by her boss and her company to deliver the project under a certain time/cost. She knows that uncertainty regarding the project itself is high, and the stakeholders do not want to have that uncertainty affect the estimate. She does not yet have a team – after all, they are only in the bidding phase.
Many projects suffer from these same dynamics. They suffer from unrealistic expectations. How do you estimate a project like that? Can you avoid that part of the project, can you drop estimates altogether? The answer is not simple. When a bidding process is required, you can’t avoid providing an estimate. And there are many ways in which you can try to be precise, honest and create an estimate that you believe in. But when you go through a bidding process, even if you can provide an estimate you truly believe in, the start of the project is when you know the least about the project in all its dimensions: content or scope, costs, technology and, most importantly, people and teams. We need a different approach. All parties involved in a bidding contest use estimates to “win”. Providers use estimation as a tool to win the bid. Clients use the bidding process to create a pressure on the estimations by the providers. Clients want to create that pressure to win the cheapest or fastest project they can. But estimates – no matter how good they are – cannot give you what you really need: visibility to progress; and actionable information.
Rethinking Estimates
Now that we have a common base to discuss estimates, we can move to one of the fundamental questions around the use of estimates in software projects.
Why Do We Need Estimates? Common answers to this question include: • • •
To know when the work will be completed and delivered. To know how much the project will cost. To know how many features we can fit in the project, given time, and other constraints.
Of course, this does not mean that estimates will help you to actually know time, cost or scope of the project, but you can have a better idea and constrain the outcomes to a minimum or maximum time, cost and scope. It is important to know that estimates, on their own, have no actual value unless they can help us understand better when the deliverables are going to be ready or how much the whole project will cost. If there were
Why Do We Need Estimates?
any better way to know the answer to these questions, estimates would be a waste of effort and time. For example, if you could know when a box is going to be delivered by asking the courier company, it would be a waste of time to conduct an estimation meeting and try to estimate when the box will be delivered. But there are deeper, human reasons to estimate and ask for estimate. One is emotional - you just need to know them so you can sleep better and reduce your stress. This is very common when I travel. When I travel early in the morning, the night before I make a careful prediction (or estimate) of how long it will take me to reach the airport. I check the weather and road conditions on the way to the airport and come up with an estimate for that trip. Then I book a taxi for a time that would give me a 30 min or so buffer because the security line at the airport may be slow that day. Making this estimate helps me sleep better. In any case I always setup 2 different alarms to make sure I wake-up on time. Without this estimation I probably wouldn’t sleep very well. Another possible reason is that you might need to give some answer to your client so that he stops calling you every five minutes, or you need to tell something to senior management and other stakeholders so they trust your ability to manage the project. You can probably think of other scenarios of when the people involved in the project just need to hear an estimate – no matter the accuracy of the estimate – so that they can feel safer, or that the project is in control. These human reasons are understandable, but they don’t make your estimates critical to understanding the project progress. They are part of working with other people, who have different needs. Without really thinking what she was doing, Carmen speed-dialed her boss’ number. He picked up the phone after just two rings – bad sign, he was expecting the call. “Hi Carmen! Do you have news for me on the Big Fish bid? I have the client’s people all over me…” “Er… I am almost done, sir. I understand that our company’s future depends on this project. I understand that we must present our bid soon, but I’ve been trying to get a team together for the past few days and no one is available.” “Well Carmen, that’s why we put you in charge, we’re sure you’ll find the way.” “I was just wondering…” “Yes Carmen?” “You know… There’s no easy way to put this...” “Come on, Carmen, you know I absolutely support you, you can tell
Rethinking Estimates
me anything.” “It’s just that… I don’t really understand, sir. It doesn’t matter how much work I put into this document, it just makes no sense. There are too many loose ends, too much uncertainty. Above all, why do they need such a complete plan now?” There was silence on the line. “Sir?” “Er… Yes, Carmen, it’s only that I’m not sure what your question was about.” “It’s simple, why do they need an estimate?” “Well, Carmen, I assume you are asking that because it’s Friday and it’s late. This is a very easy question: they just need something to show to the business.” “Yes, but why?” “C’mon, Carmen, you’re kidding me… They need something that shows them that the project will be done on time, something that makes them trust us.” “I understand, sir, but… If this is a trust issue, not a planning and analysis issue, wouldn’t it be better solved through communication? I mean, we don’t actually know if the project, and I mean the whole project, is going to be ready on time. We can just give them an idea of what might get done and what’s the uncertainty range. It’s like…” “Look, Carmen,” her boss interrupted, “it seems to me like you feel insecure. I understand that you are under a lot of pressure. But you know that we need to deliver the bid or we will lose the project.” “Well, if it’s just a matter of showing something, then I could have just made up those numbers instead of overworking myself through the last week.” Carmen was starting to feel anxious and frustrated. After all her hard work, her boss seemed to be telling her that whatever she wrote on the document it didn’t matter. “Carmen… Calm down. You are under a lot of pressure, I understand.” Carmen’s boss said in a harsh voice, “but it’s not like we could just put together some random numbers. These need to be accurate estimates, and you will need to live up to them. We will commit to these numbers, and you will be responsible to deliver according to them.” “This is not fair, sir. If you are going to hang me with my own estimates, then I’d prefer to keep them conservative. I’d rather say that we are going to do just some of the 400 features in the backlog, and that it will take us a year to do so.” “Carmen, don’t over react, please. We need to commit to the whole project scope. And it has to be delivered before the defined deadline. Period. This is non-negotiable.”
Why Do We Need Estimates?
“But sir…” Carmen felt her voice trembling, “you already have your estimate. All the features, right before the deadline. It’s like we already know what the estimate should be even before completing the due diligence work…” “Carmen.” Her boss said and paused for a few seconds. “You know what you need to do, that’s why I chose you. I pay you to solve the hardest problems in our projects. I know you can pull this off. Now I better get some sleep, we have serious work to do through the weekend. I hope you will see things differently tomorrow.”
The phone line was dead… What Carmen’s boss is asking her to do is to use her magic touch and convert an impossible project into a viable one. She will do just that a bit later in the story without the use of estimates, but before explaining how she does it; let’s review her situation. Winning a bid no matter the consequences is a very common anti pattern in the vendor-buyer relationship for software projects. The bigger the project, the more often it happens – because there is a lot of money, status and reputation at stake. And because there is so much at stake, we invest significant time and money to try to reduce the uncertainty of our decisions. Not knowing what is going to happen in the future causes a lot of stress to the untrained mind. Any projected deadline, cost or feature catalog crafted using estimates is a guess, no matter how well researched, prepared and reviewed. These guesses help reduce uncertainty, but not eliminate it. Sometimes, a very inaccurate estimate acts as a sedative: it will provide you with bad information that will make you feel secure, but when you realize the estimates were wrong it might be too late and at that point stress levels go through the roof and everybody loses their cool. In some other cases, estimates are used as a weapon to assign blame. In these cases, the estimates will turn into a deadline and all involved will be blamed when the deadline is not met. How can estimates used in this manner add value to a company? Is this a valid reason to spend so much time and money on estimates? Is it the best way to manage projects and mitigate risks? Often organizations will start a project that just needs to be done, no matter what, and then will spend some time estimating size, costs and deadlines because they need to know when it is going to be done, or how much will it cost, or what features will be delivered. In those cases, when you ask them what decisions will they take depending on the projected cost or delivery date of this project, what usually happens is that they stare at you as if you were speaking Klingon. “Because we can’t
Rethinking Estimates
continue selling our product if we don’t do this project!” – I can hear them say. In these cases, what is the value behind these estimation efforts? If you just need it, start doing it and deliver something as soon as possible. You can report throughput and forecast future results later based on the first deliveries, and this information will be much more valuable and accurate than any estimation done at the start of the project. In other cases the reason why you might need to know scope, cost or time is rational: you will decide to start or to contract a particular vendor depending on the estimates. If we can have it before this date, or if it costs less than this budget, or if it has at least these features... This is also the case for clients who need to know what vendor to contract depending on the information they provide on expected cost, deadline and features included. Of course, you should notice that these decisions are being made based on estimates (guesses), and that an estimate is not necessarily equal to a commitment. As an example, a client recently needed to decide whether to invest time and money introducing better engineering techniques into their team or just maintain the low quality levels but have more chances to meet a projected deadline. As usual, they asked for an estimate: “How long will it take to introduce these techniques? What will be the impact to the team’s velocity at the beginning? When will the velocity stabilize and increase? And how long will it take to recover this initial investment?” There is no bulletproof way to know the answer to these questions in advance because the answers depend on many factors. Instead of a guess, you need to make a trade-off decision between short-term goals and long-term improvement you seek. If you choose short-term goals, you should then make the necessary decisions to deal with the long-term negative impact of that decision. However, if you decide to support the long-term goals, you have to make the necessary adjustments to your short-term goals. No amount of time invested in estimates will help you make the inevitable adjustments, because predicting the exact impacts of either decision is impossible. Maybe your best engineer will quit because he hates Test-Driven Development, or your best tester will quickly recruit even better testers once she understands that you really mean quality when you say quality – thanks to your decision to focus on quality. In that particular case the teams were asked to invest at least 15% of their time on engineering improvement while keeping the deadline fixed. This meant that if we thought that the deadline wouldn’t be met, we would start cutting down on learning and training time. What happened didn’t surprise me: velocity didn’t change a bit once we started using 15% of the time to improve the engineering practices, while during the
Project Driven Development
next six months quality increased dramatically! This was true win-win situation, which could not have been predicted by estimating. Magic? Not really. But it does take a great deal of experience to understand that not all activities have a linear impact on schedule or costs. This is what Agile Software Development is all about, exploring the non-linear relationships between time invested and benefits gained, just like #NoEstimates.25 Some argue that the process of estimating a project, will help the team get a better understanding of the requirements, the architecture or technologies needed to succeed in that project. The assumption is that estimating a process will result in a better analysis of the project details. This is not always the case. Having a conversation about the scope of a project or even the technological alternatives is very different from the process of estimating cost and time to implement. Estimating and analyzing are two different things, and although you might need analysis to estimate, the contrary is not true. Estimation and analysis are potentially linked techniques, but they are not dependent on each other. You can estimate a project without analyzing it (like I propose in this book), and you can also analyze a project without estimating its size or cost. The conflation of estimation with analysis leads to sub-par analysis, and that in turn, leads to bad estimation.
Project Driven Development The reasons discussed above as justification for estimation are part of what Ángel Medinilla calls Project Driven Development , a term he coined to clearly distinguish this approach of developing software from other approaches. In this approach, the most important project goals are not customer value, quality, product success, time to market, adaptation, learning, market share or even profit. The important goal is to meet the established deadline, within the defined budget, with all scope included. Simple.
25 An interesting rabbit hole for the statistic mind if the concept of Confounding variables (https://en.wikipedia.org/wiki/Confounding). This is a concept that begins to unravel why estimation is such a hard problem. Thank you Pier Lorenzo Parachinni for the hint to include this reference.
Rethinking Estimates
People that evaluate their performance through those very same metrics – not surprisingly – introduce project Driven Development to their organization. Other metrics, such as quality; product-market fit; or speed of delivery end up being ignored in favor of being on time and budget. In these projects developers and customer support teams will feel the pain of bad quality. The lack of product success will be blamed on the customer “not knowing what they wanted” or the marketing team. The negative effects of Project Driven Development will affect multiple people and teams in different departments; hence the blame will be distributed while the project life-cycle process – the real root cause for product failure – remains unchanged. The Project Driven Development paradigm is characterized as delivering any scope on time, under budget and within the defined scope. Even if this approach might maximize your chances of receiving a shortterm bonus, in the long-term it is does not help your company or your client’s company to be more competitive, nor is it maximizing value from the perspective of the customer. However, some will find a lot of value on Project Driven Development. But are they maximizing value for their customers with this approach? A commonality between organizations that follow this approach to software development is that they often have little or no urge to compete or survive, sometimes because they are a de-facto monopoly in some industry. Other times because the real goal of the organization is
Project Driven Development
not survival or success, but rather to maintain their status quo. Yet another case is when the organization is very successful despite their software practices, and have no motivation to change because of that success. In these cases, Agile or Lean makes little if any sense, as there is no perceived need to maximize customer value, reduce waste or adapt to change. For example, let’s say you approach a traditional consultancy business and tell them “hey, I can show you how to turn that 8 year - 500 people - 250 million euro project for your customer into a 1 year - 10 people - 0.9 million euro Agile project.” The typical reaction will include an incredulous stare, followed by: “Why on earth would I want to do that?” Another example of Project Driven Development: maximizing project size, cost and perceived outcomes instead of searching for better ways to deliver customer value faster.
Rethinking Estimates
Set-Based Design vs. Point-Based Design One of the many things that distinguished the most productive car company in the world, Toyota and its Toyota Production System26 from its American counterparts was the use of Set Based Design, sometimes also called Set Based Concurrent Engineering. In this approach, the Japanese designers of new products would go to great lengths to make design commitments as late as possible in the project (a goal of set-based design). In contrast, the Americans were committing to sub-optimal decisions very early in the project, and then having to re-work those designs due to unforeseen performance or quality problems (point-based design). At Toyota, the production engineers would simultaneously start to design the production line and prepare manufacturing long before the new car designs were finished (hence, concurrent engineering), instead of waiting until all decisions about the design were closed. This, in the end, provided Japanese manufacturers with an astonishing competitive advantage that let them design and produce the Toyota Prius in about 3 years27, from idea to first sale! When the industry average for the time it took to introduce an improvement in an already existing car model was closer to four years. I sometimes wonder if this principle of “defer commitment” was not influenced by Japanese martial arts. When training Kenjutsu, Ángel Medinilla’s Sensei often says “you have to wait until the last responsible moment; if you move too early, your enemy will spot your movement and neutralize it; but if you wait too much, your opponent will strike you.” Making hard decisions early in the design process – when we have the least information – may force us to take the wrong path very early in the project. Later on some of those decisions will be very hard to reverse as decisions stack on top of each other as the project progresses. When you keep the scope flexible and do not limit features by a predefined estimation, you will be open to explore new possibilities as you gain more knowledge on the project. This will enable you to explore different solutions for the critical decisions, which is one way to use Set 26 More on the Toyota Production System at: https://en.wikipedia.org/wiki/Toyota_Production_System, and the very enjoyable book by Liker: The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer 27 Wikipedia: http://en.wikipedia.org/wiki/Toyota_Prius_%28XW10%29
Set-Based Design vs. Point-Based Design
Based Design If your company is asking for detailed plans before any work actually begins, there's a good chance that you are practicing a linear method, aka waterfall. Product development experts nowadays advise against this approach in complex environments 28. If you don't have a clear and detailed blueprint of what you need to build (like in cars, motorcycles, bridges or buildings) it would be far more productive and safe to start with a low-fidelity prototype and iterate it frequently in an evolutionary manner, obtaining direct feedback from your customer as you go and reducing uncertainty progressively. When the Toyota Prius team started their project, the whole definition they had from Toyota's Chairman, Takeshi Uchiyamada, was to make a green car and "question everything you know about cars". This project gave Toyota a high-single digit or low double-digit year advantage when compared to other automakers (exception: Honda)29. In the Prius example we see that the project starts with a bold goal, and a clear direction. No estimates. When the Honda City engineering team, which averaged 27 years old30, started their work, the project definition they got from management was "we want you to build the kind of car that the youth segment would like to drive." How does this compare to estimated, fixed, inflexible project plans?
28 For a comprehensive discussion of linear vs incremental planning see Larman’s Agile and Iterative Development: A Manager's Guide. For a discussion of complexity, see Snowden’s explanatory video at: https://www.youtube.com/watch?v=N7oz366X0-8 29 Wikipedia: http://en.wikipedia.org/wiki/Hybrid_electric_vehicle 30 HBR, The New New Product Development Game by Takeuchi and Nonaka: https://hbr.org/1986/01/the-new-new-product-development-game
Rethinking Estimates
Variability The estimation process is an attempt to reduce uncertainty and variability in projects. In an environment with no uncertainty and no variability, estimates would have no meaning - you would always be certain about cost, time and scope. Once uncertainty and variability kick in, it is difficult to know the exact cost, time and scope up front. If your estimates are proven wrong this will impact heavily the results of your initial decision. Hence why you need to constantly check how the project is performing according to the initial estimates and re-plan and re-estimate again.
Re-planning usually results in your client and stakeholder saying “but you committed to this deadline! You cannot change the plan now! Do whatever it takes to maintain the delivery date – but, of course, with no changes to budget or scope.” A lot of effort is invested into estimation, but not so much to reduce sources of uncertainty. On the contrary, companies that apply Lean Thinking (Lean companies) have been developing ways to reduce variability since the start of the Lean adoption. Lean companies use an
Variability
approach they call heijunka31 to reduce variability in the work where possible. This leveling out of the work load (for example, by having small User Stories) will help you reduce variability in task duration as well as help you identify the unexpected variability early on. When the rhythm of work is steady enough, the estimation process loses importance and forecasts are more useful and more accurate. Below is a list of 8 possible sources of variability for software teams. Technology: if a team which developed a Cold Fusion application for fifteen years is asked to create a .NET application, all the previous data on velocity, feature size, cost and time will be basically useless for the purpose of forecasting their throughput in this new project. On the other hand, using technologies that are immature or buggy will dramatically increase accidental complication: the work necessary to work around that unstable technology. Lean companies try to use only proven, reliable technologies, no matter how fancy, trendy or innovative a platform might look. The use of established and well-maintained frameworks is a good example of this principle on more technology or software related environments. Domain or product: even when you don’t change the technology, there can be a lot of variation if the team is forced to develop a new product or have to work on a different knowledge domain. For example, if the team have been developing a micro-payment solution and now they are asked to develop a warehouse management software they will probably need to learn many new things, and their pace of work will vary highly until they reach a level of proficiency with the new product domain that allows them to focus more on delivery and less on learning a new domain. Team composition: some often-overlooked sources of variability are changes in team composition and team dynamics. Many people assume that, if you reduce team size by 10%, the throughput should drop 10%, and if you double team size you should be able to cut development time by half. This is not the case. If you have a team of 10 people and you fire the only business analyst in the team, the effective productivity rate will drop way more than 10%. On the other hand adding more people to a project that is late is likely to delay the project even more because of the 31 ) >PQPRSTS UVWX YZPY [SPRT \]S^S]_R`.a *ZSR _[Q]S[SRYSX bVWWSbY]cD ZS_deRfP S]S`PRY]c g PRX U_YZVeY ZPTYS g ZS]QT VW`PR_hPY_VRT [SSY XS[PRX UZ_]S WSXeb_R` UPTYST _R QWVXebY_VR PRX _RYSWQSWTVRP] QWVbSTTST. *_f_QSX_P; ZYYQ;iiSR.U_f_QSX_P.VW`iU_f_i8WVXebY_VRj]S^S]_R`
Rethinking Estimates
increased complexity and the need for the team to adapt to its new composition. In other cases, removing someone from the team will actually increase throughput, while adding someone will dramatically backfire. Human teams are not bound by arithmetic - you cannot add, subtract, multiply or divide people! User, Client and client representative : as we will see later, one of the most effective enablers of a #NoEstimates approach, is a savvy client representative. No matter if it is a Scrum Product Owner, or someone from your client’s organization or even a team of people performing this role as a Product Management team: if you have someone that is able to divide your work in chunks of small enough work-items and prioritize them according to business value, it will make your life easier in so many ways that I wrote a book about it - this book, of course. On the other hand, a ‘bad’ Product Owner or client representative can have a very negative impact in organization by not helping them focus on the most valuable deliverables, or worse: trying to get so much work started that the whole organization grinds to a halt. Given the potential impact of a Product Owner in the organizational performance, it amazes me that the main focus of many organizations seem to be on training only team members or Scrum Masters. While they ignore the education and improvements necessary in management and product ownership. Workload and / or focus factor : having teams constantly changing their focus between different projects or having to attend to bug fixes every day, small requests, or side projects can dramatically increase variability in the pace of work. Not to mention the effect on teams’ morale, product quality and organizational performance. In my experience, teams constantly shifting from project to project have a significant performance decrease when compared to teams that are allowed to focus on one project at a time. On the other hand, at the end of the day, both teams will report ‘8 worked hours’, and many companies will consider that both teams ‘produced’ the same. Market and competitors: introducing your products to new markets can bring variability in the form of new requests, adaptation needs, regulations compliance and other requests for changes. Similarly, when new competitors or new products enter our market, our plans will change, which will inject unexpected variability in the project. Dependencies / specialization: in environments where the norm is high specialization and dependencies between production units, departments and even team members, variability is higher because of bottlenecks that constantly emerge when and where we least expect. Hence why methods such as Scrum advocate the cross-functional team as the unit of productive work in software development organizations.
Variability
Cross-functional teams reduce variability by reducing dependencies. But there are also other causes of variability, for example, some companies assume that every Story requires X% analysis, Y% development, Z% unit testing, with X,Y and Z all being fixed. But for some items, it could be that doing a lot more analysis could even lead to 0 development: the feature could be configured Instead of developed. Therefore the composition of the team will cause variation in the estimation of the work being analyzed and therefore cause variation in the overall project. 32 Waiting for availability: Waiting happens when a work-item is ready to be worked on (the requirements are ready, or the design is ready, or the code is written), but it must wait for the people with the right skills to be available. The time work-items spend waiting to be picked up can amount to more than 90% of the calendar time it takes to deliver the work item. These wait times are also very hard to estimate because they depend on many factors. When you ask teams to estimate their work, don’t forget that they will only estimate the time they actually work on the item, not how long the item will spend waiting. These wait times can have a very large impact on the overall schedule for a project. With all these sources of variability in performance, it is amazing that people ask for accurate, precise, fixed estimates and commitment at the beginning of a project. This is the time in the lifecycle of the project when we know less about what is going to happen. And don’t forget: the people making commitments to deliver on a particular deadline, scope and budget usually have neither control over these sources of variability, nor authority to re-negotiate deadlines, budget or scope when variability kicks in! The higher the variability, the harder it will be to predict the throughput of completed work; therefore, any investment on reducing variability will impact the product development team’s reliability and predictability. Here are some techniques you can use to reduce sources of variability in throughput for your organization: •
•
Stabilize your teams and avoid constantly changing people from one team or project to another. Define clear priorities, reduce dependencies and allow people to work on one thing at a time, finishing it before starting a new work item.
32 A special thank you to Maikel Vandorpe for the explanation regarding dependency on the team composition.
Rethinking Estimates •
•
•
•
•
Build quality into the whole production process, do not try to inspect quality in33 at the end of the line; ensure that no defects are passed down to the next step in the line. Enforce cross-functional work groups and generalizingspecialist34 teams, which can solve problems in parts of the product for which the specialists are absent, yet focus on specific areas where they have long-term experience (aka T-Shaped professionals). Standardize and automate where possible. This will allow your teams to focus on actually getting the maximum amount of work done that is possible. Protect the team from outside interruptions that disturb their focus and typically cause uncontrolled multi-tasking. Freeze scope inside iterations and allow the team to work on delivering the most important work, without context switching that costs them time and takes focus away from the most important work.
In the software industry, teams and organizations are forced to adopt new technologies, to change their domains of knowledge, or simply work in new projects. It is precisely in these cases that the #NoEstimates approach delivers the best results. It is much more appropriate to look at actual throughput (work delivered to the quality expected), than trying to estimate work done in a previously unknown domain, with a new technology, a new team, for a new project or client, etc. For example, assume you are a competitor to Facebook or Google. Can you estimate how much Facebook or Google are going to innovate during the next 12 months? Not likely. It is a much better strategy to improve your capacity to respond to whatever will come your way, no matter what your competitors will come up with, or come up with 33 Inspecting quality in: using reviews, or quality checks to help increase quality, instead of designing a work method that prevents mistakes from happening. The latter is often referred to as error-proofing. 34 A generalizing specialist is a specialist that can help the team progress by working in other areas where they are not the expert, but have enough knowledge to be able to help deliver certain work items. This is important because it reduces wait times, a major cause of variability in software development processes.
Estimation vs. Prioritization
strategies that force your competitors to respond and adapt to you instead. When you are ready to respond quickly, no matter what your competitors come up with, you will be able to respond and adapt.
Estimation vs. Prioritization Scrum teams all over the world are asked to estimate the Product Backlog. The Product Backlog should be a description of the product, feature by feature in priority order. Once you know what is the most important functionality to help your customers and grow your business, you then break that functionality down – in priority order. And this is a very important approach when you want to focus on business value: prioritization comes before estimation . It is common that managers and business people say “I need to know the estimate, the cost of every feature, so I can properly prioritize.” The immediate consequence of this statement is that estimates become the real “value” for a feature. No one wants to commit a team or a project to a long feature because we have “lower hanging fruit”. This dynamic will slowly, but surely, destroy the value of your product and lead you to create a mediocre product. No matter what you try to do, the estimates for features will drag you down to mediocrity. And the reason is simple and easy to understand: because it is so easy to do first what is considered “cheaper”. My advice is simple: focus on value first, and then figure out how to deliver that value as quickly as possible. Don’t estimate your way into excuses. Deliver it, bit by bit, incrementally.
Rethinking Estimates
Delivering value in minimum sized increments (also known as: Minimum Viable Product or MVP) is not just a trendy software development approach. It is a risk mitigation strategy that uses the Agile principle of delivering working software early and often for your business benefit: lower risk and more value. Estimating the whole Product Backlog up front does not reduce your main risk: business risk, also known as the risk of delivering the wrong things. But having the right prioritization will. What this means is that you should invest your time in spotting the most valuable features in the Product Backlog that could constitute a first, rough, small version of the product (hint: ‘all of them’ is not the correct answer). Then make relentless progress in delivering the minimum subset of those features that will deliver the necessary value to your customers. Walking at Random The traditional approach to estimating a project consists of breaking the project into work packages, creating a list of tasks, studying dependencies, estimating every task, adding them all together to see when the project could be completed. When asked for a more accurate estimate, teams will estimate to an even finer level of granularity, perhaps estimating tasks that could be implemented in 2 or 4 hours. Then they add them all in order to have a more accurate estimate.
Estimation vs. Prioritization
But that is not the only way of doing things, nor the most advisable in many situations. Let’s say that you want to predict how the stock market is going to perform in the next ten years. You could go study each stock and try to figure out how it is going to perform, then add all performances together and obtain a 'grand total'. But no market analyst will advise that approach. Instead, what they would do is study how the stock market performed during the last 100 years, then see if we can use that in order to forecast performance over the next several years. What would this idea look like when applied to a software project? Let's say we conduct an analysis of the last 200 features and we end up with this kind of graph:
Let's say that you find that the average feature duration was 3 days, and there's a standard deviation of about 1.5 days. Now let's say that there's a new project coming in and it has 100 features. You probably don't know the size of feature 1 or feature 37, since you have not done any kind of estimation, just a functional definition. But would it be unreasonable to expect that these hundred features will require sometime between 300 and 450 days? Compare that to an estimate of 100 or 1000 days for the same features.
Rethinking Estimates
There are some situations where this forecasting can't be made, and those are the ones where there is higher variability expected in the next project because of a change in technology, team, customer representative… But in those cases, would a feature-by-feature estimate be more accurate, even feasible? Let’s do a thought experiment – a Gedanken or Gedankenexperiment. Ángel Medinilla, this book’s fantastic illustrator, calls this the ‘Perfect Product Owner’ Gedanken. Imagine a perfect Product Owner. This Product Owner has the mutant superpower of being able to divide any project into stories of only 3 relatively small sizes. For every story size, there’s a statistical outcome in terms of how long does a team need in order to finish it – like, for example, small stories are finished in one to three days, medium stories are finished in three to six days, big stories are finished in six to twelve days. We don’t know up-front if a story is small, medium or big – we only find out when it is finished and we realize how long it took us. If this super Product Owner existed in reality he would produce stories so that: • •
•
There would be nothing bigger than ‘Big’. Sizes would be coming randomly – e.g. not all the small stories are at the beginning of the project and all the big ones are at the end. Even not knowing if the next story would be small, medium or big, the statistical distribution of the sizes would be constant and known over time.
So… Rethinking Estimates
You don’t know what’s coming next, but you can predict the overall behavior over time. If you were to create a histogram, characterize the statistical distribution in the form of a median and a standard deviation and, if a project is divided in 100 stories and the median is 3.5 days, with a standard deviation of 1.5 days, would it be crazy to say ‘it absolutely looks like a 350 days project, worst case 500’? The only “trick” we required in the Gedanken was a savvy Product Owner that is able to consistently divide projects into stories that are small enough. Even if you can’t perfectly determine what’s going to happen in the future; this ability to slice the work into “small enough” work-items or stories will give you a very high degree of throughput predictability.
So… Rethinking Estimates What are you really trying to achieve with the use of estimates? What's the intrinsic value of estimates? Can you really use estimates to accurately predict what is going to happen, when is the project going to be ready? How long each work-item is going to take? How much will the project cost? And how many people and what resources will be needed?
Rethinking Estimates
In this chapter you read about the concerns regarding the accuracy or value of estimates. Even if you estimate your project with great investment of time, those estimates will not help you manage the surprises that inevitably come up during a project, and in fact can make your work much harder if certain hard-dependencies cannot be resolved because of an error in estimation. Invariably plans fail, or need to change, and estimates must change with them. A better way to manage your projects is to acknowledge uncertainty, embrace change and fix the hardest constraints (time and people plus resources) while letting uncertainty be managed through a variable scope. Focus on delivering the most important part of your product early in the project and delay the less important and 'nice to have features'. This approach allows you to work on features identified after the project has started, when you find that these features are more valuable. This approach also allows you to drop features that might be considered less valuable, dedicate more time to the most valuable features and reduce scope of others. This approach has also been in use by many in the Agile community, and some call it "value driven" software development, as opposed to "scope driven" software development.
The Predictability Paradox “The best way to achieve predictable software development outcomes is to start early, learn constantly, commit late, and deliver fast. This may seem to cut against the grain of conventional project management practice, which is supposed to give more managed, predictable results. But predictability is a funny thing; you cannot build with confidence on a shifting foundation. The problem with conventional approaches is that they assume the foundation is firm; they have little tolerance for change.” Mary Poppendieck - The Predictability Paradox Predictability is the impossible quest of management. Predictability is important because we can base good decisions on what we know to be predictable. Predictability is what we seek, but how can we achieve it? And what does predictability really mean for a software project, especially one in crisis like Carmen’s?
CHAPTER 4
HOW NOESTIMATES CAN HELP YOU MANAGE A PROJECT IN CRISIS The project will be done in three months, give or take a week or two.” I remember saying these very same words in a top management meeting. The number – three months – was not arbitrary. It was the result of in depth analysis, task breakdown (yes, even I did waterfall in my day), and a lot of internal meetings to get people assigned to the project “at the right time”.
The managers in that meeting were happy. Very happy. This was also the number they wanted to hear. They were so happy they did not hear how I completed that phrase: “But only if everything goes according to plan. We have no buffer with this schedule.” This is not a unique situation. All of us that have managed projects have been in a similar situation. We’ve all been influenced by overt and
How NoEstimates can help you manage a project in crisis
covert expectations from our superiors. In some cases, we’ve also been in Carmen’s shoes, managing a project on which the company’s future depended on. A lot of sleepless nights follow. How can we answer this question? How to know when the project will be done without estimating all the work? That is the key question. (“When will the project be done?” can be replaced with “how much will it cost?” the process we go through is the same). Past approaches to estimation have not worked well, in chapter 1 I shared the data. At one of the companies where I worked, projects were, on average, 62% late. An average 100 day project would last 162 days! And even worse, several projects took longer (or much longer) than 162 days!35 Would you bet your company’s future on that kind of track record? I wouldn’t. And neither will Carmen. We need a better way to predict the end date (or final cost) for our projects that is not dependent on moody managers coming down and putting pressure on project managers to “improve” the estimates. Two months later… “Carmen, we have a review of the project with the Client next week. How are things going, what kind of progress can we show them?” Asked her boss. “Good Morning sir. Yes, we do have the requirements delivery and the Earned Value Management reports that I showed you just yesterday.” “That is great Carmen, but I was asking if we can show them working software. You know, to make a good impression.” Carmen felt the ground disappearing from under her feet. The requirements for this project had been written in a way that the software could only be demonstrated after most of those requirements were implemented. They were only two months into a 12 month development phase, there was nothing to show! The testers hadn’t even been hired yet. What could she do now?
35 Thank you to Troy Maggennis for helping me correct the conclusion in this paragraph.
The Predictability Paradox
“Sir,” she started, “you knew from the start that this was going to be a project with a long development cycle. It is quite impossible to show any working software until we have requirements implemented in all architectural layers. We only just started to develop the first layers like database, services, etc. We have nothing to show…” “I’m sure you can think of something for next week, you always do!”
How can Carmen show the real progress of the project? When requirements are written in a layered fashion, progress can only be assessed at a component level.
How NoEstimates can help you manage a project in crisis
More importantly, overall progress at the project level can only be assessed when all layers of the software have implemented a larger part of the overall functionality. How can Carmen show progress? She could count the number of requirements implemented; the costs incurred, and compare that to the baseline that she created when estimating the project (how many, and which requirements should have been implemented by now? And how much money should we have spent by now?) But the truth is that these are very misleading measures of progress. Let’s look at an example. Here’s the graph from a project that followed the same implementation strategy that Carmen is following. Take a look at the number of open bugs found. If you were the project manager for this project, when do you think the project would be ready for release?
The Predictability Paradox
Figure 6 - Data from a project using Rational Unified Process (RUP), a linear process model. This represents the project bug, or defect-curves (cumulative open, Submitted, and Closed) at the end of development phase, and beginning of validation phase (phases are used in RUP).
That’s right, no one can say when that project will be done. In fact, we can see from the graph that all requirements were implemented long ago (the development phase already ended), but the number of open issues just keeps growing and no one in their right mind would release that software. If we batch (accumulate and delay) the fixing of bugs to the end of the project – which we have to do if we take the layered approach – we will not know the real progress until we start fixing those bugs, and very likely later than that. A simpler way to see this is: if you have a 800 man/hour project, and someone says that you have actually invested 400 man/hours, can you say with confidence that you are 50% done?
How NoEstimates can help you manage a project in crisis
Is there an alternative that Carmen can use? Yes! You have the #NoEstimates alternative that creates true visibility to progress in a software project.
Visible Progress The main goal of my approach to #NoEstimates is to help evaluate progress in a concrete – and easy to implement – way. There are many ways to specify a project. For example, we can start by doing a business analysis and create a requirements document. The requirements document can be useful in generating consensus on what the project should deliver, and what are the concrete problems you will tackle with the project. However, requirements – in their classical form – are not practical when trying to assess progress (aka progress follow-up). Remember the vertical vs. horizontal division of work graph above? If you have started (but not completed) 50% of the requirements in your project how far away are you from completion? Many people in the world today still think that work that is started (but not completed) is progress in a software project. That is wrong. Code (implemented requirements) is only a liability. It turns into an asset only when a user can create value with it!
Visible Progress
“Working software is the primary measure of progress” - From the Agile Manifesto Following this principle from the Agile Manifesto requires us to write requirements in a way that allows you to do two very important things: •
•
Requirements need to be written in a way that allows you to measure progress early and often during the project. Requirements need to be written in a way that provides you with the necessary flexibility to make decisions on what part of each requirement will be implemented later, when you better understand the system, and the business needs.
Let’s look at what happened in the example we started studying above:
Figure 7 - Data from a project using Rational Unified Process, a linear process model. This represents the project bug-curve at the time of release.
In the chart above you can see that development stopped about 1/3 of
How NoEstimates can help you manage a project in crisis
the way through the project. If you had asked the developers they would have said that at that point the project was almost done. After all, they already had implemented all the requirements they were asked to implement. In reality they were not even close to 50% completion. Here’s why: when you implement all of the requirements you have only completed a small portion of the work that needs to be completed for the functionality (or capabilities) of the system to be useful to the end user. When a developer says “I’m done” what they mean is: “I’ve coded in what I think is the meaning of the requirement you gave me.” After this work is done, you need to verify two things: •
•
First, you need to verify that the developer has the same understanding as someone else – typically a tester – who looks at the software from the customer point of view. Second, we need to ask the end customer if what is implemented really solves the problem that it was intended to solve.
Even in the best-managed projects the first of these verifications is often done too late, but rarely anyone cares about the second type of verification until it is truly too late to recover without major impact on project schedule, project cost or both. The consequences of the failure to execute these two verification steps are: •
•
You don’t have actionable information that allows you to effectively measure progress. Remember this: you are not done, when you think you are done, but only when the customer says you are done. When you finally find out that the project is late, you don’t know what can be dropped from the scope of the project (you may even have all requirements implemented like the example above). And even if you know what needs to be removed, you can’t remove it because all requirements are implemented and they depend on each other. The required functionality is implemented; it just does not solve the problems they were supposed to solve.
Visible Progress
With my #NoEstimates approach, I try to avoid these problems by using the following progress criteria which is based on work by many people in the Agile software development community: •
•
Always implementing independent Stories (more on that below). Stories are requirements (written in a specific format) that explain what is the problem the user of the software needs to solve. Following progress every day, not by milestone completion. In Figure 6 we see a project that is “feature complete” – one of the key milestones in most software projects still today – but has nothing that can be delivered. Here’s the key take away: progress in software is measured by running (it can be demonstrated live), tested (high quality and user-accepted) software, i.e. RunningTested-Stories. RTS, Running-Tested-Stories is the only metric
How NoEstimates can help you manage a project in crisis
that reliably describes the progress in a software project36. You can implement progress follow-up by delivering completely each piece of functionality (I call them Stories) in a way that fulfills the two criteria listed above. Here’s what the original chart above would have looked like if the project had been measured by the number of RunningTested-Stories delivered every day:
Figure 8 – RTS (Running-Tested-Stories) burn down for the project in Figure 2
Even if the Stories take longer to implement than one day, they should follow some #NoEstimates slicing principles: 36 Others in the agile community have used a similar metric. I have found the first reference to Running Tested Features (similar to RTS) from Ron Jeffries’ blog in 2004: http://ronjeffries.com/xprog/articles/jatrtsmetric/ And the first reference to Running Tested Stories from a presentation by Simon Baker in May 2006: (PDF) http://computertrainingcenters.com/wpcontent/uploads/2012/09/IntroductionToScrum.pdf
Actionable Information •
•
•
There should be no ‘huge’ Stories (e.g. in Scrum: bigger than half a sprint counts as ‘too big’ and should be split.) Several independent Stories should fit into a Sprint or a period of 2 weeks if not using 2-week Sprints or Scrum. Six to twelve Stories delivered in a 2-week period is a good rule of thumb. The statistical distribution of small-medium-big Stories should remain constant through an extended period of time - i.e., not having all the big items at the beginning of the project (like one story about “setting up infrastructure”) and then all the small ones at the end.
However, even if we follow progress the right way, we still need to prepare for surprises. Of course certain things will take more than we expected (remember Hofstadter’s Law?). So, following progress with #NoEstimates is not enough. We also need to have actionable information.
Actionable Information Actionable information is information that allows you to make decisions that positively affect the success of the project. It is information that is typically expressed in a way that offers a conclusion. For example: Because we only have 3 Stories implemented (RunningTested-Stories or RTS’s), but we should have 6 Stories implemented at this point, we must reduce the scope of this release if we want to deliver on time. RTS (Running Tested Stories) is the metric in #NoEstimates that allows you to act on the progress and manage the project to meet a particular release date. It is the equivalent to ‘Working Software’ in the Agile Manifesto, and hence it is the main measure of progress, the only one that really counts.
How NoEstimates can help you manage a project in crisis
In the case above we see a typical project delivery rate (in a burndown chart). By looking at the chart above one can easily see that the project presents some risks of missing the deadline, but is not in a critical situation. If your project follows a similar burn down trend, you know that you need to reduce the scope. Reducing scope can only be done if the work left in the backlog is independent from each other and from the functionality already delivered. The opposite of independent Stories in software is the concept of layered requirements. Layered requirements are requirements that build on each other (different layers of the architecture, for example) in order to deliver the necessary functionality.
What are Independent Stories? In the Agile World, User Stories were widely adopted very early on. But few understand the immense power of that tool. Stories should have a set of properties commonly called as INVEST37 : •
I: independent Stories are Stories that can be implemented
37 &ZS '3<$%& [RS[VR_b _T bWSX_YSX YV B_]] *PfS PRX Z_T PWY_b]S
INVEST in Good Stories, and SMART Tasks
What are Independent Stories?
•
•
•
•
separately without depending on other Stories. You create independent Stories by slicing the project into vertical requirements (Stories) that can be verified individually. N: negotiable Stories are Stories that define a very clear capability for the system, but do not dictate an implementation strategy, or very specific functional requirements. This property allows the development team to select an implementation strategy that best suits the project when the time comes to implement that Story, and allows the customer to be engaged in defining the detailed functionality later on based on the running demo of the software. V: valuable Stories are Stories that have a concrete value to the customer or user of the product being created. The opposite would be a story that helps the developer but not the customer. E: Essential, meaning that every story is absolutely required for the product to be viable. To be Essential, a story must not only be valuable, but it’s removal must make the product unusable or unsellable. Earlier INVEST definitions included ‘Estimatable’ in the sense that there would be some understanding and specific definition of the story that allowed us to cast an estimate if we wanted to. #NoEstimates focuses on value instead. The goal is to do only what is essential to the project’s success. S: small Stories are Stories that are well understood by the team and can be implemented in a short time frame. With the #NoEstimates approach I advocate that Stories should be between 0,5 and 1 man-days of effort. Establish that as your target, and slowly move towards that size. Your visibility to progress and quality will slowly increase as the size of the Stories decreases. To determine if a story is small enough I ask: “Tom, can you get this story done by tomorrow?” There’s a world of difference in this question, when compared to “Tom, when could you have this story done?” The first question is intuitive (some call in Flashtimate), and not a result of a detailed analysis of each of the component tasks for that Story. Another difference is that we don’t ask this from all Stories in the backlog, but only the Stories that we will start working on
How NoEstimates can help you manage a project in crisis
•
immediately. T: testable Stories are verifiable. They include, for example, a set of criteria that define when the story is done. These criteria are called Acceptance Criteria and expressed from the point of view of the end-user or customer.
INVEST Stories give the project team information and the tools necessary to actively manage the scope of the project because: •
•
•
Each Story can be dropped from the project without affecting the overall project delivery. Each Story is small enough and all Stories are typically pretty homogeneous in size, which means that you can focus on their value, instead of their cost when making a decision. Value is an important input for decisions (actions), and can be easily assessed by discussing the use/benefit of a particular Story directly with the customers/users. By making Stories small you also get faster feedback on the progress of the project. The long term rate of delivered RTS’s should converge to 1 RTS per team member per day. When the number of delivered RTS’s is zero for one team more than 1 or 2 days you know you have to act.
How does this help Carmen? Let’s take a look. “I need to find a way to measure the real progress of this project. All these requirements that are in progress really give me no information about what is actually ready to go, or what is just started. Where could I find ideas on how to measure progress?” It is dark outside, all her colleagues have left for the day, but Carmen is stuck. She’s been scratching her head to come up with a verifiable progress metrics for her project. There are only a few days left to the progress report meeting with the customer. A lot is at stake. “Hi Carmen! What are you doing here so late?” It was Herman. “But why is Herman here at this time?” Carmen asked herself. “Err… Herman, why are you here? Did you come back to do some work?” “No way! I value my private time!” He smiled, “I came back to pick up that #NoEstimates book that Jerome asked about last week. I have
What are Independent Stories?
another friend who wants to read the book and we were just downstairs having a few beers, so I decided to pick up the book immediately. When somebody asks, I want to give them the book right away, so they don’t have time to lose interest!” He winked. “Wait, #NoEstimates? What is that all about?” Carmen asked. “You don’t know? Oh my god! You are working on Big Fish, you absolutely must read the book. Do you have a kindle?” “Yes…” “Right, go to Amazon and buy the book immediately. Check chapter 4 today, before you go home. It is an easy read – the author created a very good story that helps follow the concepts in a fast-paced manner. Read chapter 4 and let’s talk more tomorrow. Have to run now.” Herman left to meet his friend. Carmen was interested and checked the book, bought it and started reading Chapter 4. “Running Tested Stories…” She repeated while reading the book, “can I apply this to my project? It seems like a good way to follow progress, and I can see the similarities to the Earned Value Management ideas I’ve used in the past. But where should I start?” Many projects have only a list of requirements as the definition of scope. If you want to use RTS’s as a way to measure progress you must define the capabilities of the system in the form of INVEST Stories. Remember that each Story must follow the INVEST properties! Once you have a list of RTS’s for your project, you can then plot the progress of the project by completing each INVEST Stories in order of priority. How did Carmen do it? Let’s watch. “I have to count the RTS’s we’ve delivered so far… How can I do it? I know! I’ll list the requirements that are expressed as functionality into a list of INVEST Stories. Then I’ll group each of the other requirements under the relevant Story. If some are left, I can create more Stories for each of them. Let’s get to work.” Many, many hours later… “Great! I have my first list of INVEST Stories! “The project feels so much clear now.” Carmen felt she had just climbed Mount Everest on a clear day. And what she saw was an amazing landscape. She could see her project clearly for the very first time! “Now to plot the progress,” she thought. Carmen started to analyze each Story to classify them into “done” and “not done”. After some more hours of detailed analysis and
How NoEstimates can help you manage a project in crisis
searches through her inbox she came up with this:
“Flat line…” She could not believe her eyes. “So much work has been done in this project, so much has been invested and no RTS progress… We’ve written many, many pages of requirements documents, test specifications, design document. We’ve spent countless hours in meetings making decisions that will affect the project. But the RTS count tells us that we have no progress. Nothing to show for all that effort!” Carmen did not say what was in her mind out loud, but her body language said it all: the shoulders dropped, her eyes looked gloomy and she sighed. She was the image of frustration. “What can I do now? Why haven’t we delivered any RTS?” It was too late to answer those questions. She only had time to dash home, take a quick shower and come back to the office in time for the weekly progress review with the project team. Later that day… Carmen goes through the progress using the Work-BreakdownStructure and the Earned Value Management 38 presentation she had 38 More on Earned Value Managment: https://en.wikipedia.org/wiki/Earned_value_management
What are Independent Stories?
prepared. The audience was mute. Very few questions were asked. After all the information was “neutral”, there were no big visible disasters in the project. A few questions were open, but nothing that the project team was not familiar with. But then… “However,” Carmen continued, “after reviewing and redoing the project plan for many hours during most of last night, I found that the progress reports we are using are completely inadequate to show us the real progress of the project from our customer’s point of view.” She waited to see the reaction of the audience. Nothing. Just silence and puzzled looks. “What do you mean?” Finally asked her boss. “Well,” started Carmen, “the fact is that our requirements are indeed being implemented. We do see progress from an EVM point of view, but…” “But what?” Insisted her boss. “But, the truth is…” Carmen hesitated. “The truth is that we have nothing actually running that we could show the customer in the progress meeting next week. We have many requirements implemented, but if we look at the project from the point of view of the end-user we have nothing, really nothing, we can show!” “How is that possible?” The whole team asked in unison. Carmen continued. “Remember when we reviewed the requirements document back when we were creating the bid? Herman asked us, how we knew we were done with each requirement. And we answered that we would know when we would put them all together for the first system testing rounds, right?” “Yes, but I’m not getting your point,” commented a team member, “that is how we’ve always done it. And it worked!” “Correct, it worked before.” Continued Carmen. “But for this project we are being asked to report progress with running software every month. That is new. We’ve never had to do that before because most of our projects were small and we went from start to end without having to demonstrate progress.” Carmen stopped for a moment, and then decided to show them the RTS progress graph she created. The flat line was about to come out of the closet. She was nervous… “Here’s how our progress from a user perspective looks like.” Carmen showed them the same graph she had prepared during the early hours of the morning. Albert couldn’t be silent anymore: “How is that possible? I’ve implemented at least 10 of the requirements, and I’m only one of the 20 developers in the team!”
How NoEstimates can help you manage a project in crisis
“You are right Albert,” Carmen reassured him, “but the requirements you’ve implemented are all in the database and service layers. In fact most of the requirements we’ve implemented are in those areas. The fact is that we don’t have one single end-to-end capability implemented.” “If we look at the capabilities we need to deliver,” Carmen listed the INVEST Stories on the screen, “we can see that we have started working on five of the 64 capabilities we need to implement, but we have not finished any of them. Albert, tell me, how many of your requirements have been tested by Janet and her testing team?” “None, they are still writing the test specification,” replied Albert. “Exactly! We have done a lot of work, and we’ve started many things. But the truth is that we have finished nothing from our end-users point of view.” By plotting the progress of the project in RTS’s Carmen is giving her team: • •
Clear and verifiable progress information. Actionable information.
“Carmen,” started her boss, “what do you suggest we do now?” “That’s what I want to discuss with you and the team. I have an idea, but you all must be on board or it will not work.” Carmen explains her ideas to the team, and at the end they all committed to working as she proposed. “You have the go ahead, Carmen. But I want to see some progress by next week already or we will have nothing to show the customer!” Finished her boss. How do you recover from a situation like this? How can the use of #NoEstimates help get a project on track? That’s the topic for the next chapter.
CHAPTER 5
THE FAST TRACK TO NOESTIMATES “You’ve reached Herman, how may I help you?” “Herman, hi! It’s Carmen.” “Hi Carmen. What’s up? Are you at the office?” “Yes, I meant to ask you if we could … Er… have a chat…” “Sure, when?” “Right now?” “Wow. Must be something important.” “Yes, it is…” Carmen said, sounding unusually serious. “OK, I’ll come right over.” Carmen had just left the meeting with her boss. The stakes were very high. She had committed to show progress in the project during the meeting next week. How can she define progress in a way that is actionable? How can she ensure progress in a project that was almost two months in, and had a flat line of Running-Tested-Stories (RTS)?
The Fast Track to NoEstimates
“Herman, I have a serious problem that I need your help with.” Herman stepped back and asked: “Erm, OK. What problem?” “I presented the RTS line for the Big Fish project to my boss. The line was flat. We have already spent almost two months on this project and have nothing to show for it” “You… you did what?” Herman looked shocked. “Yes, I finally read up on that #NoEstimates ideas that you have been talking about. I must confess I thought that was just airy-fairy stuff, but I did it. I applied it to my project. I broke down the requirements into INVEST Stories. I plotted the progress by Running Tested Stories (RTS) and the line is flat! What should I do now?” Carmen looked accusingly. “Well, why didn’t you ask me before doing that? I could have told you from the start of the project that your RTS line would be flat at least for the first few months. That’s how waterfall projects normally behave. A lot of work on developing separate horizontal layers of the software that, hopefully, at the end come together in actual running software.” Herman tried to explain. “I know, I know. You told me that same story many times. But now it is a real project…” Carmen stopped. “I’m sorry Herman, I did not mean to say that. I’m just stressed out. My boss allowed me to use your #NoEstimates approach, but now I need to show progress in 1 week!” “OK, let’s start from the beginning, Carmen. Describe the situation to me.” Carmen explained the project situation, just like she had done minutes before to her team. Herman looked concentrated, asked a few questions and then stated: “Looks like you need to start cutting scope out, or at least delay work to the second delivery later this year.” Herman looked convinced. “How can you say that? I mean, we just worked on this project for a few months, the whole project may take a lot longer. It’s just…” Carmen hesitated. “Just what?” Asked Herman. “You need to be honest with me! I can’t help you if you don’t tell me what is at stake.” Carmen needed Herman’s help. Herman had been managing projects for at least as long as she had. And he had applied #NoEstimates in all of his projects. Sure, all his projects were relatively small because no one would trust him to manage a large project on account of the unorthodox #NoEstimates approach he used. But the stakes were high and Carmen’s mentor, her boss, was not a viable alternative to ask for help right now. Not after she made the strong statement about progress earlier that day. Carmen decided to tell him everything. Once she had told Herman everything…
What are Independent Stories?
“Wow, that’s heavy stuff!” Said Herman and sighed. “Anyway, I know you need my help, so let’s get to work.” “But, you have your project ongoing, don’t you need to check your calendar?” Asked Carmen, not believing her luck. “My projects are easy, the teams have a clear way to check progress and they can make scope decisions without me. I’ve built a system for them that they can easily use. The truth is that most of my projects run very well on auto-pilot.” Said Herman with a wink. “This project however… Let’s just say that it will be a challenge to get it on track, but I believe believ e we can ca n do it.” Herman picked pi cked up a piece of paper and started start ed asking questions. question s. Herman wants to help Carmen, but before he can do that, he needs to understand what is at stake. Both in terms of project delivery as well as short-term customer relationships. Here are the questions he will ask Carmen: • • •
•
•
What are your intermediary deliveries going to be used for? When does the project need to go live with the first release? What does the customer expect to accomplish with that first release? How many, and which, Running Tested Stories (RTS) do you need to deliver until that first release? How many RTSs have you successfully delivered during the last 2 months (the length of the project until then)?
With these questions Herman is trying to establish the following: •
•
What is the most important value to be delivered by the project from the customer’s perspective? This may include a significant cost-saving functionality; a new Feature that will make the product win awards, or something somethin g that is otherwise otherwis e significant signific ant for the customer. What is the amount of work that needs to be completed in number of Stories to be delivered? Note that without the INVEST properties for each Story we could not use the number of Stories to assess the delivery rate or assess future progress. If each Story is only complete when an arbitrary number of other Stories are delivered, then all those Stories need to be delivered
The Fast Track to NoEstimates
•
before we see progress. progre ss. When should the next delivery of the project happen? Delivery means something that will go into use by the customer. You may have many project deliveries during the whole length of the project, but those will be internal or testing testi ng deliveries. delive ries.
With the answers to questions 2 and 3 we can build a progress “yardstick”. For example, if you have 10 weeks to the next delivery and you have 20 Stories that should go into that delivery, you know you need to deliver an average of 2 Stories per week to make that delivery. If you deliver less, you should then evaluate the scope and make the necessary reduction. If you deliver more, you are on target and may be able to deliver more functionality at the end of the 10 weeks. However, the first question about the purpose of each release is the most important. By understanding the goal of your customer you will be able to “steer” the delivery by evaluating, prioritizing and ultimately removing Stories from that delivery. Without an answer to the first question, the most important tool for the #NoEstimates practitioner (scope management) will not be available.
What are Independent Stories?
“Wow, we have way too many things to deliver for the first delivery! No way I can show this graph to the customer c ustomer when we w e have the t he progress progre ss review next week. He’ll think we haven’t done anything!” Carmen had just realized realize d the t he extent of the project delay. There were too many Stories to deliver, even for the first release! Especially when she considered that she had zero RTSs delivered deliver ed so far because of the layering layerin g of requirements and implementation. “But the first action that you need to take seems clear Carmen,” said Herman, and a nd waited waite d for her reaction. reaction . “Is it? I can’t see what to do, I feel overwhelmed,” replied Carmen. “That’s OK. It’s normal to feel overwhelmed. After all, you just discovered that your project is in jeopardy. But now you know that you don’t have visibility to the rate of RTS delivery,” tried to lead Herman. “Precisely! I don’t know what our progress rate is because we haven’t yet delivered a single RTS, we’ve worked in many requirements, we’ve worked for months and have nothing to show for it.” Carmen was frustrated. frustrate d.
The Fast Track to NoEstimates
“Don’t despair Carmen. This is not good news, but it is actionable information.” “Actionable in what sense? I don’t get your point.” Carmen sounded angry. “You know that your first action should be to find what is your project’s rate of progress,” – Herman said, “until then you are flying blind, so to speak.” “Right, but how do I do that?” “We need to get your Stories to be small enough, the current Stories are too large to give you any insight into progress. We have to make those Stories smaller. What Stories are already in progress?” “These here at the top of the list, I’ve highlighted them,” said Carmen, while pointing to the list of Stories she had created the previous night. “Right, let’s make sure those are small enough. We’ll worry about the rest later” “And how do I do that?” “Simple. Take this first one: As an enrollment nurse, I want to add the health record of my patient to the database, so that the doctor can later read the answers to the questions we ask when the patient arrives to the hospital.” “How would you break that down?” Asked Carmen curiously. “I mean it can’t be smaller than that, right? That’s a pretty simple Story, and it will probably take multiples weeks to get it implemented because we have the UI team involved, then we have to run some tests with the nurses, and the doctors. Then we have to run a live test, whereby a business analyst will actually be at the hospital to play the role of the enrollment nurse and test that the system actually works, etc.” “Wow, calm down, you’ve covered many things already that we can use to split this Story. Let’s take them one by one. Do you really need the UI team involved before you start designing a UI for this functionality?” Asked Herman.
Slicing User Stories to Assess Progress and Manage Scope During the conversation that follows Herman will help Carmen slice the User Story she just read into smaller, runnable, testable Stories. The most important attribute of those Stories is that they be small. How small? That depends on your need to assess progress. If you need to assess progress every day in a project that lasts a few weeks, for example, then your Stories should be completed at the rate of several per week. As an example, you could aim to have about 1-day time boxed
Slicing User Stories to Assess Progress and Manage Scope
Stories, so that every day you can see that some Stories are delivered (or not!), and everyday you can assess progress. If your project is several months long, then assessing progress every week may be enough and your Stories may be time boxed to a few days (say 2-3 days). Here’s a story of how my friend Ángel Medinilla used some of these concepts to save a failing project: I have a personal experience with an 18-month project. There were 30 people in that project in three different teams. When we looked at the data we saw that there were between 1 and 3 Stories delivered by every team in each 2-week period. Even though there was some variation from week to week, a consistent average of 5 to 6 Stories were finished every two weeks by the three teams. As we compared that to our backlog (which contained about 300 Stories) we realized that there was an obvious risk of not delivering 90 to 125 Stories over the next 35 sprints (2 week periods). So we decided to focus on the most important 200 or so Stories as soon as possible. After prioritizing the 200 most important Stories we just ourselves: “does this Story feel like it could fit into a 2-week sprint?” If the answer was yes, we took it in, if not, then we broken it down further. This was what some will call “blink estimation”, and it worked for us in that project. Not much time was wasted in those conversations; the goal was to get started doing the work to assess if we were indeed able to deliver that Story in 2 weeks. Nine months into the project, a working version with roughly 120 Stories was available. The company decided to go live and the project was stopped while the company re-planned and focused on a more important project with Features that made more sense than the ones that were identified and committed a year ago. There are a lot of lessons to be learned from this story! Ángel is right, this short story has many lessons to be learned. One such lesson is that it is only when we start working on a Story that we actually know how long it will take to deliver. Another lesson is that breaking down Stories helps us assess progress at the project level faster, and make the necessary (and inevitable) scope
The Fast Track to NoEstimates
decisions. Not all Stories are critical for any project. Discovering which are, and delivering on those is where the value really is. Finally, having a consistent rate of progress is more important than estimating a project. This consistent rate of progress will help us steer the project in a very concrete way: reduce work or re-prioritize work based on actual progress data, instead of a guess at a plan that will invariably change. This consistent rate of progress will be a key tool for Carmen as well. In her project, Carmen had to deliver visible progress information in 1 week therefore she did not have the luxury of waiting several days to complete one Story. Her goal was to deliver several Stories that week so that she could show progress as well as assess the time it takes to deliver multiple Stories, which would in turn help her forecast future progress. Slicing Stories to be small enough is a critical skill upon which successful software projects build. There are many techniques that you can use to achieve a decomposition into INVEST Stories that are small enough for your needs. In this example we will take the Story at the top of Carmen’s backlog to explain some of the techniques.
Slicing User Stories to Assess Progress and Manage Scope
1.
Slice along functional dependencies
In the Story above Carmen mentions a dependency on user interface design. This is a classical example of functional dependency where one team (the developers/testers) is dependent on the work of another team (User Interface specialists) before they can complete the work. We can slice the Story so that we create a clear division between those two types of work or functional expertise. If we were to use this technique the resulting Stories would be •
•
First, the original Story now without a dependency on the UI: As an enrollment nurse, I want to add the health record of my patient (using the draft user interface), so that the doctor can later read the answers to the questions we ask when the patient arrives to the hospital Then, the second Story with the dependency on the UI: As an enrollment nurse, I want to have the User Interface optimized for information input when I add the health record for my patient, so that I can concentrate on asking questions and documenting the answers.
Note how the first Story can be completed without involving the User Interface specialists, and therefore be quickly completed; while the second Story focuses on the role of the User Interface design for that
The Fast Track to NoEstimates
particular user (optimize for information input)39. The second Story could focus on reducing the “movement” needed to introduce information by, for example, designing an interface that guides the nurse through the enrollment process in a way that does not require the use of a mouse.
2.
Slice to separate quick from time-intensive functionality
Another possible division of the original Story is to separate the quick implementation aspects from the time-intensive ones, in order to be able to complete part of the work by separating what can be done quickly from what requires a longer implementation cycle. In this case we could assume that the database – which is used by the existing legacy application – will require much more work to be completed, so we may decide to separate the input (data entered by the enrollment nurse) from the database persistence strategy (entering that data to an existing database that interacts with other applications beyond our control). The new Stories could look like this: •
•
As an enrollment nurse, I want to create the health record of my patient (using a temporary data storage), so that the doctor can later read the answers to the questions we ask when the patient arrives to the hospital. As a doctor I want the data that is entered by nurses when receiving a patient at the hospital to be available in the same application that I use for prescriptions, so that I can easily review patient information during the consultation.
In this division of the Story we see that the data entered by nurses is kept in a different storage solution (maybe a temporary database), and then we add another Story that changes the storage strategy so that the data is finally stored in the final database. This strategy for slicing may be useful if the operational implementation of database changes is a common bottleneck for the organization. 39 Editor’s note: It is worth noting that the ability to separate these stories hinges on skills like: Design Patterns; Automated Unit Testing; Software design; and others. These skills are usually not part of the skill set HR personnel look for when recruiting programmers. They are never part of the skill sets specified when consultancies and clients make business deals. The ability to slice stories hinge on a lot of other skills. This may cause problems if no one is aware of the need for those skills.
Slicing User Stories to Assess Progress and Manage Scope
This approach may add work to the project, however, it is also an effective risk mitigation strategy. When you follow this strategy, you may decide at some point to go live with the temporary solution (the temporary storage in this example), and later change the implementation, or pursue other high value Features instead. Not being able, or willing to use this strategy may lead your project into a death march: where you are committed to implement the permanent solution, but can’t deliver anything until such solution is ready. Add some dependencies to other functions (like the “storage team” in the organization and you have in place the ingredients for a death march.
3.
Slice along user/role separation
Not all acceptance criteria need to be included in one Story. A strategy for slicing may be to explicitly exclude some of the user-specific acceptance criteria into a Story to be implemented later so that we can quickly show progress and receive feedback. The remaining Stories can be added to the backlog and prioritized accordingly. One example is the live test that Carmen referred to in her explanation, as well as the changes we expect to come from that live test. Implementing this slicing heuristics could give us the following Stories •
•
As a nurse lead user (a user that tests the product for the nurses), I want to add the health record of my patient, so that the doctor can later read the answers to the questions we ask when the patient arrives to the hospital. As a enrollment nurse (the actual nurse at the hospital), I want to have an intuitive and quick input method for the information I collect from the patients, so that it is comfortable to enter information even in time-critical patient situations.
In the example above we’ve introduced a few concepts (nurse lead users and time-critical patient situations) in order to separate out the aspects that affect the applicability of acceptance criteria. By separating out the performance and user interface optimization into a different Story, we are able to deliver some work without performing the live test, one of the original acceptance criteria. Another possible approach would be to separate the mandatory form (without which data could not be entered) from the final form design implementation. You can start by tackling the basic database operations, and later on invest more time (if you have time) in improving the user interaction design for the form. While the final design may significantly
The Fast Track to NoEstimates
improve the functional value of the application, you may still go to market with the initial implementation, and later add the necessary changes. This approach has the advantage that you will have feedback from the users and will therefore understand better what needs to be improved with the new design. On the other hand, if you run out of time, you can still go live with the original implementation, significantly reducing the risk of not being able to deliver the product to the market.
Other Slicing Heuristics There are many possible slicing heuristics that you can use to take a large User Story and slice it into manageable, and most importantly, progress uncovering parts. As an example, you can slice following your user journey steps (login, search, select, modify, accept, etcetera); you could use different scenarios, roles, or personas; you could slice according to input/output data; you could divide according to complexity, interfaces, current level of knowledge, test case. And the list goes on. Even when a Story looks like it can not be divided further, there is always a way to bring it down to smaller, independent pieces that can be developed and tested separately, giving you a better idea of progress than the amount of hours you’ve put into a Story versus the “estimated” effort to complete it. If you estimated 40 hours and you’ve put in 4 hours, can you really say that you are 10% done? On the other hand, if you divide the Feature in ten separate slices and you complete two of them, that’s a far more tangible progress indicator.
Other Slicing Heuristics
“Working software is the primary measure of progress.” Agile Manifesto The most important aspects of slicing are: •
•
Each slice is independent (the I in INVEST). In other words, each Story can be delivered independently from other Stories, and accepted on its own. Even if each Story may not be “sellable”, it must be testable and final, i.e. the team can make sure that a particular User Story has been successfully completed according to a Definition of Done. This Definition of Done is a litmus test that will allow you to classify tiny parts of the whole project as completed, before the whole project is done.
The focus on completing thin slices of functionality every day (or as often as makes sense for your project) is what allows you to collect the progress information you need to assess progress in your project, and therefore show progress towards the final goal. Early in each project, your top priority is not to ship something meaningful to your customer, but to obtain information on capacity, throughput, and backlog size. If you are able to slice your Stories so that you can deliver 1 or 2 Stories per day, that will dramatically increase your ability to both track, and steer your project! But even if you are not able to reach this state, being able to deliver multiple Stories per team for every iteration (in many cases iterations are about 2 weeks long) is also a good start to reduce your estimation needs and have more tangible progress information.
The Fast Track to NoEstimates
For more heuristics on how to slice Stories and some examples, look at the resources at the end of the book and the links to blogs and sites that explain how other people are able to slice large pieces of work into thin slices of functionality. Now, let’s get back to our story. “But Herman, now that I have these 10 small Stories instead of the one we started with I still have a problem: I don’t know how much time all the rest of the work will take! This was only one Story!” Carmen was not convinced. “Absolutely correct! In fact you will not know how long the whole project will take until you have either the whole backlog of INVEST Stories sliced up (a bad idea) or until you have enough historical information that you can infer the cycle time for every backlog item, independently of size,” Herman explained. “Oh, do you mean that this slicing of one Story is just a way to have visible progress for this one Story, but not for the whole project?” “Yes!” Herman answered. “But I need to know the progress at the project level, not just for this Story.” Carmen was still not convinced. “I understand Carmen. But before you can assess progress for the whole project you need to first understand what is the throughput of your
Other Slicing Heuristics
project. In other words you need to know how many of those INVEST Stories you created last night actually get delivered in a week.”
“OK, let me see if I got this. I will work with the teams to implement these thin slices of my INVEST Story; by the end of the week we’ll have an idea of how many slices of an INVEST Story we can deliver.” “Correct!” Confirmed Herman. “And then I’ll just guess how many thin slices each of the other INVEST Stories has? Isn’t that estimating?” Carmen asked. “Not really, but that is something we need to cover next,” continued Herman. “Right now the most important step for us is to get your project to show some progress. The data we get when we show progress will help us to predict or forecast future progress, but we will need more of those INVEST Stories to be delivered before we can be sure we know the actual progress rate.” “But doesn’t that mean that – even if we deliver a few of the slices we just created – we will not know when we will deliver the Features we need for the first release?” Carmen was puzzled. “The idea with #NoEstimates is that you should focus on value, and use the available data to forecast future progress. But the first step is to focus on value to be delivered. Once you are clear on the value you need to deliver you should then worry about forecasting future progress. The first question is: what is the most important piece of work we need to
The Fast Track to NoEstimates
deliver now? You just answered that. Let’s focus on that first and talk again tomorrow,” Herman stated. “I have to run, meet me for breakfast tomorrow morning, we’ll look at the rest then.” Carmen was not happy, but she trusted Herman and was happy to have been able to slice the INVEST Story – which seemed huge – into smaller items that she was confident the team could deliver in a shorter time. Her next step was to get the teams to start on the thin slices of functionality she and Herman had just defined.
Determining Progress from Historical Data Carmen asked some very important questions: how to assess progress when we actually break down an INVEST Story into smaller, thinner slices? After all they are not the same size as the original INVEST Stories and those slices may not even be “sellable”, i.e. ready to go into production. The lack of historical progress information is a very common obstacle when applying the ideas behind #NoEstimates. We don’t always have enough historical information that we could use to model the future progress of a particular project. The reasons are varied: we may not be working with the same technology; we may not be working with the same team; we may not have a stable team; we may never have used small increments; we may have only used waterfall in the past, etc. This is why it is important to start collecting historical information now. Don’t wait for tomorrow, start collecting information about your project’s progress and use that to forecast progress as soon as possible? How soon? As the proverb goes, “the best possible moment to plant a tree was twenty years ago; the second best moment is now” In my research I’ve normally used the progress data from 3 to 5 iterations (or weeks if you are using Kanban/flow based software development) in order to define the initial progress rate. Many expect that you need many more data points before you can make a useful prediction, but that is not the case. Three to 5 iterations are typically enough.40 40 Thank you to Troy Maggennis for highlighting how important it is to recognize that a small number of data points or samples is enough for us to be able to make useful predictions regarding future progress. For more on the problem of inferring a discrete uniform distribution through sampling see the German Tank Problem entry in Wikipedia, which explains that the use of sampling and statistics can improve on human estimates: https://en.wikipedia.org/wiki/German_tank_problem
Determining Progress from Historical Data
In one project I took the information from the first 3 weeks (how many RTSs were delivered to a production-like environment, also known as the project velocity or throughput) and merely extrapolated that to the rest of the project. The average velocity multiplied by the number of sprints we had available in that project gave us an indication of the total amount of RTSs that we could deliver during the full length of the project. Below you can see a graph detailing the number of Stories delivered in every one of the 21 iterations for that project.
Figure 9 - Run chart of Stories delivered by one team in a long (21 iterations) project. Notice how useless it would have been to set a target of 10 User Stories for this team...
In this project the average velocity during the first three weeks was enough to predict very accurately how many RTSs the team would deliver over 21 weeks. In your project that may not be the case, so you should constantly update your forecast based on the latest information you have. The graph below shows a shorter project where the first three iterations (not weeks in this case) could not be used to reliably predict the number of RTSs that project would deliver. However, as the project progresses we see that the velocity stabilizes. By updating our forecast based on the latest data available, we progressively become more accurate in our forecasting.
The Fast Track to NoEstimates
Multiple Levels of Granularity In Carmen’s project we have multiple levels of granularity. Carmen was able to divide the project requirements into somewhat large INVEST Stories; which we call Features because they cannot be delivered in a 2week or Sprint timebox. Together with Herman, Carmen was able to further divide each Feature into smaller INVEST Stories; which we will call Stories or User Stories. User Stories are constrained to be delivered in a period of 2-weeks or a Sprint in Scrum. In my practice I advise that Features be given a mandatory, maximum calendar duration of around two months depending on project size and calendar duration. The smaller Stories should also be given a mandatory maximum calendar duration: I like half-day to one-day because it helps teams find and solve execution bottlenecks on a daily basis. But your mileage may vary. In any case, a User Story should not be allowed to grow bigger than about half the length on your iterations (a common iteration size is two weeks).
How Do I Mandate the Size of a Feature or a User Story?
By establishing these different levels of abstraction for requirements you will be able to gather progress information at different levels. You will be able to ask and answer the questions: •
•
How many User Stories can a team deliver on an average week? (The User Story velocity). How many Features can our project deliver on an average week? (The Feature velocity).
Both these metrics will help you forecast the progress for your project. While the User Story velocity metric will help you assess when a certain Feature might be ready; the Feature velocity will help you assess when the project might be ready.
How Do I Mandate the Size of a Feature or a User Story? “Work always expands to fit the available time”, states Parkison’s Law. Parkinson’s Law is not the only example, we have many other quotes and phenomena that basically describe the same thing: when it comes to knowledge work, it will always take at least as much time as you’ve allocated it to take. In statistical terms, if you plotted the duration of all tasks in a project it would create a histogram similar to the one below.
What this means is that, even if you estimate, you are very likely to
The Fast Track to NoEstimates
get it wrong and chances are you will get it wrong by under-estimating the work that needs to be done.41 Because we are more likely to underestimate the duration of a task, the delays in the project continue to accumulate even if some tasks are finished quicker than estimated. How to avoid this phenomenon? Wrong question. We should instead focus on defining work based on how much time we think it should take. For example, if a project were likely to generate a maximum income of $100,000 it would be a bad idea to spend more than that to implement it, independently of what your estimates say. When it comes to following progress for a project this concept is applied by hard-limiting (time boxing) the duration of certain parts of the work. If all Features take one month to deliver (by definition or time box) you know that in a year you will deliver around twelve Features (assuming you work in one Feature at a time). The project may deliver a few less Features, or a few more Features, but close to twelve. However, if instead you try to estimate the Features to take 1 month you will be a victim of Parkison’s law, which dictates that each Feature will most likely take at least 1 month to deliver. Let’s take an example. When delivering an IT ticketing system (to handle requests coming in from the users of the services IT provides) we may decide to list a number of Features and then estimate their size. Alternatively, we may decide to list Features and not worry about their size. As long as all Features are increments of value for your customers, what matters is that you start immediately delivering that value. As the teams develop the Features, the Features are sliced into smaller Stories, with each Story being in itself an increment of value. When we get closer to the end of the mandated one-month Feature calendar duration, our focus will turn to making the Feature under development “sellable” (i.e. ready to be used by end-users), even if not all the functionality could be delivered. The functionality that did not fit the one-month mandated calendar duration for the Feature is said not to “make the cut”. This functionality may still be valuable or not. If the remaining functionality is considered to be valuable it is then grouped into one or more new Features (also with the same mandated calendar time duration), and added back to the list of Features to be developed. If, on 41 One significant reason for this large spread for task estimation is that we tend to estimate the actual work it takes to complete the task, but are unable to predict the time that task spends waiting to be picked up. In Chapter 1 we cite Troy Maggennis email where this phenomenon is further explained.
Why Should I Mandate the Size of a User Story or Feature?
the other hand, the remaining functionality is not considered critical, then it should be dropped from the list of work to be completed, or at least placed with low priority on that list. As we add the remaining functionality back to the backlog we will see the remaining work grow. This phenomenon is very normal and to be expected in software projects. In fact the work to be done in a software project will increase unless the project team makes a decision to actively remove work from the backlog. This constant addition of work to the backlog of a project is one of the causes for schedule overruns and even has a pet name in the software industry: “scope creep”. Of course, that name does not reflect the reality of software development. Adding work to the backlog is not “scope creep”, it is just a natural outcome of our constantly changing and improving understanding of the problems we need to solve with the software we are creating. Instead of “scope creep”, we should really use the term “value discovered”. Mandating the maximum calendar duration for an item is also used for User Stories. In my practice I advise teams to have 1-day User Stories. The reason is simple. If you were wrong about the time it takes to develop your User Story you will know it already tomorrow! And can therefore act to either remove the obstacles or reduce the scope of that User Story. Following this maximum allowed calendar duration for Features and User Stories requires practice in slicing larger pieces of work into small increments of value. Don’t be discouraged if at first you don’t succeed. Rather than increase the mandated size of a Story, practice slicing your User Stories more often, ask for help from a more experienced colleague or ask Google. Someone out there has already cracked that nut and can help you do it. See the resources at the end of the book for ideas on how to improve your skills in Story slicing.
Why Should I Mandate the Size of a User Story or Feature? There are several reasons for mandating small enough calendar duration for User Stories and Features. The most important one in our #NoEstimates context is that it will give you the progress information you need to be able to forecast future progress and deliveries. See below the Feature velocity graphs of two different teams, one that mandated the size of Features to 1-month and the other that estimated the size of Features instead as they were defined. You can see that the first graph provides regular progress information and a reliable metric for you to use in forecasting. While the second graph shows how Parkinson’s law impacts the relative unpredictability of progress.
The Fast Track to NoEstimates
Figure 10 - Plotting the velocity over time for two teams. Above: throughput for a team that explicitly limits the calendar duration of their Stories. Below: the velocity for a team that does not limit the calendar duration of their Stories.
There is no magic here. The reason limiting work to a fixed time works is simple: it forces you to increase the frequency at which you collect feedback, and evaluate progress. The moment you realize that a Feature or a User Story cannot be fully delivered within the allotted time is the moment you get to decide whether to accept that additional work or to discard it. That is a powerful moment in your effort to contain the project scope and focus on the most valuable work. Why wouldn’t you use it?
Extrapolating from User Story to Overall Project Progress “Herman, we are close to the end of the week and I wanted to review the progress with you before presenting it to my boss. Can you come
Extrapolating from User Story to Overall Project Progress
over”, Carmen asked Herman. “Sure, let’s review what you have.” Carmen and Herman were looking at a spreadsheet. The sheet showed the number of User Stories that were completed per day as well as the number of User Stories left to complete for the Feature under active development.
Figure 11 - Accounting for the Stories delivered within one Feature during an iteration. Notice that the Feature increases in number of Stories as time goes by, this is a very common scenario. Work is discovered as previous work is completed.
“Great! This is very valuable information!” Said Herman excited. “Great? Are you serious? We were not able to finish the Feature we started with this week. There are still 4 User Stories left even though we completed 9 User Stories out of a Feature that was thought to have 10 User Stories!” Carmen said expressing frustration. “Calm down Carmen. You are right, but you are not seeing what the
The Fast Track to NoEstimates
data is telling you.” Continued Herman trying to change the tone of the conversation. “Look, the team was able to complete 9 User Stories this week, that’s a rate of about 2 User Stories per day. That gives you an indication of what is the capacity of the team at the moment. All other things being equal you can trust that the team will continue to deliver around 2 User Stories per day. Some days it may be zero, and other days it may be three or four, but this is valuable information.” “But I don’t know how much work is left. How many User Stories does each of the Features to be developed have? I don’t know.” Carmen was not impressed. “That is correct, but let’s review our goals for this week. We wanted to show progress. Here you have it! You have software you can demonstrate to the customer and you have a pretty good understanding of how much software you can deliver on a regular week. We have to expect that this User Story velocity will change. If the team, the technology or any other key factor in your project changes your velocity will change. That’s normal. But you have a ball-park figure that helps you forecast progress.” Herman continued, convinced of the value of the data collected. “But Herman, I need to show progress at the project level. All I have now is progress at the Feature level.” Carmen pointed out. “Correct. You can only show how long this one Feature took and is likely to take. However that information is valuable for the project as well. As of today you can assume that every Feature in the backlog will take between one and two weeks to deliver.” “No I can’t!” Carmen interrupted. “We’ve worked only on one Feature, which is not even completed.” “Sure, but you can speculate based on that observation. Right? I mean when you look at the backlog, do you think this was the lowest effort Feature you have in the backlog?” Herman asked. “No, this is by far not the smallest Feature.” “Is it the highest effort Feature you have in the backlog?” Continued Herman. “No, this is quite large, but not the largest.” “There you go! Now you can speculate that this Feature is somewhere in the middle, which gives you a good range for all the other Features. Let’s assume, for the sake of argument, that this Feature is about average in effort. Now you define an interval for the other Features. Let’s say Features will take anywhere between one week and three weeks to deliver. Take those numbers and multiply them by the number of Features you have in the backlog, what do you get?” Herman waited for Carmen’s answer.
Extrapolating from User Story to Overall Project Progress
“Well, making those assumptions I could say that the Features we have left will take anywhere between one year to deliver to four years – which is unacceptable!” “Wait!” Herman interrupted, “you are going too fast. Even in the case of one year being too much you have not yet applied the most important tool you have as a Project Manager.” “What’s that?” Carmen was puzzled. “Scope Management!” Herman waited for her reaction
“Are you joking? How can Scope Management help me when even the lowest end of the interval is too much?” Carmen was not impressed. “Good point. But you are talking about Feature progress information. Don’t forget that each Feature itself can have its scope managed, so that even if you can’t remove some of the Features in the backlog you can manage what each Feature will include in order to meet your target schedule,” Herman continued. “Oh, I see! What you are saying is that I should forecast progress based on the data at different levels of granularity. At User Story level so that I can manage the scope for a Feature and at the Feature level for the project…” – Carmen explained. “Yes! Now you are getting the hang of it.” Herman continued, “the idea is that you have to collect the information you need to make
The Fast Track to NoEstimates
significant project decisions, and as you know, scope management in a project is one of the few things the project team really has power over; especially if the team can forecast progress during the early days of the project. After all, the customers are never happy to drop Features or even Story-level functionality at the end of the project, but I’m sure they will consider your suggestions if you bring them early enough in the project.” “Yes, of course. Now I understand what you mean by ‘showing progress’. You actually meant that we have to show enough to help us forecast future progress against today’s backlog so that we can see if we are over the schedule at all times!” Carmen looked happy. Herman continued, “yes! And now you can bring actionable information to your boss when you review the progress of this week! The first question you should ask yourself now is how many Features you would need to cut out of the backlog to be reasonably sure, according to your forecast, that you can deliver the first release on time.” “Great! Thank you Herman, now I need to go prepare the presentation.” Carmen left the room with decisive speed. Here some of the key takeaways from Carmen’s story so far: •
•
•
Use multiple levels of granularity to establish flexible requirements. Use historical data to assess progress and forecast future delivery. Cost is a multiplier of time (mostly); the only real variable the project team can control actively is value (in the form of scope).
1-2-3: Step by Step Towards #NoEstimates As with any important change in the way you work, bear in mind that moving directly from a traditional estimation-based-plan environment to full #NoEstimates approach will be risky most of the time, and perhaps not advisable. This is the second reason we considered the idea of giving you a step-by-step guide. So please, keep in mind that the list below includes some specific steps you can follow in order to explore how many estimates you really need in order to plan and manage your projects. 1. Move to Story Points . Even if this is just another way of estimating, getting rid of ‘hours’ and ‘days’ has too many benefits to ignore them. We already discussed previously in this book the problems of using time-based metrics, which are an indication of
1-2-3: Step by Step Towards #NoEstimates
2.
3.
4.
5.
6.
cost, to measure project progress. Even if it’s just another proxy metric for productivity, Story Point-based estimation gives a better understanding of how things like risk, complexity, expected dependencies for each Story, etc. Given that a large amount of time it takes to deliver one Story is spent waiting, Story Point estimation is more likely to help you assess the true impact of one Story in your project. Stop estimating tasks . One of the saddest thing we witness in planning meetings is a team casting an estimate for a Story, dividing this Story into tasks and then casting estimates for each task, adding them all and seeing if the number matches the original estimate for the whole Story. Instead of that, just don’t create sub-Story tasks or, if these are valuable for team synchronization – knowing who needs to be doing what – just stop estimating them. For progress reporting, just ask the team about the Story progress – did we progress well yesterday? Can we complete the Story today? Limit the calendar duration of Features and Stories. For Stories, specifically you should aim for one, maybe two days of calendar duration to finish each Story. Even if this is not easy when you try for the first time, this approach will give you concrete benefits. For example: any Story started at the beginning of an iteration that was not finished by the end of the iteration is showing an organizational impediment that you should investigate further. If you are already using Story Points, remove some ‘planning poker’ card options. Start by asking team members to rate everything either as a 1, a 3 or an 8. This means that anything bigger than a 1 is a 3 – this avoids the “is it a 2 or a 3 point Story?” discussions – and anything bigger than a 3 is an 8. Anything bigger than an 8 should be sliced. Slowly decrease the options. For example, use only 1 and 3, and soon you will be able to ask a simple question: “can we get this Story done by tomorrow if we start working on it today?” Build histograms. Keep track of your average duration for Stories and Features. Simply record the day the team starts to work on each Story or Feature and the day that Feature or Story is complete. This information can later be used for progress forecasting. Use the average cycle times for Stories of different size to start producing Story-based forecasts. Count how many Stories go into every sprint and make a histogram-based forecast of how long will it take. Use it also to forecast small projects (one to three months) that can be sliced into small-medium-big Stories. If you can prove these numbers to be at least as reliable as the estimations you gave,
The Fast Track to NoEstimates
7.
you’ll have the case for #NoEstimates right in front of you! Finally, work with Stories as if they all had the same duration . Simply count Stories and project progress based on how many Stories the project was able to deliver in the past: average Stories delivered per iteration or per week.
Try each of these steps in your own project. Some steps will be easier, but when you find a step that is hard to implement ask “why?” In some cases the requirements will be the impediment – maybe they are still horizontal requirements? In other cases the hard part is to learn to slice the Stories. In fact, slicing Stories is probably the most effective tool to manage scope, and very few projects are using this approach effectively today. I call this the “lost art of Agile Software Development”. But the next question is: even if you can slice the Features and Stories into smaller work items, that you can deliver regularly into a productionlike environment, how can you use that information in a project negotiation? Carmen’s next challenge is just that: how to use the actionable information she collected to negotiate the project delivery with the customer. Let’s see how she does that in the next chapter.
CHAPTER 6
THE FIRST STEP TO DELIVER A PROJECT ON TIME IS TO RECOGNIZE THAT WE ARE LATE Carmen, I’m impressed with what you were able to do during this week. Your presentation of the project’s progress was very clear, and is just what we need to make good decisions.” Carmen’s boss smiled. “Thank you! I think I’m starting to get the hang of these #NoEstimates ideas, that Herman has been talking about, and I really think it will help…” “What?!?!” Interrupted her boss. “That’s not acceptable! You can’t be talking about that to the client! They will think we are not following the process and may sue us!” Her boss was not amused. “But, that’s the truth. It is thanks to Herman’s ideas that I was able to finally get a grip on the real progress of the project. Without his help and his support we would still be in the same situation as we were last week. Why can’t we say this to the customer?” Carmen was not happy with the need to hide #NoEstimates from the customer. “Carmen, I’m sure you mean well. And I’m sure that whatever ideas Herman has told you they have only helped you realize that you needed to work harder. This #NoEstimates is simply not credible! Why do you think I transferred Herman out of my team? We can’t run the risk of him talking to a customer about his ideas, we’d lose all credibility we have in the market!”
The first step to deliver a project on time is to recognize that we are late
“I see…” Carmen’s mind was racing, she was at the same time disappointed and angry with her boss for not listening and dismissing the ideas that she had been learning about. Maybe this disappointment was due to her own incredulity before she went through the process of losing faith, and then regaining it again by looking at the actual data that she had been able to collect in the last week. “Look, you’ve done a great job this last week.” Her boss continued, “don’t spoil it by scaring the customer with immature and irresponsible ideas. I’ve been in this industry for many years and have seen many successful projects. I know estimation is a key practice in any project. All the indicators of project failure point to bad management, not the estimation process as the root cause for failure. Keep your game together and work hard, I have faith in you.” At that moment, Carmen would realize later, a bit of her died. She stopped respecting the knowledge she knew her boss had. She had found a different way to look at project management, and specifically at assessing progress over time. And she was not about to throw that away just to please her boss. She knew now that Herman was right, and she was about to prove her boss wrong. But before that she would need to improve her diplomatic skills to counter her boss’ unwillingness to deviate from the old process. Client meeting day had arrived. It was show time!
1-2-3: Step by Step Towards #NoEstimates
The meeting started with Carmen giving her overview of progress as she had prepared the day before. She did not mention #NoEstimates even once, but gave a clear indication that the project would very likely be late. Carmen showed a graph illustrating progress with a burn down chart that only mentioned “Work to be done” and “Months”, as had been agreed with her boss the graph did not mention Features or User Stories.
Figure 12 - Carmen's projection for Big Fish project. The optimistic and pessimistic projections.
“The most optimistic expectation right now is that the project would, with the current scope, be finished in 16 months or around 12 months from now.” Carmen explained, “as you can see in this forecasted line of progress.” “Carmen,” the client interrupted, “what is that other line that ends 4 years from now? What is that referring to?” “Great question, and well spotted. That other line is the worst-case scenario. Given what we know now about the progress in the project, it could take up to 4 years to deliver the functionality that we have in the plans today,” Carmen added. “Joseph,” said the client, turning Carmen’s boss, “I believe we had an agreement on the live date for the project, didn’t we?” “Yes, we did Mr. McNeal. And I assure you we still have that
The first step to deliver a project on time is to recognize that we are late
agreement. What Carmen is showing is important information. As we are at this early stage in the project it is important to have a discussion about what is possible, and that is what we are trying to do here.” Carmen’s boss tried to help Carmen save face. “Indeed, Sir.” Carmen concurred, “there are certain measures we can take to try to increase the probability of delivering within the original date, but we will have to do some work to analyze and decide which requirements we will either remove or delay” “I don’t like the idea of removing requirements as this is pretty much the minimum set of requirements that we need in order to have a successful launch. Especially since the elections are shortly after this system is scheduled to go live. I’ll have Travis contact you about the work he has done. But for now I want to have a closer look at progress. Please send us updates every week,” finished Mr. McNeal. “But, Mr. McNeal. There is so much work to do, preparing reports for your review every week will hinder our ability to manage the project at the best of our ability,” Carmen’s boss added. “OK, let’s make it every two weeks then. By the way, I liked the software demo you did today, let’s have one of those every month.” “Certainly, Mr. McNeal!” Carmen’s boss added with a forced smile.
How to Recover from a Late Project?
How to Recover from a Late Project?
Carmen was happy the client had taken the bad news without much anger, but she now had a challenge. How to recover from the delay in the project? In the best case the project would be done 12 months from that meeting, which is 2 months late. However, the most likely scenario is somewhere between 12 months and 4 years. This situation is by no means uncommon42. Many projects face this situation late in the planned schedule. What Carmen was able to do with the help of #NoEstimates was to create the conditions to have the scope discussion with the customer quite early in the project. One of the key ideas with #NoEstimates is to focus the conversation on the value of the work to be done. By forecasting and showing progress (or the lack thereof) very early on, Carmen is bringing the scope discussion to the first few days of the project. This is the time when customers are willing to compromise, and when the technology is still flexible enough to be able to manage the scope effectively (very few dependencies are created, unlike at the end of a project where removing some functionality may be harder than adding it in the first place). The key for Carmen now is to find out how to implement an effective scope management strategy. Carmen knew she had to start reducing the scope of the project if she was going to deliver that project on time. Now was time for action. She felt confident that she would be able to reduce the scope of the project after talking to Travis the Business Analyst, so she rang him up and set a meeting for the next day. The next day, the meeting started with the bad news. “Travis, I need to reduce the project scope massively. We have a very low chance of getting this project done with the current backlog size.” Carmen stated. “OK, I can see that.” Travis concurred while looking at the progress burndown that Carmen had shown him just a moment ago. If I understand this graph correctly we need to remove at least the equivalent of 2 months of work given the best estimate, right?” “Actually Travis, this is not an estimate. It is a forecast,” Carmen corrected. “What’s the difference? If it gives me a delivery date it is an estimate.” 42 Research into the ”on time” delivery of software projects shows that a large % of projects are delivered after the agreed delivery date. For more data see Chapter 1 of this book.
The first step to deliver a project on time is to recognize that we are late
“There is a big difference which we can’t go into right now,” Carmen stopped short of mentioning #NoEstimates. “But for now I can say that this is a forecast based on actual data, not estimations made by the team.” “Oh, you mean this is like that Earned Value Management graph but upside down?” Asked Travis referring to the fact that the progress lines were pointing downwards. “No, this is not the Earned Value curve. It is concrete, validated progress data, but never mind. The important thing is that the data we have tells us that we will need to remove between 50% to 80% of the existing set of functionality.” Travis looked at Carmen and said: “Are you trying to get me fired?” “Look, Travis. I know this is a lot, but if you really want to have this project live 10 months from now we need to scale down the expectations.” “Carmen, I may be able to negotiate the scope down a bit. But never 50% let alone 80%.” “You do realize that we are fighting a losing war trying to get all of this scope delivered, right?” Carmen interrupted. “Sure, but that is your problem. You’ve committed to this bid, now you need to figure out how to pull it off. From the list you have there I may be able to remove 5-10 Features, if that is what you call those, but not more!” Travis continued. “OK, please work with your management team to remove as many as possible and get back to me later this week. I’ll see what I can do on my side.” “OK, will do. Talk soon,” – said Travis as he exited the room. Carmen lost the optimism she had found in the meeting with Mr. McNeal the day before. The full implications of the project being late were just now hitting her. She felt as if she could do nothing to improve the situation. It was time to get back to Herman. Maybe he had some ideas. As she walked to Herman’s office, Carmen remembered the conversation with her boss about #NoEstimates and decided to meet Herman outside the office. The last thing she wanted now was for her boss to think that she was still using #NoEstimates methods and tools. Carmen picked up her phone and dialed Herman’s cellphone. “Herman, hi! Carmen here. Can we meet outside the office today for a discussion on #NoEstimates?” “Sure Carmen! I’m going to a #NoEstimates meetup later today. Would you like to join?”
How to Recover from a Late Project?
“Sounds like a plan,” Carmen replied, “when and where?” “Downtown, at the Ritz at 7:30pm. Let’s meet just before the meetup, there’s one person I want you to meet.” “Oh, great. See you then Herman.” Later that day, at the Ritz… “Carmen, over here!” Herman shouted. “Hi! I was looking for you.” Carmen was happy to be out of the office, and to be able to again talk freely about what was worrying her. “Carmen, I want you to meet Julia Matthews.” Herman introduced the speaker for the event. “Julia has a long experience in project management and is one of the very few experienced #NoEstimates practitioners. I briefed her on your project and she be may be able to help you.” After the introductions, the conversation started with a quick overview of the project and the conversation that Carmen had earlier that day with Travis, the Business Analyst. “So, I understand that I need to reduce the scope of the project to be able to meet the committed release dated. But I don’t see how I can do it when the business analyst himself tells me that he may be able to reduce only 5 to 10 Features from the backlog.” Carmen reported. “Carmen,” Julia started. “First of all, let me tell you that you have come a long way. By having transformed the requirements into RTS’s you have created visibility into your progress that is uncommon in most software projects today. Congratulations for your work, you have the key tools you need to manage your project successfully. That list of Features and User Stories gives you a concrete list of valuable items that your customer wants, and you have a concrete way to measure progress against that list. Many projects are still measuring progress against a plan. You’ve started measuring progress against concrete, expected value.” “Thank you, Mrs. Matthews.” “You can call me Julia, Carmen.” “Thank you Julia. But I need to be able to reduce the scope of the project, and now I’m puzzled. Travis can’t see how to achieve the necessary reduction in scope.” “That is very normal, even predictable,” Julia interrupted. “People are used to think about project scope as a list of dependent items, requirements. Usually even a layered architecture is used, and the requirements scattered in those layers. It is very hard to imagine a project where all the requirements would be independent from each other when you are used to this layered approach, where requirements build on each other, and are therefore dependent on each other. It is
The first step to deliver a project on time is to recognize that we are late
therefore hard to understand that when you have a list of Independent items, like User Stories and Features as you defined already, reducing scope is not only possible, but can be achieved in several ways. For example: you have the possibility of reducing Features as you asked Travis to help you with. But you also have the possibility of reducing the scope for each Feature separately. I call that Flexible Requirements Management 43. I use the prefix “Flexible” because it is not about managing one list of functionality, but rather a matrix. Let me draw this for you to try and make it clear.”
Flexible Requirements Management for Maximum Scope Visibility We often think of the scope for a project as an inflexible – or at best slightly negotiable – list of requirements or functionality. However, projects have a tendency to grow in scope precisely because that list is very flexible. The scope creep phenomenon is only one example of that flexibility. Requirements are added to the list because, when looking at the details, we find: • •
• •
Cases we didn’t think about. New possible situations in which the existing requirement could be used. Performance aspects we had not considered. Requirements that have a direct impact on how other requirements can be implemented, and therefore expand the scope for those other requirements.
The list goes on. As we know more about the project, the users, the technology, etc., we will find information that we could not have considered when the project started. That information will need to be reflected in the work to be done, the requirements list, in the form of additions to that list. 43 Flexible Requirements Management is inspired by a technique that Jeff Patton popularized, called Story Mapping. Story Mapping is used at the start of a project to envision the product as a whole and decide what should be released in each of the product releases. Flexible Requirements Management is the application of the story map concept to the day-to-day scope management of a project. For more on Story Mapping: http://jpattonassociates.com/the-new-backlog/
Flexible Requirements Management for Maximum Scope Visibility
What I propose is a similar approach to the management of Features and User Stories, but with the opposite goal. I propose that, as we know more about the project, a Feature or a User Story, we question the need for that work, and if possible remove that work. When we understand more about the project or the problem we are trying to solve we can question if certain Features are needed. For example, when implementing an IT ticketing system we may have a Feature that calls for the users to log-in and manage their list of open tickets so that they can review what IT has done for them. Alternatively we can have the list of the last 10 tickets in each email that we send to the users of the system, therefore removing the need to have the userfacing web-site. By removing the web-site page for the “open tickets” Feature we will no longer have to implement other Features, such as user creation, user authentication, password renewal, etc. Here’s a way to visualize the project in its different dimensions:
Carmen needs to start considering all the possible dimensions of scope before she is able to realize that, even fixed scope projects, can have a lot of flexibility in the list of requirements, if that list is expressed as a two dimensional matrix of Features and User Stories. “As you describe the scope of your project in the form of a matrix, instead of a list you are able to see possible options for reducing scope much more clearly than if you only consider the list of Features.” Julia continued.
The first step to deliver a project on time is to recognize that we are late
“Oh, I see. You mean that instead of reducing scope by removing Features, I can also reduce scope by reducing the User Stories associated with each Feature.” “Correct.” Julia responded. “OK, but I don’t have that list of User Stories, so I can’t do that at the moment. And it would take a great deal of work to go and list all the User Stories for each Feature,” Carmen was still not convinced. “Don’t worry about the User Stories for now. Your first step should be to look at the list of Features and find Features that you can remove from the project. Once you’ve done that you review the list again to check if, by having removed those Features, there are some Features that are no longer needed. For example, if you remove a Feature that uses a particular database, you may not need to support that database anymore, which would probably remove related work in other Features or even some Features related to administrating that database.” “Oh, I see. You mean that I should first try to list and remove the Features that require a large amount of work or possibly impact indirectly other Features if they are implemented.” “Correct,” responded Julia. “OK, I get that. But, even if I do remove several Features the fact is that I would need to reduce 50% to 80% of the Features. The client is certainly not going to agree to that,” Carmen worried. “When we start discussing scope reduction we never have an easy conversation ahead of us. However, because you started very early, the client will be able to make decisions that may have a significant impact on the list of Features. You have to continue that discussion and find the right Features to remove. It will not be easy, but the alternative is certain failure. And no one, not even the client, wants that.” Julia assured Carmen. “You’ve taken the hardest step in any project. You’ve started the conversation with your customer. Now it is time to continue that conversation.” “OK, I’ll have to give it a try. But even if I remove some Features from the list, I will not have enough to complete the project on time,” Carmen expressed her concern. “That is a possibility, but before you get to that point give the Features a good scrubbing. You may be surprised with what you find. And when you find that Features alone will not be able to impact enough your project then it is time to take the scope scrubbing to the detailed User Story level,” Julia commented. “Apologies. I need to interrupt you. Julia, the session is about to start,” said Herman as he signaled Julia to enter the room.
Flexible Requirements Management for Maximum Scope Visibility
“Julia, can I contact you later?” “Sure, it would be a pleasure to help you Carmen. Good luck and talk soon.” Julia headed towards the room where the evening’s presentation was about to start. Carmen was still not comfortable with the situation, but at least she knew what to do next. She would have a discussion with Travis the next day and use what she had just learned to remove, not only the Features Travis had been able to remove, but also Features that may have been there to support the Features that could be removed. Carmen was sure that it would not be enough, but she had to give it a try. She might be surprised, as Julia pointed out. The next day at the office Herman tried to meet Carmen several times but was unable to find her. She was not in her room, did not go to lunch to the usual place. It was as if she had disappeared. “Carmen, what’s up? I’ve been the whole day trying to find you to discuss what you heard from Julia yesterday. Are you busy?” Herman asked, surprised to find her in the corridor. “I am busy, but I’d also like to review with you what I learned yesterday, but we can’t do it here in the office. Let’s meet later. I’ll explain why we can’t discuss here.” Carmen added while looking to see that her boss was not around. “I’ll meet Travis from the Big Fish client today. How about meeting near their office at 5pm?” “OK, meet you there. But tell me, why is this secrecy about us meeting necessary?” Carmen felt ashamed as she confessed “Well, my boss told me about his history with you, and how he thinks that the #NoEstimates ideas are crazy and that I should not mention #NoEstimates to the customer.” “Ah! Ah! Well, he is right about one thing: you should not mention it to your customer. It is our responsibility as professional and competent Project Managers to deliver the projects on time and under budget. #NoEstimates is our secret weapon to achieve that goal. They will be happy when you provide transparency they’ve never seen, and the project on time and under-budget. Don’t worry about the label. Just be transparent and accountable to your client. I have a feeling your boss won’t mind you surpassing your client’s expectations!” Herman winked, and turned away. “He is right!” Carmen realized. “I will focus on delivering this project on time and providing more transparency and accountability to the client, and I even know how to do that now!” Carmen drove up to Travis’ office to discuss the project. “Travis, hi! Thank you for meeting me on such short notice. As you
The first step to deliver a project on time is to recognize that we are late
know we have our next progress review with Mr. McNeal in 2 weeks. I need to show an updated progress report based on what we discuss today,” Carmen started. “Sure. I know that. I did some work since we spoke yesterday. Here’s a list of the 5 Features we can remove from the scope of the project. I tried, and tried to get a commitment to more Features, but that was not possible. This is the best I could do since yesterday. We may be able to remove 1 or 2 more over the next weeks, but for now this is the best we can do.” Travis announced while passing a paper to Carmen with the list. “Thank you Travis. I can work with this. I’ll have to review the implications of removing these Features on the remaining list of Features. Can I come back to you later with questions about these?” “Sure, let me know if I can help you in any way. But as I said, these are the Features we can remove now.” “Thank you. Talk later,” said Carmen as she exited the room. She felt a bit more confidence in the process since she had that conversation with Julia, but she was not yet fully comfortable with the situation. She knew those Features would not be enough to bring the project end-date back to the original 12-month time frame. And now she was responsible for the delivery, as her boss had clearly reminded her. The stakes were high. She needed to act. The meeting with Herman later that day started with a charged atmosphere. “I just can’t see how I will be able to pull it off, Herman.” “Don’t worry about the project release for now. Let’s work with what we have right now. We have a concrete scope reduction of 5 Features. Where does that leave us in terms of release date?” Herman tried to cheer Carmen and focus her on the information she already had at her disposal. “Let’s review your release forecast, do you have that?” “Yes, here it is,” Carmen pulled out the graph. “The previous forecast as well as the one I created earlier today, that already accounts for the Features we’ve just removed.”
Flexible Requirements Management for Maximum Scope Visibility
Figure 13 - Current forecast (overlaid on the original forecast), already taking into account the Features removed by Travis
“Great. Do you see any Features in the backlog that would be unnecessary now that you’ve removed those other five Features?” Asked Herman. “Hmmm, hard to say at this point. I supposed I could bring this back to our team and collect a few more ideas on what Features we could remove.” Carmen was unsure that this was the right course of action, but she wanted to sound more positive. “Then do that. You may find some Features that can be removed now that were not possible to remove before. Then there’s the next level, we have to analyze the next level.” Herman added cryptically. “What do you mean by next level?” “What I mean is: at first you can manage the scope by removing Features. Once you are done with removing Features there’s still a lot of scope that can be removed when you look at the stories under those Features. There are many ways in which a Feature can be delivered. The stories under a Feature represent one way to do it, but you can find other
The first step to deliver a project on time is to recognize that we are late
ways by thinking about the functionality from your ideal customer 44 perspective,” Herman explained. “What do you mean by ideal customer? Is that a new concept?” Carmen asked, puzzled. “No, it is not a new concept, but it links back to the vision of your product. A product exists to serve several types of customers, but it always has a specific customer type without which the product would not even exist. That is your ideal customer. When you think about the product from your ideal customer’s perspective, you will have a clearer focus and will be able to decide what is indeed needed, and what could be removed because the ideal customer can use the product without that particular functionality.” Herman looked at Carmen waiting for confirmation that she had understood. “OK, let me see if I understood this right. What you are saying is that in a particular Feature there are stories that include functionality that the ideal customer needs, and other functionality that the ideal customer either does not need or can live without, right?” “Right,” Herman smiled, “this is what we call flexible requirements management. We have different levels of abstraction at which we can manage the scope of the project. Typically projects tend to balloon in scope, because we discover functionality at lower levels of abstraction that we consider ‘important’, and just add to the backlog. However, we can use the same approach to remove items from the backlog. Think of it like negative scope creep.” “I see… That’s a good insight. But won’t that require a lot of work?” “Yes, and constantly. But when your other option is to miss the delivery date, I’m sure you can see why it is worth it,” Herman commented. Carmen sighed and looked at Herman. “That means one more long night for me…” Carmen said. They parted and Carmen went to work on the backlog to find the stories that could be removed from the ideal customer’s point of view.
44 In this context ideal customer is a term used to designate the target customer of the product or service being developed. This should be as specific as possible, and not generic terms like consumer or business owner. Examples: a consumer that has purchased from our shop before; a small family restaurant owner.
Creating Options by Slicing Features
Creating Options by Slicing Features Each Feature (or story) in a product backlog contains many undiscovered options. By taking Features as they are without slicing them into thin slices of functionality we implicitly commit to an implementation strategy. However, when we slice Features we create options that allow us to pro-actively manage the scope of a project. Let’s return to the IT Support Ticketing System project we discussed before. A Feature like the one below will not allow us to manage the scope actively. As an employee, I want to be able to submit issues to IT, so that I can fix a particular problem that prevents me from working. The Feature above is what I would call a “binary” Feature. Either the employee is able to submit an issue to IT or not. This simple Feature can have large implications in terms of the amount of work required to implement it. Specifically the chosen “input” solution (how the issue tickets are submitted) can make the difference between a simple and very complex and long-winded implementation. Taking the Feature above and breaking it down into several smaller Features or stories will allow us to make decisions regarding the implementation order, or delaying certain parts of the implementation. Let’s look at an example: •
•
•
As an employee I want to be able to submit an IT issue to the IT department so that I can have a fix for a problem that prevents me from working As an IT helpdesk employee, I want to have a queue of issues to handle, so that I know what items I should be working on at any given time.
By slicing the original Feature in this particular way we unpacked the functionality under the term “submit issues” in the original Feature into two different Features: send submission (replaces simple submit above) and Queue of issues (replaces the receiving end of the submission process). We’ve potentially reduced the scope of the initial Feature (for example no need to have a system to enter IT tickets, just use email as the submission tool), and we’ve given ourselves the option to implement a solution based on standard tools. The two Features we created allow for
The first step to deliver a project on time is to recognize that we are late
a solution based on email and a spreadsheet program with shared editing. For example, we could use Google Docs to manage this queue and get started today! These two stories could still be implemented with a full-fledged IT issue tracking system, but that is an option and not a mandatory outcome of the initial Feature. Slicing Features into separate functional parts helps us actively manage the scope by creating different implementation options 45that are often implicit and non-negotiable when we have larger Features in the backlog.
How to Communicate Progress? Carmen had worked hard all night, but the picture had not changed. Carmen was able to remove one more Feature, and split another 12 Features in search of ways to reduce the scope. Carmen began: “Herman, thanks for taking my call this early. I was up all night. I was able to find one more Feature to remove, and split another 12 Features, but now my list of Features - even with the five I removed this week - is up to 93. It is as if this exercise created even more work instead of reducing it.” “This is part of the process,” said Herman trying to reassure Carmen. “When you split the Features it is natural that the number of Features grows. But that does not mean that you increased the amount of work. It only means that you’ve found work in the list of Features that was already there, but you were not aware of before. This exercise has helped you better understand the backlog. That’s why it feels overwhelming.” “Sure, I understand that, but I need to start removing Features and I don’t see where to start. There’s just too many Features for me to review and classify.” Carmen doubted the process. “You’ve only completed the first part of the work. The next step is to review the new Features with your team. They’ll have ideas on how to further slice those Features and suggestions as to how many of those you could avoid with different implementation strategies,” Herman continued. 45 6VW [VWS VR VQY_VRT YZ_Rf_R`D PRX YZS UVWf YZPY _RTQ_WSX YZ_T PQQWVPbZ ' WSbV[[SRX YZS UVWf kc :ZW_T (PYYT PRX #]P^ (PPTTSR PRX YZS_W kVVf; :V[[_Y[SRY ZYYQ;iibV[[_Y[SRYLYZSkVVf.bV[i
How to Communicate Progress?
“I know this is asking a lot, Herman. But can you help me out with hosting a meeting to do just that? I’m tired and don’t feel confident enough to help the team see through these Features.” “Sure Carmen, let’s meet at the office.” “Hmmm, it is better if we meet in the meeting room floor to avoid indiscrete looks. I’ll take the team there. Talk soon!” – Carmen hung up and felt a bit better after having obtained Herman’s cooperation. She was not yet completely sure that his ideas would work. But now she was committed to trying his ideas in practice. She felt the alternative of going back to her old approach to project management was no longer an option. It is only when we start to actively manage the options we have (slicing the work into INVEST stories) that we truly gain control of the work we must complete. Finding the next most important story to develop is the core of my #NoEstimates approach. Slicing the stories and prioritizing them regularly is the process. But there is more to that. How do we communicate the progress to the customer, especially in critical projects? How can we help customers make decisions regarding which work to keep and which work to delay or drop? That’s the next step for Carmen. The pressure is increasing and the stakes are high.
The first step to deliver a project on time is to recognize that we are late
CHAPTER 7
GAIN THE CUSTOMERS TRUST WITH ROLLING WAVE FORECASTING Carmen was re-arranging her papers repeatedly as she waited for the team to come to the meeting room. She had prepared the room for the workshop with flipcharts on the wall, the list of Features on one side and the slices of those Features underneath. She wanted to know if her effort to slice the Features was understood and accepted by the team. When everybody was in, she started the meeting. “Thank you all for coming at such short notice. As you know we have a very challenging project ahead of us. I’ve been focusing on how we could keep this project on track both from the scope and time perspective, but also so that we don’t have to work over-time for the next 9 and a half months. No one would like that, least of all me.” She felt her team’s attention and a huge responsibility at the same time. “I reviewed the backlog in the last few days, and as you know, concluded that we can’t possibly make the release date in 9 and a half months with the current amount of work. We have two options, increase our throughput of Features per iteration, or we can remove content from the backlog.” “Increase the throughput? Are you serious Carmen? I’ve been working over-time for a week to get some progress visible to the customer in our next progress report. I can’t possibly work any harder,” Albert was not amused. “I understand Albert, and I thank you for your efforts. Without your and everybody else’s extra contribution we probably would be in big trouble right now. I understand that. That’s why I wanted to focus this meeting on creating options for us. I would like to review the backlog with you and list possible Features we could drop based on what was dropped already, and slice the remaining Features to see if we can find functionality that we don’t need to deliver for the first release. I’m not asking for miracles here. I know what can be done. Now I’d like to focus on what we can avoid doing, in order to meet our deadline.” After the introduction, several groups were formed. One of the groups reviewed the Feature slices that Carmen had created the night before, and the other groups focused on trying to unpack the remaining Features into slices that could be prioritized for later or dropped altogether. It
Gain the customers trust with rolling wave forecasting
was an intense workshop. The atmosphere was charged. People asked themselves if there was a practical, and realistic solution to the conundrum they were in. “Thank you all for your help with this process,” said Carmen as she prepared to close the workshop. “We have learned a lot about the project in this workshop and, not surprisingly, we were able to remove some work that was ‘hiding’ inside the big monolithic Features that we had in the backlog. Although we are no better than we were a week ago (we now have 73 Features in the backlog, compared to 64 a week ago) the fact is that we have a good idea of what we can remove further from the backlog and may have impacted our throughput by reducing the scope of the current Feature set. This last comment needs to be validated in the following weeks, but now I have a good idea of what I can suggest to the client can be removed further. Thank you all.” Carmen was happy with the outcome of the workshop, but she knew there was a long and hard road ahead to convince the client about what could still be removed and to show concrete, and constant progress. The first progress review was only one week away. Now it was time to let the team focus on the work they had at hand and prepare the meeting with the client.
The Never-Ending Pool of Ideas What Carmen and her team just went through is very common in software projects. Once we start looking into the details of a set of requirements (Features or user stories) we always find details we had not thought about. This is normal, and expected in every software project, especially in those where planning starts at the top and only slowly trickles down to the team level. In software and hardware (aka embedded software) projects it is also natural that we discover certain quirks in how the hardware works only when the software system has grown enough to uncover those unexpected behaviors. That phenomenon leads to more work needing to be done on the software side for the simple reason that hardware is much harder to change. Scope creep is the natural state of software projects, it feels like the pool of ideas grows with every day that passes, and the work to be done grows with it. That is why when we apply #NoEstimates we focus on managing the scope from day zero. In order to successfully manage scope from day one, we need to have a tool that shows progress visually every day, or at least every week. We can’t wait for a specific milestone later in the project to find out how much work we need to either remove or delay. In software projects, the work to be done grows every day, and
Reporting Progress with NoEstimates
our ability to see that growth also needs to be ensured every day. A common approach to creating that visibility is to use the technique Carmen used: slice your Features and user stories so that you can review progress on a daily or at least weekly basis. In practice this means that every week several stories should be completed to allow you to assess progress. And every few weeks (every month or so) several Features should be completed. You should involve the whole development team in the slicing of Features because they will have insights into the components of the work that can be made independent, and how to validate each slice separately. Validating each slice from the value and quality perspective is essential for us to assess progress. Work waiting to be validated from value and quality perspective is for software development what inventory is for manufacturing: a liability. You will have to pay dearly for that work later on, unless you validate that work immediately. How do you visualize progress when you don’t even know all the possible dependencies that will emerge later on? That’s a question that is addressed by the progress reporting solution described here.
Reporting Progress with NoEstimates The meeting with the client, Mr. McNeal, was about to start. Expectations were high. The day before Carmen and her boss had a heated debate about how to present the progress of the team so far. Carmen’s boss was of the opinion that they should report progress based on the initial count of Features, before the “scope creep” that Carmen had uncovered. Carmen was adamant; she wanted to show the situation as she saw it. The tension was high. Carmen was prepared. She started: “Mr. McNeal, unfortunately, and although we had good progress since our last meeting two weeks ago, we can’t say that we are closer to the original estimate now than we were then.” “Can you explain what you mean Carmen?” Mr. McNeal did not sound as angry as Carmen had expected after her conversation with her boss. “Sure. In the last progress review we reported that we had started, but not finalized the highest priority Feature.” “Remind me again Carmen, what is a Feature. Is that what you call requirements these days?” Mr. McNeal interrupted. “No sir. A Feature is something you can show to the users of the system and they understand it from the point of view of their use of the system. Unlike a requirement, a Feature is a self-contained, testable piece of functionality that can be delivered independently from the other
Gain the customers trust with rolling wave forecasting
Features in our list,” Carmen explained. “Oh, I see. That means I could actually deliver some Features to production before we have all the Features completed?” “Yes, sir. That is the idea. To be able to deliver each Feature independently to production and validate that it fulfills the needs for use. Once the Feature is tested and the users give feedback, we consider the Feature validated,” Carmen continued. “But wait, you could deliver this feature to production within 3 months, couldn't you?” – asked Mr. McNeal with a sudden interest. Carmen was surprised by that comment and thought: “Does this mean that Mr. McNeal is interested in delivering early? He never expressed so much interest in the content of the project during our previous meetings”. “Correct!” Confirmed Carmen, trying hard not to give a hint of her surprise. “You are saying that you could – if I asked you – deliver to production before the final release date, right?” “Correct. However, I must also say that it requires some readiness on your side to be able to do that. We can test that the functionality works as expected, but your team will need to confirm that it is the necessary functionality or deliver back to us the list of changes for that Feature.” Carmen was unsure if she was speaking too fast. She was excited about the idea of incremental deliveries. Would Mr. McNeal buy that idea? “Sure, sure. Of course they can do that. Show me the list of Features please. I want to check something.” “Here you go, sir.” Carmen said as she handed over the list of Features that had been created after her workshop with the team. Mr. McNeal started to look attentively through the list. He seemed to be reading each Feature. Once in a while he stopped and asked a few questions about one Feature and said “OK, that’s not the one”. Everybody was puzzled. First it was a surprise that Mr. McNeal, who usually did not interact much with the development team was paying so much attention to a simple list of Features. Second, nobody expected that he would read the whole list of Features in a progress meeting. Everybody expected him to be tough and demanding, and requiring overtime to be paid by the vendor to meet a deadline that had been agreed in the bidding stages of the project. The next ten minutes felt like an eternity. But finally Mr. McNeal raised his eyes from the list, looked at Carmen and asked: “When is this Feature going to be delivered?” Carmen looked at the Feature that Mr. McNeal was pointing to and said: “I can’t be sure Mr. McNeal. With the current rate of progress it is
Reporting Progress with NoEstimates
unlikely that we will have that Feature ready in the next two weeks, but I can get back to you with an estimation later today or tomorrow if you like.” “I would really like to know when this Feature will be ready, so please hurry up your estimation meetings and let me know by the end of today when you will be able to deliver that Feature.” Mr. McNeal was back to his demanding self. “We will try.” Carmen’s boss interjected with a smile. “Try as you may, I want to have an answer today. Now, if you will excuse me I have to run. Carmen, great work on the use of Features, this is the first time I see any project using this approach, and I must say I like it. Now please let me know when that Feature will be delivered.” Mr. McNeal thanked all in the room and left. It was as if a huge pressure cooker had just been opened. The room suddenly felt serene and calm again. The fear was gone, and Carmen knew what to do next. A few hours later in a restaurant nearby, Herman and Carmen were debating heatedly about how to solve the problem of answering Mr. McNeal’s question: when will this particular Feature be delivered? “But Herman, we really need to estimate every Feature in the backlog. Mr. McNeal wants to know when this Feature will be delivered, but next week he will ask about another Feature. If I don’t have a Gantt 46 chart with the Features and assignments I will not know when the Feature is ready,” Carmen insisted. “Carmen, let’s look at the data you have. You have been able to deliver 2 Features to your validation environment in 3 weeks. This Feature that Mr. McNeal wants is currently the tenth Feature from the top, this isn’t that hard. If you complete between 0,6 and 1 Feature per week on average, it will take 10 to 16 weeks to deliver that Feature. It is that simple. Trust the data.” Herman tried to convince Carmen. “Sure, but that is a rate. Not a specific work sequence. I can’t be sure that this Feature is number 10 in the list if the earlier Features can grow or shrink between now and when we start that Feature.” “Correct, but you will have a good indication of the delivery window. You will also know when the window for delivery changes, and you can react to that! Be it with reprioritization or removing content from Features that are earlier in the list,” Herman continued. “But what if we make a commitment to Mr. McNeal and we are late? 46 http://en.wikipedia.org/wiki/Gantt_chart A commonly used graphical representation of work and dependencies between different work packages in a project.
Gain the customers trust with rolling wave forecasting
He seems to be very interested in that functionality. Maybe we should move it up on the list?” Carmen was unsure “Whether you need to move it up the list or not you will know as soon as you report the rolling wave forecast with the window for that Feature.” Herman commented. “Rolling what? What did you say?” Carmen asked. “I said that Mr. McNeal will let you know if you need to reprioritize your list of Features once you tell him when the Feature is forecasted to be ready.” “No, what did you say about rolling wave forecast?” Carmen insisted. “I said that when you present the rolling wave forecast to Mr. McNeal he will let you know if he is happy with the delivery window for that Feature.” “What do you mean by delivery window?” “OK, I’ll backtrack bit. First, you should have a rolling wave forecast for your project. Say you have windows of two weeks (because that is your iteration length) and total project duration of 12 months. You should show your project as a sliding window over the 12-month timeline. Like if you were projecting two weeks in detail and have a rough indication of the rest of the work that is possible in 12 months.” “But the project is not 12 months now. It was only at the start, we only have 9,5 months now.” Carmen was confused. “Sure, you can also have a total timeline of 9,5 months, but if you do, you will not show clearly what does not fit anymore in the project. Let me draw you an example.” - Herman picked up a piece of paper and started drawing.
Reporting Progress with NoEstimates
“See this window here?” Herman asked pointing to the grey rectangle in the drawing he was creating. “This is the work that is likely to be delivered in the next two weeks, the rest is shown in priority order. And the work that goes beyond the planned release date for the project is then highlighted in red, to show that it is likely it will not be completed within that time frame.” “OK, I got it. So I show a window of two weeks to list the Features that are likely to be delivered in the next two weeks. But the Feature Mr. McNeal was interested in will not be ready in two weeks. How do I show that to him? Should I have multiple two week windows on the graph?” Carmen asked. “You could, but you could also have bigger windows. For example, you could have a two week window in green to show that it has a higher certainty, then a 1 month window in yellow, to show less certainty and finally a grey 3 month window. That way you give Mr. McNeal an indication of what Features will be delivered in different timeframes.” Herman paused, and then continued. “Of course, this is just me speculating. Maybe Mr. McNeal is interested in different time windows of 3 and 6 months. You should ask.” “OK, I got it. I have to go now and send that email to Mr. McNeal. Thank you again Herman for your help. I was about to call an overnight
Gain the customers trust with rolling wave forecasting
meeting with the team to build a Gantt chart with tasks, dependencies and resource balancing. But what you say makes sense and is completely in line with the way we are reporting progress right now. I have to try that. I will let you know how Mr. McNeal reacts. Wish me luck!” Carmen said as she was leaving. “Let me know what he says!” – Herman said while waving goodbye. The rolling wave forecast that Carmen will prepare will give her client: • •
Clear and verifiable progress information. Actionable information.
The same information that helps a project team make decisions, will also help the customer prioritize and decide on the scope of the project. The rolling wave forecast further helps you see what is possible to deliver in multiple time frames. Given that each Feature will have a different cost-of-delay47, this information is critical to decide which Features to keep in the backlog and which to delay or remove.
Rolling Wave Forecasting Allows You to Adapt Your Plans, Constantly Carmen needed to present a possible date of delivery to Mr. McNeal, and she was planning to obtain that date, the same way she had always done it. Through a detailed plan (Gantt chart) where she could review assumptions, planning details such as dependencies, risks, etc. But was that what Mr. McNeal wanted? By creating a detailed plan, Carmen was about to commit the work of the team for the next few weeks. Once that commitment was made (and the implicit promise to Mr. McNeal), the team would no longer have the option to adapt to new information. All the assumptions, sequence of work, dependency handling, risks and errors would be locked in. She would have removed all flexibility from her project. 47 http://en.wikipedia.org/wiki/Cost_of_delay Note that cost of delay is a rough measure of how much value is lost by delaying the delivery of some functionality. Each type of work will have a different cost of delay curve. For example a software program needed for the Football World Cup will have a very steep cost of delay curve around the day that software needs to go into use because the Football World Cup will start at the right time, even if the software is not ready. Other type of software will have a different cost of delay curve.
Rolling Wave Forecasting Allows You to Adapt Your Plans, Constantly
In the past, Carmen would have added buffers; created contingency plans and worked hard at managing expectations. But all that is unnecessary when we, instead of giving a commitment, give a forecast. At the heart of the rolling wave forecast is the acceptance of uncertainty. This, in turn, allows us to keep our options open. To be flexible and able to respond to change – just like the Agile Manifesto says. In a rolling wave forecast we create scenarios about the future. We speculate about how the events will unfold and reflect those analyses on a forecast that shows a range of possible outcomes. In this particular case, Carmen will assume that the throughput of the project will be within a range and therefore will give not one number, but an interval in time in which the Feature that Mr. McNeal wants is likely to be delivered. From this information Mr. McNeal can then: •
•
Accept the forecast and follow-up the delivery by getting an updated forecast. Refuse the forecast and ask for changes in prioritization of work so that the Feature he wants can be delivered earlier.
Independently of what decision Mr. McNeal will make, the cost to produce the forecast is very low, and the information it provides will be enough for him to make a decision. Following the decision, Carmen will be able to adapt the plan by re-arranging the order of implementation of the Features (they are independent) to meet the need or expectation from the client. If Mr. McNeal decides that a certain Feature should be delivered earlier than the forecast suggests, adapting the plan to that decision is a simple process of moving the Feature up in the priority order. The team is then notified and work continues. Contrast this with a Gantt chart. A detailed, and linear planning tool like a Gantt chart requires you to update the order of work for a detailed plan, and that typically involves sequencing, detailing, designing the work and then assigning it. Your goal should be to make changes to the plans easier. Why? The simpler the planning process, the faster and more easily your projects will be able to accommodate the inevitable changes. A key Feature of choosing a low overhead, yet accurate, forecasting mechanism for your project is that you can update the plan at all times. In the case of the Big Fish project, and thanks to the measure of throughput that Carmen uses to forecast the project, she can update the project progress information (rolling wave forecast) every week, because every week she has new information that she can add to the report. In
Gain the customers trust with rolling wave forecasting
turn, this provides actionable information for the project leadership to make concrete decisions about what Features or stories to move higher or lower in the priority order. This forecasting mechanism allows the project team to know when they are likely to deliver a certain Feature and therefore also coordinate work with external project contributors. This is necessary when the project team depends on external teams. For example: the project team may need to coordinate their work with a marketing team that implements the marketing campaign, or a field testing team that works with final users to collect feedback for a large rollout, etc. Finally, the rolling wave forecast also provides us with a varying scale of precision whereby the forecast is relatively more precise in the short term, and loses precision as we look into the future. Giving a measure of certainty that is different for different time scales. This is achieved by picturing the forecast for different values of the progress metric. Carmen uses her throughput range to give a widening range of outcomes over time as seen below.
Presenting The Rolling Wave Forecast to a Client
Presenting The Rolling Wave Forecast to a Client Carmen was nervous to read Mr. McNeal’s answer to her email. She had delivered the forecast she had created with Herman based on the throughput of the team. She remembered the trembling fingers with which she wrote “10 to 16 weeks from now”. The day started with a short conversation with her boss. Carmen was surprised by how silent and absent he had seemed, but now her mind was on her e-mail client. She opened the program, typed her password and waited anxiously until the emails were downloaded. Usually this happened in a few seconds, but today she felt the process took ages. She tried to guess Mr. McNeal's answer. Will he be furious? Angry? Get her fired? Carmen opened the email message of Mr. McNeal. It read: “Subject: RE: forecast for project Big Fish Dear Carmen,
Thank you for the information you sent me yesterday. It was most useful. Thanks to your detailed forecast and report on the possible outcomes for the next few weeks in the project I have been able to reprioritize the Feature we discussed yesterday.
Please call my secretary and arrange a meeting for today. I’d like to discuss the project’s next steps with you.
Regards.”
Carmen was at first happy. After all there was no anger in the email. However, the last phrase made her very anxious. Why was Mr. McNeal asking for a meeting now? What was going on? She called Mr. McNeal’s secretary and scheduled a meeting for later that day.
Gain the customers trust with rolling wave forecasting
As she entered Mr. McNeal’s office she felt her legs shake. She had a gut feeling that this was an important meeting. She sat down in the meeting room and waited for Mr. McNeal as she was instructed. She waited for a few minutes, which felt like an eternity. She tried drinking a glass of water, but her hand would not accept the order the brain had sent. Carmen decided that she was too nervous to drink water and sat on her hands to keep them from shaking. A few minutes later, Mr. McNeal entered the room. But he was not alone. “Hi Carmen, thank you for coming here on such short notice.” Mr. McNeal said. “Hello, sir. I understand. What is the matter…” Carmen stopped as she saw the person entering the room behind Mr. McNeal was her boss. He seemed serious. “Hello sir, I did not expect to see you here,” Carmen said while looking at her boss. “I wanted to have both of you here for this meeting,“ Mr. McNeal explained. “The reason is simple. I’ve made the decision that from now on the Big Fish project will be handled internally in my department.” Fear struck Carmen. Her fear of being fired was coming true. She thought: “My god! They are kicking us out of the project. Will my boss fire me now? Oh no...” “I want to keep a close watch on this project,” Mr. McNeal continued, “it is a very important project for me and for the Prime Minister. We can’t accept anything less than an on-time, high quality release. As you know this system is scheduled to go live just before the election. Any failure to deliver this project can cost us the election and we would not want that.” “I guess our company is out of the project, then.” Carmen was sure that this was the golden handshake moment. “I want to guarantee that this project is a success and that is why I’ve asked your company and Joseph here to move you and your team to our premises here, in our building. Effective Monday you will work here and report directly to me.” Mr. McNeal announced. “I’m very impressed with the clarity and transparency in this project, and I’m aware that you, Carmen, created that. You have been able to deliver more visibility and clarity regarding this project in 2 months than any of our other projects ever delivered. I’m impressed and I want you to help me bring that same kind of transparency to other projects here. Joseph has graciously agreed to let you and your team work directly with us here at our offices until further notice.” After a pause, Carmen said: “I don’t know what to say sir. I’m glad that you are happy with the progress the team has shown, but the
Presenting The Rolling Wave Forecast to a Client
visibility was created thanks to a colleague of ours that has been helping me and without whom I would not have been able to create this level of transparency.” “Bring him with you as well! We start on Monday! This is the most important project you will ever work on. I want the best people in charge.” “But Mr. McNeal,” Carmen’s boss tried to interrupt. “No buts Joseph, bring that fellow with Carmen and the team.” Mr. McNeal was not taking no for an answer. “Very well,” Carmen’s boss acquiesced. “We will bring Herman in as well.” Carmen was smiling inside. Her hands did not shake anymore and she felt confident. “And Carmen,” Mr. McNeal continued. “Next week we have a presentation about this project to the council of ministers. Let’s get ready for that. You are in the big leagues now.”
&1$ $3"
We hope you enjoyed the #NoEstimates book. Join the conversation on twitter under the #NoEstimates hashtag. This book is part of a larger project that includes video interviews with some of the early adopters of the ideas described in this book. Sign-up at www.NoEstimatesBook.com/print_gift to get an exclusive essay on Capacity Planning with #NoEstimates. Visit oikosofyseries.com/noestimates-book-order to find the following extra material: Two mini e-books on contracts and planning ! !
The Ultimate Guide to Capacity Planning with NoEstimates by Tomas Rybing How Much Does it Cost?: A Guide to Agile Contracts by Evan Leybourn
The #NoEstimates Pioneers on Video: ! ! !
Woody Zuill, the creator of the #NoEstimates hash tag on twitter Neil Killick, the creator of the Slicing Heuristic, a great way to reach #NoEstimates quickly Henri Karhatsu, greatly experienced #NoEstimates practitioner with many stories to share
Four video interviews with #NoEstimates practitioners ! ! ! !
Chris Chapman, inventor of the #NoEstimates game Clinton Keith, game developer using #NoEstimates in his projects Marcus Hammarberg, author of Kanban in Action Allan Kelly, author and #NoProjects movement founder
Two interviews with CEO’s applying #NoEstimates ! !
Sven Ditz, CEO of Sitegeist.de in Germany Diego Cenzano, CEO of biko2 in Spain Visit oikosofyseries.com/noestimates-book-order to know more
Gain the customers trust with rolling wave forecasting
ACKNOWLEDGEMENTS A project like this is never easy, and could not succeed without help and support from many people. So here is my heart-felt thank you to all, including those I have unintentionally left out in this acknowledgement. You made this project possible! To my family, who was so patient with me through the process of writing this book. A special thanks to my partners at Oikosofy who’ve helped and supported me through the difficult process that is writing a book, especially a controversial one as this.
Luis Gonçalves, aka the web-master, who helped me create the web-site and product pages for this book and all the additional material that is available with the book. Sven Schnee, who helped the #NoEstimates movement progress with his blog post on the topic. Veronika Gonçalves, who helped me get the first book page up and running and was patient with me when I could not answer her questions because I was immersed in the writing of this book. Fernando our investor who made Oikosofy possible! Woody Zuill, a dear friend whom I met in Skype first, and then later in several conferences. We organized workshops together and brought attention on twitter to a very important topic in our industry. Ángel Medinilla, the amazing illustrator for this book and the person who helped me get started with the book. Neil Killick, Henri Karhatsu, Chris Chapman, Sven Ditz, Diego Cenzano, Clinton Keith, Markus Hammarberg , a big, big thank you for being available and willing to contribute to this project with incredibly insightful video interviews that bring the whole idea of #NoEstimates to life from so many points of views. Tomas Rybing and Evan Leybourn, a very special thank you for the insightful essays that are now part of this project and will help countless people take these ideas into practices. All Beta Readers that invested their time and attention in making this
Acknowledgements
project much better with their questions, insights and comments. This book would be much worse without your contribution.
To the twitter friends I made during these years where #NoEstimates went from a crazy idea, to a wide-spread cry of dissatisfaction with the status quo in the software industry. You make me believe we can improve our industry!
ABOUT THE AUTHOR
Vasco wants to transform product development organizations into product business organizations. He does that by focusing the work of the product development teams on the end-to-end life-cycle of their products. From Concept to Cash and Back! Currently a Managing Partner at Oikosofy, Product Manager, Scrum Master, Project Manager, Director, Agile Coach are only some of the roles that I've taken in software development organizations. Having worked in the software industry since 1997, and Agile practitioner since 2004. I Vasco was one of the leaders and catalysts of Agile methods and Agile culture adoption at Avira, Nokia and F-Secure and other companies where he consults teams and management. Vasco is also the host of one of the most popular Scrum podcasts at: http://scrum-master-toolbox.com/ Follow that podcast for interviews with Scrum Masters from all over the world. You can read more at: http://softwaredevelopmenttoday.com/ You can join Vasco on twitter: @duarte_vasco
