Re: [scrumdevelopment] How to estimate the project with scrum
- On Dec 30, 2010, at 5:01 PM, Jorge Rowies wrote:> I'm with you in all you said, but I'm trying to understand if/how this> <http://upload.wikimedia.org/wikipedia/commons/thumb/1/12/Niag715.jpg/800px-Niag715.jpg>,
> could work on my organization and in many others that are agile-oriented
> because it's cool but when it comes to contracts and negotiate with the
> customer how the project would be, they are like this> (I don't think I'm alone in this ship, am I? ;)Something I think you should clarify, also. Are you being asked for estimates or for commitments? An estimate is an educated guess based on the information currently available. Estimates are *always* either high or low, and usually low when building complex software. They are not commitments and can't be used as commitments.To turn an estimate into a commitment, you must add some padding to cover unexpected eventualities. To NOT do so is unprofessional as you're making a commitment you almost certainly *know* you will not be able to deliver on.Also, if a commitment is required, the scope has to be fixed (or better still, the time and budget should be fixed so you can collaborate instead of fighting over what is and isn't a change request). If the client can say "what about if I enter a negative number into the transfer field" or "I'd rather have that over there" or "that's good but not what I had in mind" then the scope isn't fixed as there could be an indeterminate number of such changes. When you truly explain to a client what a fixed scope project is (anything that meets the spec is acceptable, any changes they request are charged separately) they often realize that it isn't such a good idea for them.Best Wishes,Peter
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.
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 firstname.lastname@example.org, "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 email@example.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: firstname.lastname@example.org
> > 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 Email:kiran@... Ph-India-(+91)9823378726 Ph-UK-(+44)2070239006 Ph- US-(+01)6178307605