Re: [scrumdevelopment] How to estimate the project with scrum
- Hi, Jorge,
On 12/30/10 1:47 PM, Jorge Rowies wrote:
> Ron/Woynam, I couldn't agree with you more.
> Perhaps I didn't explain myself correctly (English is not my native
> language) but I was thinking on a context where the people on the top of
> the organization is not that mature on agile as what you are describing.
It's not a question of agile maturity. It's a question of business
acumen. The business environment changes during the course of a
project. Estimates are just estimates. If your profit or loss is
dependent on a precise, accurate prediction of the cost, then you've
chosen the wrong product. The upside potential is too small.
Often I find that the people on the top of an organization understand
this, but the managers in the middle often do not.
> What I was trying to say is that, even if we manage to have stories
> equally sized to avoid estimations (thus, also avoiding the problems Ron
> described earlier), there are points in your project when you have to
> deal with estimations, and that information have to be public.
Is it "have to be" because someone said so? Or do you have a reason to
need that information.
> If the organization is not mature enough, "the bosses" would take those
> estimates and stick with them (which is wrong, I know that).
All the more reason not to give estimates.
Another approach is to pad the estimates. I used to triple them, and
find that not enough. I couldn't predict how much scope would be added
after giving the estimate.
> So, unless you give them information about how those estimates change
> (because you have acquired more knowledge about the product and/or
> technology, or you have more information on what the customer needs are,
> etc...) they would have in their minds only the initial estimate you
> gave them and they will assume that it's written in stone. (which is
> wrong, again)
> What I think is, starting a project with estimates (to have a rough
> understanding of how much is going to cost, etc.) and then stop doing
> estimates and just focusing on creating stories equally sized just for
> the upcoming sprints is not something that will work in organizations
> that are not really mature in agile (I'm talking of the people on the
> top, not the actual team of devs, SM, PO, etc.)
> I'm with you in all you said, but I'm trying to understand if/how this
> 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? ;)
You might find
helpful on this topic. Otherwise, "if you can't change your
organization, change your organization."
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
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