The perils of estimation

Business people want estimates. They want to know how much it’s going to cost them to get a solution, and they want to know how likely it is to come in on time and on budget. And of course quality is not negotiable.

Agile teams I encounter are at best nervous about estimates and at worst simply evasive. “You don’t need estimates if you’re doing Agile,” they say. “It will be ready when it’s done. We’re constantly adding value so we don’t need to commit to a date.”

We’re missing the point of release planning

My favourite exchange goes something like:

“We’ve done an inception and broken down the entire project into stories and measured it, and it’s come in at 400 stories, estimated at 865 story points.”

“865 what?”

“865 story points.”

“So how big is a story point?”

“We don’t know yet, we’ll let you know in a few weeks.”

At a governance and funding level the business could care less about story points. They don’t actually care about stories except that we shove them in their faces with our release plans. They care about solving a problem. They came to us and asked us a) how much will it cost to solve the problem, and b) how confident are we about that number?

So how do we approach that? We go through some sort of inception process that looks something like this:

1. Identify some personas
2. Identify some process flows
3. Start breaking the flows down into stories
4. Lots and lots of stories
5. Lots and lots and lots and lots of stories
6. Spike some technical ideas that came out of the stories
7. Estimate the stories
8. Roll up all the estimates and call that our project estimate

The part where we estimate the stories is a real chore (c’mon – we’re estimating 400 stories here), so we cut corners. We do a first pass as t-shirt sizes (small, medium, large) and then take a representative sample (sounds suitably scientific) and do a “detailed” estimate of those. This involves a bunch of people estimating lots of important-sounding metrics: minimum, likely and maximum size, clarity, volatility (eh?) and whatever else, and then multiply it up to provide a WOOOOAAAAAHHHH! hang on a minute! What were we trying to do again?

All they wanted to know is: How long will it take, and how confident are you about that number?

Redefining success – in a bad way

By introducing a comprehensive story list – with or without the notion of story points – we have unwittingly reframed the project. The business started out by defining success as solving the problem, but now we have redefined success as delivering this list of stories. However we frame it, that’s what the business will believe. The project will start and and the business stakeholders will start counting down the list of stories until you get to zero.

So now we have the worst of both the Agile and plan-driven worlds: the business expects delivery of a fine-grained list of requirements (whether we call it a Product Backlog or a Master Story List), and we have only taken a half-hearted attempt at it compared to the big up-front analysis we used to do. From here on we are on the back foot, constantly negotiating with the business to manage scope, when it’s our own fault they even care about the story-level detail. They see the story backlog and mentally turn it 90 degrees and think of it as a Gantt chart. Happy days!

Back to project basics

There are two observations to make here. Firstly the business wants accuracy and we’re giving them precision. If you tell me it will take 4.632 months and it takes 8 months, that’s worse than useless. If you tell me it takes “about six months” and it takes seven months, I should still be onto a winner. (If the return on investment is small enough that the extra month stops the proposition being viable, I’d have been better off investing in something else in the first place. Spending $60,000 to realise a return of $70,000 is risky to say the least.) I’m simplifying here of course because the real RoI varies over time, and its value may be particularly time-sensitive.

Secondly we know that requirements vary on an agile project over time, for good reason. Hopefully we are learning as we go, which means we will discover new requirements and decide others are no longer worth pursuing. If we assume about a third of the requirements will be delivered as described (this is generous in light of the Standish Chaos reports), another third will be delivered but with changes, and the last third won’t be delivered at all – but replaced by other features – then we have just wasted all that time and effort in the inception coming up with detailed, high-precision data for a pile of stories we will never deliver.

To compound this, it turns out that estimation is fractal. The more fine-grained you break down the requirements, the more “edges” you will discover. This means that the more detailed you estimate, the more the total will tend towards infinity, simply due to rounding errors and the fear factors that we multiply into fine grained estimates.

Use the inception for deliberate discovery

So what should we be doing during an inception instead of doing the fine-grained story breakdown? Taking it back to first principles we simply want a rough idea of size and an understanding of certainty. There is uncertainty in everything, so the purpose of the inception is to understand the potential landscape we are delivering in.

When we start the inception we know nothing. We want to come out of the inception knowing as much as we could reasonably expect to learn in the time we have allocated. This discovery is along several axes: technical areas such as the technology stack, potential architectures, integration points and external services; domain questions such as how well we understand the problem and whether it is more about research than solving a clearly-articulated problem; people and process challenges like the path to production, identification of stakeholders, how co-located or distributed the team is and how much of this kind of delivery they have done before. For some of these areas, breaking broad requirements into finer-grained detail is a great way to discover more. But not for all of them, and certainly not at the expense of other discovery activities.

There are good arguments from both the Kanban and Real Options folks about deferring the decomposition of feature sets into features and stories until the “last responsible moment”. This means the information is freshest and you aren’t holding an inventory of atrophying information. You might want a couple of weeks of story-level detail – to promote a consistent flow and avoid starving your process – and beyond that a few features identified that will be broken down into the next candidate stories, but beyond that you shouldn’t be worrying about that level of granularity. The experienced members of the team should be estimating feature sets of the order of person-weeks (or better yet, pair-weeks), not going down to the level of individual pair-days. The less experienced team members should be using the exercise as a learning opportunity.

So please, let’s move beyond this cargo cult approach to inception where we slavishly trot out hundreds of stories with their associated estimates, and remember that we are engaging in a process of deliberate discovery.

Its purpose is firstly to convey to our stakeholders and ourselves an order-of-magnitude sense of size – to quote the Pragmatic Programmers, is it larger than a breadbox and smaller than a house? – and secondly to present the risk landscape in which to understand that estimate.

49 comments

  1. A way that works for us is to ask for X time up front.

    Give us 1-2 months to achieve this project. From there on in, we just pick the stories that are most important, and deliver those. We adjust the amount of work to the impending deadline.

    We have one core objective; and everything else ontop of that is just usability / functionality gravy. If the objective is too broad, we redefine it.

    If we come in under time, we either polish it further or just ship it as is.

    Shipping as is lets us return to the business and re-adjust their timelines; so that we are ahead; and simply pick up the next project.

    I find this (1) much more palatable to all involved (2) good for morale (3) do able (4) a hell of a lot better than the inverse.

    1. Hi Daniel.

      I agree that is a great way to interact with your business stakeholders on a small scale. The problem is scaling that to a multi-million dollar programme of work. The business wants to know if the programme is viable and they need some assurance around the scale of the solution. The store is opening in January and you are on the hook for delivering a critical business system by a drop-dead date. The core objective you described looks like a minimum of six months concerted effort. Will it all be ready in time? Are you sure? Can you give me that same confidence?

      The trouble is most businesses still use top-down, budget-driven governance models rather than throughput accounting and incremental funding, so sometimes you simply don’t have the option of “let us run with it for a few weeks/months and we’ll let you know.”

      1. > The trouble is most businesses still use top-down, budget-driven governance models rather than throughput accounting and incremental funding.

        I think you’ve hit a significant nail on the head here, Dan. I’ve worked in many organisations where it’s just as hard to get 5k for a couple of weeks of skunkworks as it is to get 250k for a bigger ‘strategic’ project.

        Your points about cargo cult agile teams doing this sort of big-analysis up front are absolutely spot on, and I do understand that business people need to know whether a project looks feasable, but I feel like software people are still too afraid to just confidently say ‘I don’t know yet’. To me it’s really important that, rather than brushing it under the carpet, we’re clear as software professionals that most of our projects carry a significant degree of risk.

  2. Great post Dan, I totally agree with you.

    I see the problem being the disconnect between the business and the agile (dev) team. The dev teams have gotten hooked up in this wonderful process, where the backlog is king and the customer is happy because they can change at will. All is good with the world.

    The problem, as you describe above, is that the teams hide behind this. They retract to a safe place when asked the difficult questions. To be successful and to deliver business benefit we need the be able to make those ‘educated guess’s’. Business are used to working on the basis of estimate and risk, they do this all the time with Sales funnels. And it is not the dev team that will make the call as to whether the ROI is acceptable.

    AndrewWoody

  3. Jeff Santini · ·

    Here Here!

    When I went on my first Inception back in the day it was a good experience. We spend a good few days with the client. Both sides came out with a lot more knowledge of what life might be like once engaged with each other. While we collected plenty of info on Index cards they weren’t stories. The only time stories came up was in a mock excercise of what a planning game was like.

    By the time of the last inception I was involved with, it was this full blown process as you describe where our ability to adapt to changing situations would be greatly hampered by all these stories that were beginning to look very contract like.

    Jeff

  4. When I first did a project estimation, I was impressed on how useless the metrics of minimum, likely and maximum size, clarity, volatility, etc… are. In both occasions we did some high-level estimations on the project, then spent five hours calculating all this metrics and in the end the result was a 5 points difference in a 200 points project : )

    Cheers,
    Frank

  5. Regardless of development methodology (agile, waterfall, winging it, etc), estimation takes 3 things from the project planner(s)/manager(s): understand the challenge, know your craft, know your team.

    1. @stephane: I think it actually takes a 4th thing too – be comfortable with your estimates being wrong …

      1. @Johny: I’m not disagreeing, but in my experience, the more you master the 3 I listed, the least yours is a concern.

    2. Hi Stephane.

      Even with a project manager with all those characteristics, the business may still be sceptical and unconvinced about the viability of your project. I believe there is a lot we can do during that inception phase to increase that confidence.

      There are many activities I see on inceptions that are fantastic for this, especially when the business challenge is more creative (exploring an opportunity) than prescriptive (solving a specific problem). Things like persona modelling, wireframes, story boards, and many other activities we’ve borrowed from other creative industries. But rather than doing much more of this high value, high discovery stuff we dive into the nitty gritty of fine-grained estimation.

      _(Thanks to Marc McNeill for pointing out there are different factors involved with responding to opportunities vs. problems.)_

      1. Dan wrote, “Even with a project manager with all those characteristics, the business may still be sceptical and unconvinced about the viability of your project.”

        This is your first mistake. It’s not YOUR project. It’s THEIR project. The client is the one who is paying your bills, directly or indirectly, so it can ONLY be considered the client’s project. If the PM says it’ll most likely take 6 years to come to fruition, and the client wants it done in 3, then the client is SOL with that particular project team, now isn’t it? Either the client can axe some features, or it can find a new PM. (And learn the hard way that the original PM was most likely right.)

        This is why extreme programming is the best process to use. Whether you use an on-site client or colocate your dev team at the client’s locale, the fact that you have a tightly knit, indeed almost amorphous, integration of development and business know-how automatically means that the economic sting of featuritis or incessantly changing features becomes all-to-painfully-aware to he who pays the bills, and very prominently puts the burden on the client.

        Where it belongs.

  6. Great post Dan!

    This inspired me to think about the implications of such detailed estimation once a project starts and I started writing about it on my blog: http://www.dtsato.com/blog/2009/07/03/velocity-gone-wrong-done-is-not-done/

  7. Hi Dan, thanks for stopping by this afternoon! think everybody got a lot out of it.

    Still getting my head around what you’re saying, and it seems (perhaps) that you’re not really talking about just “estimation”, which is a rather narrow exercise in analysis. More, it’s about project viability on the whole.

    With real options, we give the business a chance to rearrange or even drop feature sets (or MMFs, whatever you call them) in ways that make sense from a timing and risk point of view. By giving real options we’re not just “estimating” we’re providing feedback to the business about how the project could be tackled, with, if you’re good enough, some idea as the ultimate risk of the various possibilities. But project viability is not just about real options either!

    If I understand you correctly (?), it’s about helping to answer the customer’s question “is this project going to work out for us?”. Which is a lot more than figuring out how many story points there is.

  8. Mike Cottmeyer · ·

    While I totally agree with what you said here in
    principle, what makes this approach unique to Kanban or Real Options?
    This is how you progressively elaborate a traditional project, I have used
    progressive decomposition on RUP projects and every agile project
    I have ever run. People do stupid things in every methodology, maybe
    Kanban is new enough that people just haven’t screwed it up
    yet. Good practice is good practice no matter what you
    label it or how you package it.

    1. Hi Mike.

      I don’t think I was implying these ideas are exclusive to Kanban or Real Options, they just provide a good mechanism for describing why it’s useful to defer the decomposition of requirements.

      The principles of Lean and kanban say you should have no more inventory (in this case fine-grained stories) than you absolutely need to keep a consistent flow, and thinking of the story breakdown as a real option allows you to defer the actual decomposition of the coarser-grained work into stories. My point is that we’ve lost sight of some of this common sense in our desire to assemble a comprehensive story backlog as an artefact of project inception or release planning.

      1. I reread your post and agree I overreacted a bit to the inclusion of Kanban and Real Option. My apologies ;-)

        My general approach is to keep the requirements a a higher level early… identify the detailed stories that validate technical and business assumptions and build them. Once technical and business assumptions have been validated, I am generally more comfortable defining the backlog at a more fine grained level.

        I think you need some agreement from the business that at each checkpoint, as you learn more about the projects, you get an opportunity to reassess the viability of the project/product.

        Mike

  9. Kimie Nakahara · ·

    Hi, your post had left me wondering how, with only some discovery and stories estimated at person-weeks level, we would be able to answer “How long will it take, and how confident are you about that number?”.

    Maybe the biggest issue is not with “How long it will take”, I believe that both methods you described would give an estimation to that. The problem is “How confident are you about that number”. If we say that we can’t answer that or that our confidence is, say, 50%, because we don’t have enough knowledge about the problem yet, they will push us to detail the stories until they get the answer they want to hear: 100%!

    This discussion is very interesting. Thank you!

  10. Hey Dan,

    I agree with every single word that you wrote… Awesome post.
    We need to raise awareness about this issue and we are the ones who can make it better… Let’s change it.. continuous improvement is one of our biggest values.

    When I went to my first inception I wrote something about it with a similar intent to your post, I guess… check it out:

    http://fabiopereira.me/blog/2008/12/18/plan-with-ballpark-numbers/

    IMHO, one of the most important things about your post is the re-definition of “Success” that the big upfront analysis causes… I’ve seen people get so attached to the story list because they had already spent time on it (estimation, prioritization, volatility, clarity, xity, yity… and sometimes even acceptance criteria is already written), they DO NOT WANT TO CHANGE IT… OMG, what? isn’t one of our biggest values to “accept changes instead of following a plan”? :)

    I’ve seen the “short term ahead detailed plan” and “long term overall plan” work a couple of times on projects and I totally agree with you that this is the way to go…
    I’ll “spread the love” about this post and try to improve as much as possible…

    Cheers Dan,

  11. I would recommend adding to the list of estimation techniques on new projects the use of data from old projects (estimation by analogy). This becomes very useful before you are at the stage where you begin defining the features. Your estimates as this stage should come with a wide confidence range. Once you have data on the specifics of the project, you can begin to employ bottom up estimation techniques to get more accurate data based on the specific customer and development team.

  12. Anupam · ·

    Estimates are always estimates. They are almost like the published schedule of a busy urban transit system; the time is given for arrival and departure of all trains and buses at the start of the year (or season) however the trains and buses can run late (compared to the scheduled time table) depending on the traffic scenarios or excess rain or natural disasters etc.

    When the business is interested in implementing in a multi-million dollar project, the stakeholders are interested in not only knowing the to-be implemented ‘solution’ to their problem(s) but also how soon can the solution be delivered and what will it cost. Business wants to know the schedule, the ‘time table’ and its our responsbility and job as experienced consultants to deliver a tentative release plan based on our estimates and projected velocity. If the first round of estimates for a ‘public’ release of the product to be build is 865 story points, then let be it. So in this case, 865 points worth of master story list or initial product backlog is the initial projected capacity that will help the business address one or more problems in X number of days. The suggested capacity is based on the projected velocity and initial round of estimations (ideally most team put contigency estimates to mitigate any implementation risks before signing on the dotted line).

    Obviously the master story list is going to evolve over the time of implementation due to multiple reasons which includes detailing of epics, new requirements, change in vendors, de priortization of requirements etc. If its a fixed capacity project (hence fixed cost), set the expectation with the business stakeholders that whenever NEW story points are added to the MSL, equivalent story points needs to swapped from the MSL to keep the capacity constant. So the product owner and business stakeholders are always involved in making sure that only the highest priority stories/requirements/problems are going to be delivered in the release. This is what the lean folks have named as MMF or Minimum Marketable Feature. If this is not a fixed capacity project, then swapping of the story points might not be needed at the release level however the effort to prioritize stories at an iteration/sprint level will still be the biggest factor to make sure that the team is working to deliver the right thing.

    If the business feels that 865 is too big of a beast to built and release in public, then thats good news too. Now the business is going to look at the story list and prioritize once more to see what they ‘really’ need. So IMHP,early estimates from a detailed inception is always critical to success of a project.

  13. Hey Dan – have you been listing in on our office? I’m just finishing a big inception and your article sums up a lot of my current thinking.

  14. Some great SOA …

    Some great SOA …

  15. Deliberate discovery. As opposed to accidental discovery? Or any other sort of discovery? Why add the extra word ‘deliberate’?

    1. The extra word ‘deliberate’. As opposed to the extra song deliberate? Or any other sort of deliberate? Why add the extra word ‘word’?

  16. Suman Thareja · ·

    The piece about the “The business started out by defining success as solving the problem, but now we have redefined success as delivering this list of stories” really made me think..

    I found myself reflecting and thinking about how often at a review we asked the question “Sponsors are we closer with this sprint to solving your problem” vs. here’s the number of points / stories we completed and here’s the sprint burndown. Not very often.

    Will need to be more conscious of this in the future..

  17. Lalatendu Das · ·

    Hey Dan..

    Nice post..
    One point that needs further clarification – “how to implement throughput accounting and incremental funding driven governance model”? Based on your experience can you share some pointers on how a project is funded / measured in a governance framework.

    My guess if unless we solve that problem, the need of upfront estimation will always be a challenge.

    LD

  18. Silvia Todorova · ·

    Nice article Dan! I do agree that a lot of agile teams are missing the point of the release planning when they try to layout all stories and spend too much time in estimation (very time consuming process as we all know); instead we should focus on understanding the problem at hand, who are the stakeholders that need to be involved, structure the project properly, understand the architecture, the risks, etc. so that we convey how big the project is, show a good understanding of the potential risks and how the estimates may be affected by it. I would like to hear from you how you actually suggest to accomplish this during the early inception/ discovery of the project. What specific approaches have you seen working well?

  19. Scott Townsend · ·

    I agree it’s really important to make estimates easily consumable and relevant for the target audience. Spending a lot of time generating estimates with false precision is not a fruitful exercise, and in fact can mislead the project sponsors and get the development team in a lot of hot water! In my experience, sponsors find the most value in estimates that communicate the rough size of the project (cost and timeline) along with margin of error, which can be large in the early phases of a project.

  20. Yva Montalvo · ·

    Interesting article. My key takeways:

    – The idea of the estimation exercise in Inception is not to provide accurate timelines to the business but to provide a sense of size (building a car vs. airplane) and for the team to understand potential risks

    – Keep requirements at a higher level and do just enough to understand and identify those stories that validate technical and business assumptions. Defer the breakdown of stories until necessary (this will allow to adapt to changing requirements, flexibility in the overall process and most importantly avoid waste)

    – Experienced team members should be estimating stories in person weeks; junior team members should learn/observe; I thought this point was very interesting as in my organization we have all team members participate in the estimation exercise. Different approach that is worth trying to see the impact on the project and how team adapts…

  21. By trying to bring precision to estimates we would conflict ourselves. It was true in case of big upfront analysis in the past and hold true in case of long list of stories at inception. Nice article!

  22. By trying to bring precision to estimates we would conflict ourselves. It was true in case of big upfront analysis in the past and hold true in case of long list of stories at inception.
    Nice article!

  23. Bhaven Sheth · ·

    The business will always be interested in project cost and timelines. This helps them to determine their return on investment. But does it really? There are many factors, other than cost, that can help to determine if the investment is a wise one.

    Wouldn’t it be better if we asked the right questions to help them determine the appropriate way to look at estimates, and ultimately ROI? Such as:
    – What problem are we solving?
    – How do we know when it’s solved?
    – Are we improving productivity?
    – Are we improving efficiency and saving time?
    – Are we providing a service that is not currently available? What do we anticipate they will do with this service?

    Asking the right questions (as each project will be different) will help the Business to focus (and prioritize) on what’s really important first, and if the project will achieve the appropriate goals.

  24. Belkis Vasquez-McCall · ·

    Hi Dan,

    This is a great article! We sometimes focus so much on the stories, and estimations that we lose sight of what’s the goal of the project. Last week I asked a sponsors what is project success to them and their answer was “that all stories in the backlog are delivered”…

    Here are my key takeaways from your article:
    – Some team adopt a new process and just try to fit the new process into their own way of working (backlog/stories points as a contract, etc..)
    – Inception/Discovery is critical for the project success and many teams fail to realize this
    – The art of creating/grooming/maintaining a backlog is something that every team should invest in
    – Project estimation is something that teams struggle with whether is RUP, Scrum, Kanban
    – People have the false perception that “more analysis = better estimation”

    One of my teams is currently in the discovery phase and we are planning to do release planning in two weeks. Would anyone be willing to collaborate with me in preparing for the release planning (e.g., share practices that have worked for you, creative ways to do release planning, etc..)?

  25. Thanks for sharing this Dan.

    Although we have been practicing Agile/Scrum for over 2 years now your post is quite interesting to me mostly because experience has proven that we do not do a very good job of estimating and I think this is mainly due the fact that we always want to size the whole project from the beginning, even though this is not truly Agile. As a result teams do begin with a Discovery phase however it seems we still get caught up in too many details for which there are many variable.

    One of you points that stands out most to me is the 3 axis’ you mention. Currently teams engage in story boarding and estimating at the story level. However, given that a large % of the stories with change or go away, this is hardly precision and in fact feels very waterfall. I personally am a fan of the SWAG process to initially get a feel for cost. Using the 3 axis you mention, while working with experienced resources, to estimate each axis at a high level based on prior experience, comparing prior projects that feel like this and then roughly estimating seems to work just as well.

    I personally have not been on too many projects where we even came within 5% of the original estimate. I suppose the pitfall here is stakeholders typically have their mind on two things; 1. when will I get this (even though they don’t know what “this” is); 2; and how much will it cost. I know you clearly mention this but this is a mindset that needs to be adjusted in order to get better at a process that is not really science. Back of the envelope has proven to be just as good as detailed plans.
    Mitch

  26. Belkis Vasquez-McCall · ·

    Hi Dan,

    This is a great article!We sometimes focus so much on the stories, and estimations that we lose sight of what’s the goal of the project. Last week I asked a sponsors what is project success to them and their answer was “that all stories in the backlog are delivered”…

    Here are my key takeaways from your article:
    – Some team adopt a new process and just try to fit the new process into their own way of working (backlog/stories points as a contract, etc..)
    – Inception/Discovery is critical for the project success and many teams fail to realize this
    – The art of creating/grooming/maintaining a backlog is something that every team should invest in
    – Project estimation is something that teams struggle with whether is RUP, Scrum, Kanban
    – People have the false perception that ‘more analysis = better estimation’

    One of my teams is currently in the discovery phase and we are planning to do release planning in two weeks. Would anyone be willing to collaborate with me in preparing for the release planning(e.g., share practices that have worked for you, creative ways to do release planning,etc..)?

  27. [...] This article is a very interesting read for everyone that works in a project. It deals with the perils of time estimation of a project and the underlying thesis is that the further you break things down to estimate the time of each piece of work to do, no matter if you are doing agile stories or some other way of organising your work, the longer the project estimate will be. This is beacause the more fine-grained you break things down the more factors like rounding errors, lead times to start each task and some general fear factors will be multiplied in and create a longer over all project time. As the granularity approaches zero the time to complete the project approaches infinity – we have in short a fractal time. [...]

  28. [...] rounding errors and the fear factors that we multiply into fine grained estimates.” — Dan North ▶ No Responses /* 0) { jQuery('#comments').show('', change_location()); [...]

  29. [...] am still trying to resolve the difference between the customer’s business model and Agile. As Dan North writes: “The trouble is most businesses still use top-down, budget-driven governance models [...]

  30. Hello from Germany! May i quote a post a translated part of your blog with a link to you? I’ve tried to contact you for the topic The perils of estimation « DanNorth.net, but i got no answer, please reply when you have a moment, thanks, Gedicht

    1. Hi Gedicht.

      Sorry for the delay getting back to you. Of course you are welcome to translate anything you like from my site, as long as you credit me as the source.

  31. [...] the morale? quoting Dan North’s Perils of estimation: The business started out by defining success as solving the problem, but now we have redefined [...]

  32. [...] Estimating in the agile world! May 4, 2011 tdittmer Leave a comment Go to comments I’ve read this article by Dan North – the perils of estimation [...]

  33. This really is Awesome! Thanks a ton.

  34. [...] Customer buy-in: You need to find a customer that is able and willing to make business decisions independently from the cost of the wanted MMF. From my experience with Scrum, it is hard enough to convince customers that they don’t need a detailed project plan with a big design up front. How can you justify abandoning release and sprint planning (and sprints for that matter) all together? Here Arlo draws from his experience by using the Naked Planning process with his team. In his experience, the ‘Disneyland wait time’ (the time for the 7th item on the queue to go into production) is usually never longer than 90 days. This means the customer can plan with the seven most valuable MMFs within 3 months. Further reading on estimation: The perils of estimation (Dan North) [...]

  35. [...] isn’t helped by common practices of estimation and the associated promises, which often lead to that pressure building up in the first place. Rather than making these [...]

  36. Is there a standard rating system for estimation of software development tasks?…

    There are different methods of achieving something like you described. Methods as COCOMO, Function Points (FP), Use Case Points (UCP) and other similar ones rely on specifying different parts of a task and then add their estimates to come with an overa…

  37. [...] Dan North came up with a great insight a couple of year ago in a piece he wrote, ”the perils of estimation”. [...]

  38. [...] then Liz Keogh pointed me at Dan’s blog on The perils of Estimation. Read it [...]

  39. [...] me you would know I’m not a big fan of estimates, mostly for the reasons better explained here, here and here, but there are still moments within a project where there are a bunch of stories [...]

Follow

Get every new post delivered to your Inbox.

Join 473 other followers

%d bloggers like this: