Loading ...
Sorry, an error occurred while loading the content.

Re: [scrumdevelopment] How to estimate the project with scrum

Expand Messages
  • Ron Jeffries
    Hello, Jorge. On Thursday, December 30, 2010, at 6:40:10 AM, you ... Yes. I recommend not estimating stories at all, beyond making them all a couple of days
    Message 1 of 34 , Dec 30, 2010
      Hello, Jorge. On Thursday, December 30, 2010, at 6:40:10 AM, you

      > What do you mean with "I no longer recommend doing such estimates", do you
      > mean that you don't estimate at all? Could you elaborate a little more on
      > this?

      Yes. I recommend not estimating stories at all, beyond making them
      all "a couple of days work for a couple of people". That is, of
      course, still a kind of estimate, but not one that is easy to

      Ron Jeffries
      A long range weather forecast should be obtained before leaving,
      as weather conditions are extremely unpredictable. --Natal Daily News
    • Kiran
      Make or buy decisions,lot of variables comes into the play. cost to produce + maintenance cost + customer service  cost + etc etc depending on nature of your
      Message 34 of 34 , Jan 2, 2011
        Make or buy decisions,lot of variables comes into the play.

        cost to produce + maintenance cost + customer service  cost + etc etc depending on nature of your product.

        Not sure if scrum fits in here.

        On 1/2/2011 4:26 AM, Roy Morien wrote:

        I was in this position once upon a time, abd the lessons that I learned about selecting a 3rd party package basically boiled down to:

        1. Ensure that you have a very thorough demonstration of the packaged software, at which you ask how the package does the things that you see as being important to you.

        2. Do not spend time telling the salesman how you do things ... that just lets them off the hook as they quietly listen to you wasting your time and not screwing them down to details and they will always agree that their software will do that just perfectly.

        3. Determine how much you are willing to change your ways to accommodate the way the package does things. This is very important.

        4. It is not especially relevant, in my view, how many other people use the software ... that is current installations. A new software package may very well be the best of product, but yet have little following due to it being newly available in the marketplace.

        5. A Package under $1,000 will probably be great, and do what packages under $1,000 do, but I almost guarantee it's not for you/.

        Well, I could go on with lots of wordly wisdom that just supports the view that you better know what that package does before you commit, and you better know what it doesn't do before you commit.

        And for really expensive packages, there is no reason to believe that it is the cheapest option. I could grow a lot of watermelon in my own garden for $1,000,000 plus. Beyond that, Mark's option a is pretty standard stuff, and very common.

        And finally, regardless of any option, estimates will always be guesses, and when managers ask for comparative estimates, you can bet your bum that they are looking for solid figure that they can beat you with and hide behind when it proves to be incorrect, as it will inevitabley, indubitably and definitely be.

        Roy Morien

        To: scrumdevelopment@yahoogroups.com
        From: woyna@...
        Date: Fri, 31 Dec 2010 15:43:30 +0000
        Subject: [scrumdevelopment] Re: How to estimate the project with scrum


        My experience has taught me that a) building it yourself will always be harder, and take much longer than you expect, and b) software salesmen are basically lying weasels, and the software you purchase will not do 50% of what you want it to do, resulting in you living with the limitations, or reverting to option 'a'. :-)

        So, the estimation process is really no different. For option 'a', you use the techniques described in this thread to generate a number, and then multiply it by 2 or 3.

        For option 'b', take the cost of the acquired software, and multiply it by 2 or 3.


        --- In scrumdevelopment@yahoogroups.com, "toomuch2do914" <lynn.cowan@...> wrote:
        > Any insight into how to approach project estimation when the PO is asking, "Should we buy it or should we build it?" There are two epics here: one for the effort to integrate some TBD purchased product with ours and another for building a similar product and integrating it with the rest of our product. Any case studies of how someone using scrum has successfully worked through this? Thanks.
        > --- In scrumdevelopment@yahoogroups.com, "Markus Gaertner"<shino@> wrote:
        > >
        > > Scrum states that the product owner is responsible to take care of having a Product Backlog which is prioritized and estimated most of the time. The contents of the Product Backlog include user stories which might be on a more coarse level like epics, or finer levels which can be pulled into the next iteration. From this perspective you should have an emergent backlog of stories that you want to work on with some stories ready to go, and others on the shelf where you need new information in order to start working on them - i.e. acceptance criteria.
        > >
        > > Epics are usually on a coarse level of confidence regarding their estimates. They are broken down later into finer stories. The sum of the estimates of the stories often does not map to the estimates of the epic. They are usually larger or smaller, thereby incorporating the knowledge that was gained in the meantime, and reflects the purpose of estimation: To get a hunch about the size of your project.
        > >
        > > Now, there are two common scenarios for projects with Scrum. Either your scope is fixed, then you should be able to negotiate about the time you will be able to deliver the functionality. The story estimates will give you an overview and together with your current velocity you can extrapolate different delivery dates based upon the certainty you have in your story estimates.
        > >
        > > The second scenario is to get get a something finished at some point in time. Then you can extrapolate from your backlog what functionality is likely to be finished by then - again using your story estimates together with your team's velocity. Apply varying factors of uncertainty to make pessimistic and optimistic estimations about which features will be included in that release at that point.
        > >
        > > Since all your team members are working fulltime on your project, you will either have a fixed time - which is easy to calculate the project personnel costs for - or you will have a variable project delivery time. In the second case, you use your optimistic and pessimistic estimations, and calculate your costs accordingly.
        > >
        > > Agile Estimation and Planning from Mike Cohn elaborates on this topic.
        > >
        > > Best
        > > Markus Gaertner
        > > http://blog.shino.de
        > > Twitter: @mgaertne
        > >
        > >
        > > ----- Original Message -----
        > > From: mchlsync@
        > > To: scrumdevelopment@yahoogroups.com
        > > Date: 30.12.2010 03:37:43
        > > Subject: [scrumdevelopment] How to estimate the project with scrum
        > >
        > >
        > > > Hello,
        > > >
        > > > I have a few questions related to the Scrum estimation.
        > > >
        > > > 1. Why doesn't Scrum allow us to have a detailed task under user story in
        > > > backlog? The only way to create the task is that we need to move the user
        > > > story to the sprint and then we can create the tasks for the user story.
        > > >
        > > > 2. I heard that we should not estimate more than one or two sprints because
        > > > we will have to change them later. But it doesn't really work in reality. We
        > > > need to estimate the whole project or a few features in advance so we can
        > > > negotiate the target date and adjust/prioritize the features. In order to
        > > > estimate more accurately, we need to break down the user story into the task
        > > > before creating the sprint. How should I handle or estimate for that?
        > > >
        > > > Basically, how can we estimate the timeline for large project or large
        > > > features? Thanks.
        > > >
        > > > Thanks and Best Regards,
        > > > Michael Sync
        > > >
        > > > Don't go the way life takes you.
        > > > Take life the way you go
        > > >
        > > > http://michaelsync.net
        > > >
        > >

        With Regards,
        Kiran Badi
        Ph- US-(+01)6178307605
      Your message has been successfully submitted and would be delivered to recipients shortly.