• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

resources (links,books) for topic software estimation?

 
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi there,

i am quite into developing and things run as i wanted the only thing is, that sometimes it takes longer than i wanted. am looking for some aid for that.
so can you recommend good books, links, articles on the topic 'software estimation'?

what about: 'software estimation, demystifying the black art'? i am a bit suspicious about microsoft press books... so far mostly of them did NOT pay off the reading.

thank you.

[ April 27, 2006: Message edited by: manuel aldana ]
[ April 27, 2006: Message edited by: manuel aldana ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I haven't read it yet (it's on my virtual book stack ), but I've heard very good things about Mike Cohn's "Agile Estimating and Planning".
 
manuel aldana
Ranch Hand
Posts: 308
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
once again
has anybody read 'software estimation, demystifying the black art'?

in amazon this book has got good reviews and the content sound promising but as i said, i am very cautious about buying microsoft press books...
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by manuel aldana:
I am very cautious about buying microsoft press books...


Don't sweat it about Microsoft Press books. Yes, they have a mixed catalog but if you avoid them you might be missing out on some good material. Go By the author. Steve McConnell is more likely to turn out good material rather than bad. Code Complete, Rapid Development and Software Project Survival Guide are classics. After the Gold Rush and Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers not so much.

So far I have read only 8 of 23 chapters (103 of 270 pages). So far it's (as expected) mainly about dispelling misconceptions and general guidelines.
  • Distinguish between targets and estimates.
  • Even the best estimate during project inception may over or underestimate a project by a factor of four � i.e. you can do much worse. (The cone of uncertainty).
  • Even a project that finished on time and on target usually isn't the project that was initially estimated.
  • Developers DO NOT generally overestimate. Developer estimates are usually too optimistic by 20 to 30%
  • Project effort does not scale linearly, it scales up exponentially due to factors contributing to "Diseconomies of Scale".
  • Count if at all possible. Compute when you can't count. Use judgment alone only as a last resort. (Don't give of the cuff estimates.)
  • etc.

  • I expect that the remainder of the book deals with the collection of relevant historical project data, and acceptable computation practices, tools, presentation, politics.

    See the Book Outline on the author's website.
    [ April 30, 2006: Message edited by: Peer Reynders ]
     
    (instanceof Sidekick)
    Posts: 8791
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Making an initial estimate before starting a project is a difficult step that everyone has to do regardless of their methodology. Being off by a factor of four (mentioned above) is a wider "cone of uncertainty" than I had heard before, but not surprising. If it comes from metrics on real projects, I could believe it.

    What you do with estimates and how you deal with reality once things get going is very much part of project management methods. If you hang around here much you'll find us favoring the "agile" flavor of management. I think the honesty and transparency the agile methods provide in tracking estimates to reality and reality to future plans are a fantastic improvement over other methods I have been subjected to in the last (cough)30 years. Look for "velocity" and "planning" topics here http://www.extremeprogramming.org/ and other agile sites.
     
    author
    Posts: 608
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    You might find Comparing Approaches to Budgeting and Estimating Software Development Projects to be useful.

    - Scott
     
    Peer Reynders
    Bartender
    Posts: 2968
    6
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Stan James:
    I think the honesty and transparency the agile methods provide in tracking estimates to reality and reality to future plans are a fantastic improvement over other methods I have been subjected to in the last (cough)30 years.



    Of course Steve McConnell is a bit more cautious � he has to avoid the "one-size-fits-all" trap.

    He acknowledges that most business executives (8 out of 10) will choose "predictability" over "agility" (i.e. the ability to change the requirements). Nearly all executives chose option 2 of the following:
  • Deliver a project with an expected duration of 4 months, but it might be 1 month early and it might be 4 months late.
  • Deliver a project with an expected duration of 5 months (rather than 4) and it will be completed within a week of that date.


  • Option 2 requires that you have a much better handle on the (amount and quality of the) requirements to come up with an accurate estimate (though it accepts a certain amount of "waste"). As far as I can tell it is notoriously difficult to predict the total project duration for highly agile methods � they usually make up for it by generating the most business value possible within any given time period while minimizing waste. But this is a hard approach to sell in the "can you deliver functionality X by date Y � if you can't we don't even need to start" situation.

    He breaks down software development styles in the following manner:
  • Evolutionary prototyping (iterative) � Prototype is used define largely unknown requirements.
  • Extreme Programming (highly iterative) � Defines requirements for one iteration only (~1 month). Use when requirements are fluid.
  • Evolutionary delivery (sequential or iterative) � Sequential when most of the requirements are known up front, iterative when hardly any requirements are known.
  • Staged Delivery (sequential for estimation purposes) � Most requirements are defined before construction. Iterations are used for design, construction and test.
  • RUP (sequential for estimation purposes) � RUP describes it's stages as "iterations", but seeks to define 80% of the requirements before construction begins.
  • Scrum (iterative for estimation purposes) � Requirements are locked for the feature set that is implemented in the current 30-day sprint. An individual sprint is sequential (for estimation purposes), but a project will tend to perform multiple sprints, making it iterative.


  • Ever since the initial publication of Kent Beck's Extreme Programming I suspected that a team of competent/motivated individuals was a pivotal ingredient to the success of agile methods (i.e. people that are already competent, productive, good at estimating and keeping their commitments without the shackles of a heavy process). It was in Jim Highsmith's Agile Project Management that I had seen this put into print for the first time (p.66 Getting the Right People):


    The agile value of people over process drives the need to get the right people. Process proponents argue that a good process will compensate for less capable staff, and therefore getting the right people isn't as critical to the success as getting the right process. Agilists believe that process can provide a common framework within which people can work effectively, but it cannot replace capability and skill.


    So ultimately process-heavy software development failed because it deluded itself into believing that it could maintain a Warm Bodies mentality and use more readily available, "less capable staff" in the development highly complex products.
     
    Ilja Preuss
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Peer Reynders:
    Of course Steve McConnell is a bit more cautious � he has to avoid the "one-size-fits-all" trap.



    As an aside, that's not the only trap to be aware of - there is also the infamous "but-my-project-is-special" trap.

    He acknowledges that most business executives (8 out of 10) will choose "predictability" over "agility" (i.e. the ability to change the requirements).



    But you typically can't really *choose* predictability. A project can only be really predictable if you expect not to learn much during the project. For IT projects, that's rather rare, I suspect.

    As far as I can tell it is notoriously difficult to predict the total project duration for highly agile methods � they usually make up for it by generating the most business value possible within any given time period while minimizing waste. But this is a hard approach to sell in the "can you deliver functionality X by date Y � if you can't we don't even need to start" situation.



    I'm not sure where this impression is coming from - Agile projects have a rather good record of hitting delivery dates, in fact.

    Extreme Programming (highly iterative) � Defines requirements for one iteration only (~1 month). Use when requirements are fluid.



    That's a misrepresentation. XP teams have release plans that go several months into the future, up to half a year and more. Iterations, on the other hand, are typically one to two weeks in length, not a month.

    And I wouldn't hesitate to use XP with "fixed" requirements.

    RUP (sequential for estimation purposes) � RUP describes it's stages as "iterations", but seeks to define 80% of the requirements before construction begins.



    That's interesting - I'm not sure that Grady Booch would agree. (In fact I'd bet that he wouldn't.)

    Ever since the initial publication of Kent Beck's Extreme Programming I suspected that a team of competent/motivated individuals was a pivotal ingredient to the success of agile methods (i.e. people that are already competent, productive, good at estimating and keeping their commitments without the shackles of a heavy process).



    They are not only pivotal ingredients to the success of Agile methods, but to the succes of development in general.

    One of the advantages of Agile methods is that with their emphasis on feedback, collaboration and humanity, they actively foster team members becoming competent and motivated.
     
    Peer Reynders
    Bartender
    Posts: 2968
    6
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Ilja Preuss:
    there is also the infamous "but-my-project-is-special" trap.


    Every project is special! Use only what is essential � dispense with everything else.

    Originally posted by Ilja Preuss:
    A project can only be really predictable if you expect not to learn much during the project.


    If you learn everything during the project then you have no baseline data for making an estimate in the first place. Unless you have done exactly the same project before � in which case you are not learning anything new the second time around.

    Originally posted by Ilja Preuss:
    Agile projects have a rather good record of hitting delivery dates.


    I'm not talking about hitting targets here. You can identify a particular business pain (with lots of hand waving) that needs to be addressed "no matter what", commit to a certain effort, length and number of iterations, then in hindsight decide whether you are happy with the result and if you are you, declare the whole thing a success. (Basically you are iteratively working towards what you actually need, rather than storming ahead towards something that you thought you needed based on the opinions of the wrong people).
    But did anyone actually estimate how much work will be accomplished in the given time period? Not just one iteration. The entire project, before the project starts. If you don't know the extent of the ultimate product how can you estimate the amount of effort that "it" is going to require? If you don't know the extent of the effort required how can you estimate how long it will take? Yes, you can set a target that you will be working towards X for Y months � but that is not an estimate.
    For any estimate you have to put in some up front work. You need to understand the requirements in enough breadth to estimate the extent of the project; use tracers, spikes or whatever to understand the technical complexities; define the requirements just deeply enough to give you the detail you need to estimate without venturing into premature assumptions. There is the understanding that less detailed requirements decrease the confidence in the estimate, while too much detail results in waste (as you are probably estimating the wrong project anyway).
    Ultimately project control is responsible for keeping the project on target but project control also changes the project i.e. the project that was completed is usually different from the one that was originally estimated.
    According to McConnell a project manager can only keep the project on target (based on an estimate) if the actual effort is within +/- 30% of the estimate.

    Originally posted by Ilja Preuss:
    XP teams have release plans that go several months into the future, up to half a year and more. Iterations, on the other hand, are typically one to two weeks in length, not a month.


    Do those release plans commit to specific features and functionality? It's not very agile if they do. Agility was never about slavishly sticking to a plan. Kent Beck cites "one-to-four week iterations" (Extreme Programming, p.133).

    Originally posted by Ilja Preuss:
    That's interesting - I'm not sure that Grady Booch would agree. (In fact I'd bet that he wouldn't.)



    I think he was referring to this:
    Jacobson, Ivar, Grady Booch, James Rumbaugh, 1999. The Unified Software Development Process, Reading, MA: Addison Wesley. P.387


    15.4.1 Requirements
    With this introduction to the construction phase, we turn next to finding use cases and actors, prototyping the user interfaces, detailing the use cases and structuring the use cases. In the elaboration phase we identified all the use cases and actors; we understood about 80% of the mass but we described in detail something on the order of 20% - from this number we were able to pick a small number (less than 10%) that we needed to implement at that time) because we needed only enough detail to establish the architectural baseline. In the construction phase, of course, we are going all the way to the initial operational system, so we have to carry requirements capture all the way (i.e. identify and detail 100% of them).



    Originally posted by Ilja Preuss:
    One of the advantages of Agile methods is that with their emphasis on feedback, collaboration and humanity, they actively foster team members becoming competent and motivated.



    It's well known by victims of process heavy software development that it sucks life and soul out of you.
     
    Ilja Preuss
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Peer Reynders:
    Every project is special!



    Yes. And at the same time it is likely very similar to most other projects.

    What I'm getting at is that "our project is different, we can't do that here" often in fact just means "I don't know how to do that in our situation". It is just too easy to dismiss valuable advice because "our project is different".

    If you learn everything during the project then you have no baseline data for making an estimate in the first place. Unless you have done exactly the same project before � in which case you are not learning anything new the second time around.



    Most projects, fortunately, are somewhere in between - we know a lot of the fundamental stuff, but we are also missing a lot of details that we should expect to learn during the course of the project.

    That's what allows us to make a rough plan from the beginning, but also makes it necessary to adjust the plan regularly.


    But did anyone actually estimate how much work will be accomplished in the given time period? Not just one iteration. The entire project, before the project starts.



    Yes, of course. Everything else would be economically unsound.


    For any estimate you have to put in some up front work. You need to understand the requirements in enough breadth to estimate the extent of the project; use tracers, spikes or whatever to understand the technical complexities; define the requirements just deeply enough to give you the detail you need to estimate without venturing into premature assumptions.



    Well, yes. Are you somehow suggesting that Agile or XP projects don't do that?


    Ultimately project control is responsible for keeping the project on target but project control also changes the project i.e. the project that was completed is usually different from the one that was originally estimated.



    I'm not familiar with the term "project control", and I'm not sure I understand what you are getting at here.

    According to McConnell a project manager can only keep the project on target (based on an estimate) if the actual effort is within +/- 30% of the estimate.



    Wouldn't a project where actual effort is within +/- 30% of the estimate be +/-30$ off target, typically?


    Do those release plans commit to specific features and functionality? It's not very agile if they do. Agility was never about slavishly sticking to a plan.



    There is a difference between telling the customer what he can expect the team to be able to deliver in six months, and slavishly sticking to that, even if we learn that some other feature set would be more valuable. Agile teams do the former, typically not the latter.

    And I know of no methodology that can *guarantee* delivery of a fixed feature set, at a fixed price, to a fixed date.

    Kent Beck cites "one-to-four week iterations" (Extreme Programming, p.133).



    Lately he is advocating Weekly Cycles (Extreme Programming, 2nd ed., pg. 46).

    In the XP community, two weeks seem to be most common, with a tendency to single weeks.


    I think he was referring to this:
    Jacobson, Ivar, Grady Booch, James Rumbaugh, 1999. The Unified Software Development Process, Reading, MA: Addison Wesley. P.387



    Unfortunately from your quote it wasn't fully obvious whether it was an example or a general recommendation. Anyway, if you google for Booch and XP, you will find statements from him that he thinks Agile/XP and RUP are very much compatible.
     
    Stan James
    (instanceof Sidekick)
    Posts: 8791
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    I think we hit some common ground without knowing it. A bunch of mostly related thoughts ...

    The initial estimate - the one you make economic decisions on like which project should the business fund and which should they pass on - is likely no better or worse for an agile style than a heavily BDUF RUP style. Either team can spend whatever amount of time they need to get a good overall estimate of features & time.

    The next level estimate - after management has decided they'd like to do the project - has been much better for us with stories. We used to estimate by use cases which were too large and fuzzy. Now we estimate by stories which are finer grained and make great sense to the end users and business customers.

    A RUP team (at least ours when it was one) puts more time in on estimates, but we never got the level of granularity that we do now with stories so I doubt they were any better. We certainly put a lot more time into planning. The management team made an 80 page MS Project document that was excruciatingly detailed, unrealistic - driven more by politics and target dates than the estimates - and nearly impossible to update with real progress.

    If you put less time on estimates and plans, you get to put more time into producing software. If Agile coders work as earnestly as RUP coders more days of coding should mean more software.

    Nowadays we do iteration and release planning much as Ilja described. We define a release by what the business wants done. I'd hesitate to say we "commit" to any particular feature. We have a plan. The plan might change in collaboration between AD and business right up to the last iteration. If everyone agrees we can leave something out in order to do something else, there's no talk of missed commitments, just changes in plans.

    I like to see the current iteration planned in detail, the next one in a little less, and the rest of the story / feature backlog out there in a priority order stack of stories. We know the size of the backlog from the estimates, the rate at which we are burning through it from observation, and have a really good idea whether we are on track.

    Any of that useful?
     
    Peer Reynders
    Bartender
    Posts: 2968
    6
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Ilja Preuss:
    That's what allows us to make a rough plan from the beginning, but also makes it necessary to adjust the plan regularly.



    estimate with low confidence => rough estimate => rough plan.
    More detail => estimate with higher confidence => better estimate => adjust plan.

    I'm not criticizing. You are correct - that's how it works.

    Originally posted by Ilja Preuss:
    Yes, of course. Everything else would be economically unsound.



    This is where you lose me. It was my impression (I have been wrong before and I may be once again) that the economic soundness of agile methods stems from the fact that you will always know due to the rapid feedback whether the project continues to generate business value. So if you constrain the effort you will get the maximum bang for the buck, even though you may decide to extend the investment if enough high priority/high value user stories remain. If the project fails to generate sufficient business value, you stop. So the economic soundness is not based on a commitment to any specific effort or specific result in the long term.

    This is why I stated that I feel that it is difficult to predict the total project duration for an agile project (during inception). How can you predict how long it will take until you will run out of high value/high priority user stories? If you stop before that, you are simply deciding to stop work.
  • You generate user stories before you start construction.
  • You start construction when you have enough (but not all) user stories.
  • You continue to add user stories to the stack after you started construction.
  • The developer estimates effort per user story.
  • You predict what user stories will be completed in the current iteration.
  • For each release you release the user stories implemented so far.

  • So when you plan a release you are simply committing to releasing the completed user stories. Unless you lock all the user stories for a particular release you can't make a case for saying that the release was estimated. Initially a rough estimate was used to make the plan � but after that the plan takes on a life of its own. The only thing that seems to get estimated are the user stories.
    Now further into the project you know the effort that was required for the completed user stories, you know how many user stories are on the stack, though you are not sure how many will ultimately make the cut, you know how many new ones went on the stack since you started, at what rate they arrived and how many of those are of a high priority. Now you finally have some data to estimate how far you are from finishing. And the more you get done, the more accurate that estimate will become.

    In Chapter 12 McConnell looks at Mike Cohn's Story Points (which he considers a Fuzzy Logic Proxy-Based Estimation technique). Basically your velocity determines how many story-points you can deliver per iteration. I still fail to see how I can estimate the entire project when I don't know all of the user stories at the beginning and which will ones make the cut? And it was my understanding the agile methods dispensed with this a piori whole project estimation, as you wouldn�t be estimating the project that you end up implementing anyway.

    Originally posted by Ilja Preuss:
    Well, yes. Are you somehow suggesting that Agile or XP projects don't do that?



    I am saying that I am not yet convinced that there can be sufficient data initially to generate an estimate of any reasonable confidence as to when the project will be "finished". (You only have some of the user stories and you have little idea how many more will be coming down the pipe). Instead there is enough data to decide how much time you will need to deliver "something of (sufficient) value" � which can be seen as a reasonable facsimile of being "finished".

    And I�m not saying that to criticize agile methods. It's simply an effective strategy for dealing with the unknown.

    Originally posted by Ilja Preuss:
    I'm not familiar with the term "project control", and I'm not sure I understand what you are getting at here.




    Typical project control activities include removing non-critical requirements, redefining requirements, replacing less-experienced staff with more experienced staff, etc.



    Originally posted by Ilja Preuss:
    Wouldn't a project where actual effort is within +/- 30% of the estimate be +/-30$ off target, typically?



    Apparently my memory is optimistic.


    Problems arise when the gap between business targets and the schedule and the effort needed to achieve those targets becomes too large. I have found that if the initial target and initial estimate are within about 20% of each other, the project manager will have enough maneuvering room to control the feature set, schedule, team size, and other parameters to meet the project's business goals; other experts concur (Boehm 1981, Stutzke 2005).



    Originally posted by Ilja Preuss:
    And I know of no methodology that can *guarantee* delivery of a fixed feature set, at a fixed price, to a fixed date.


    Estimates are requested to determine what price and/or dates are reasonable targets. But to estimate you need at least a ballpark idea what the "fixed feature set" is � and even a "ballpark" idea will lead only to a "ballpark" estimate.

    This all started because of the suggestion in McConnell's example that you may be able to trade agility for predictability. There was nothing "real" about that example � it was a thought experiment to make a point:


    Over the years, the software industry has focused on time to market, cost, and flexibility. Each of these goals is desirable, but what top executives usually value most is predictability. Businesses need to make commitments to customers, investors, suppliers, the marketplace, and other stakeholders. These commitments are all supported by predictability.



    Originally posted by Ilja Preuss:
    Anyway, if you google for Booch and XP, you will find statements from him that he thinks Agile/XP and RUP are very much compatible.


    I know, I know. RUP is a process framework not a process. However the RUP instantiation discussed in that text is definitely of the BRUF/BDUF kind. It's probably due to that text that RUP and BRUF/BDUF are mistakenly used interchangeably.
    [ May 01, 2006: Message edited by: Peer Reynders ]
     
    Peer Reynders
    Bartender
    Posts: 2968
    6
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Stan James:
    Any of that useful?



    I would say that your post is a comprehensive summary (after all my nattering).

    There is still the issue of predictability
    :roll: Just tell the executives to call to their astrologers.
     
    Ilja Preuss
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Peer Reynders:
    It was my impression (I have been wrong before and I may be once again) that the economic soundness of agile methods stems from the fact that you will always know due to the rapid feedback whether the project continues to generate business value.



    That is true, but in my experience not sufficient in most cases.

    Most often, your stakeholders will have a specific problem that they want to be solved, and they have a good idea of when they want it to be solved and how much they are willing to spend. They won't even start the project if you can't tell them with confidence that their problem can be solved inside those constraints, and I think they are right to do so.

    That might still mean that they later learn that they were wrong and stop the project early - or that they can get much more value and therefore want to extend the project. Still, they often have less money than projects they cold spend it on, so they need a rough whole estimate of project costs to decide which projects to start and which ones to simply forget about.


    How can you predict how long it will take until you will run out of high value/high priority user stories?



    You can't. What you can predict is whether you will be able to generate enough value for the customer that he won't be likely to want to cancel it early.

    So when you plan a release you are simply committing to releasing the completed user stories.



    I'm also making a first rough guess on which stories will get implemented. That's important for a number of reasons (one of which is marketing, for example).

    Unless you lock all the user stories for a particular release you can't make a case for saying that the release was estimated.



    This is where you lost *me*. I don't see why I have to lock the stories to estimate the release. Of course the estimate will likely change when we change the content of the release, but that doesn't invalidate the value of the estimate, does it?


    Initially a rough estimate was used to make the plan � but after that the plan takes on a life of its own.



    That's not quite how I would say it - it sounds like the plan gets out of control or something. It's exactly the opposite what happens - the plan is tightly controlled and checked against reality.


    I still fail to see how I can estimate the entire project when I don't know all of the user stories at the beginning and which will ones make the cut?



    The typical project, in my experience, has a fixed length and fixed costs. You estimate how many of the original stories can be done, and you later change the plan by replacing lower value stories by higher value ones. And sometimes the customer really happens to find some more money he can spend...

    And I�m not saying that to criticize agile methods. It's simply an effective strategy for dealing with the unknown.



    Understood and agreed. It's just that a starting estimate is typically still of high value, even if we know that the plan will be changed later.


    --------------------------------------------------------------------------------

    Problems arise when the gap between business targets and the schedule and the effort needed to achieve those targets becomes too large. I have found that if the initial target and initial estimate are within about 20% of each other, the project manager will have enough maneuvering room to control the feature set, schedule, team size, and other parameters to meet the project's business goals; other experts concur (Boehm 1981, Stutzke 2005).

    --------------------------------------------------------------------------------



    I see. I misunderstood what you meant by "off target".


    --------------------------------------------------------------------------------

    Over the years, the software industry has focused on time to market, cost, and flexibility. Each of these goals is desirable, but what top executives usually value most is predictability. Businesses need to make commitments to customers, investors, suppliers, the marketplace, and other stakeholders. These commitments are all supported by predictability.

    --------------------------------------------------------------------------------



    I'm not convinved that it's that black and white. In fact I'd argue that what business people want is a balanced mix of predictability and flexibility.

    Another thing I'm not convinved about is that Agile projects are actually less predictable than more conventional ones. After all, when talking about Agile teams, we are talking about teams that deliver running tested features week for week, and who get massive feedback about their quality of estimation and planning, who know how much they are able to do in an iteration.




    quote:
    --------------------------------------------------------------------------------
    Originally posted by Ilja Preuss:
    Anyway, if you google for Booch and XP, you will find statements from him that he thinks Agile/XP and RUP are very much compatible.
    --------------------------------------------------------------------------------


    I know, I know. RUP is a process framework not a process. However the RUP instantiation discussed in that text is definitely of the BRUF/BDUF kind. It's probably due to that text that RUP and BRUF/BDUF are mistakenly used interchangeably.
     
    Stan James
    (instanceof Sidekick)
    Posts: 8791
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    BTW: After all the fine talk I did about our team moving from RUP to something more agile, I got our next release plan today. With the help of senior management and the project office team we have reinvented the waterfall. The 6 weeks of analysis at the start and 8 weeks of testing at the end kinda gave it away. I have a granddaughter to feed, so I guess I'll show up and see how this goes.
     
    Stan James
    (instanceof Sidekick)
    Posts: 8791
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    RUP is a process framework not a process. However the RUP instantiation discussed in that text is definitely of the BRUF/BDUF kind. It's probably due to that text that RUP and BRUF/BDUF are mistakenly used interchangeably.



    My team learned RUP (beta 0.9) from Rational consultants who were on site with us for most of a year. In 1996. It was darned B everything UF. Any reputation it gained for that kind of style in the early days was deserved.

    Booch and Rational have since embraced almost all the agile ideas, maybe because they believe it, maybe because marketing required it. I laughted out loud when I first heard it. An agile team would opt out of an awful lot of the RUP and Rational tools. That's a perfectly valid thing to do as a RUP process engineer, but I don't think Rational had agile in mind when they made RUP up. It felt like they were playing catch up for good ad copy.

    I've read and heard Booch say the main thing he doesn't buy is "emergent architecture." Last I heard, he still thought it was worth doing more architecture up front than agile leaders might.

    My own contribution to agile RUP is this quip: A story is a promise to have a conversation and the use case is the record of the conversation.
     
    Peer Reynders
    Bartender
    Posts: 2968
    6
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Ilja Preuss:
    What you can predict is whether you will be able to generate enough value for the customer that he won't be likely to want to cancel it early.


    Which is what I was getting at with "there is enough data to decide how much time you will need to deliver 'something of (sufficient) value' � which can be seen as a reasonable facsimile of being 'finished'."

    Originally posted by Ilja Preuss:
    I don't see why I have to lock the stories to estimate the release. Of course the estimate will likely change when we change the content of the release, but that doesn't invalidate the value of the estimate, does it?


    In my view changing the story mix invalidates the estimate unless the total story point count doesn't change (significantly) � however at this point I think that is just stating the obvious.

    Originally posted by Ilja Preuss:
    It's exactly the opposite what happens - the plan is tightly controlled and checked against reality.


    I didn't express myself clearly. What I was getting at is that the estimate is used to select a reasonable target and the plan is devised towards meeting the target. Project control is about the plan and the target. Estimate, target and plan should not be confused with one another. Estimates are only important initially and when a project is re-estimated (which subsequently may impact the target and/or plan). In between the estimates its all about the plan and the target � that is what I meant when I said that "plan takes on a life of its own".

    Originally posted by Ilja Preuss:
    The typical project, in my experience, has a fixed length and fixed costs. You estimate how many of the original stories can be done, and you later change the plan by replacing lower value stories by higher value ones.


    And this still sounds like a requirements phase to me. It may be "requirements-lite" and it may not be BRUF � but it still is a requirements phase.

    And I think that's maybe what Steve McConnell's thought experiment was based on � maybe, just maybe you can enhance the predictability of a project if you spend just a little bit more time on the requirements � much in the spirit of Scott Ambler's middle of the road approach.

    Originally posted by Ilja Preuss:
    I'm not convinced that it's that black and white. In fact I'd argue that what business people want is a balanced mix of predictability and flexibility.


    To continue the quote from above:


    None of this proves that predictability is the top priority of your business, but it suggests that you shouldn't make assumptions about your business priorities.
    Tip #10: Many business value predictable more than development time, cost, or flexibility. Be sure you understand what your business values the most.



    Originally posted by Ilja Preuss:
    After all, when talking about Agile teams, we are talking about teams that deliver running tested features week for week, and who get massive feedback about their quality of estimation and planning, who know how much they are able to do in an iteration.



    You have already emphasized that your business values predictability of development time and cost over predictability of features. The choice in the thought experiment implied that you have to accept a certain amount of waste (by spending more time in the requirements phase) and inflexibility towards requirements changes later, in order to enhance predictability. Granted, this goes against the grain of agile methods as you may end up with a system with features of little or no business value. Also some predictability may be possible in the short term but predictability is next to impossible to achieve in the long term.
     
    Peer Reynders
    Bartender
    Posts: 2968
    6
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Stan James:
    With the help of senior management and the project office team we have reinvented the waterfall.



    The Agilistas Handbook
     
    Ilja Preuss
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Originally posted by Peer Reynders:
    And this still sounds like a requirements phase to me. It may be "requirements-lite" and it may not be BRUF � but it still is a requirements phase.



    Yes - it's XP's exploration phase - see chapter 21 of the first edition.
     
    Ranch Hand
    Posts: 84
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator


    Booch and Rational have since embraced almost all the agile ideas, maybe because they believe it, maybe because marketing required it.
    ....
    ....
    I've read and heard Booch say the main thing he doesn't buy is "emergent architecture." Last I heard, he still thought it was worth doing more architecture up front than agile leaders might.


    Four or five years ago I was at a conference where there was a panel discussion. The panel was setup like a heavy weight championship bout. In one corner, there was one of the creators of RUP, and, in the other corner, they had a similar expert/spokesperson/evangelist from the XP Camp.

    It turned out to be more of a love-in than a slugfest. What surprised me the most about the ensueing discussion was that even though the crowd tried to provoke a disagreement or argument between the two sides, it really seemed that both sides were more in agreement than anything else.

    I am not surprised about RUP embracing agile ideas. Also, I find more and more approaches where agile blends in a *little* more upfront design and analysis.
     
    I claim this furniture in the name of The Ottoman Empire! You can keep this tiny ad:
    We need your help - Coderanch server fundraiser
    https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
    reply
      Bookmark Topic Watch Topic
    • New Topic