Re: [scrumdevelopment] How to estimate the project with scrum
- Hello, Kurt. On Thursday, December 30, 2010, at 3:23:32 AM, you
> I thought the scrum guide specifically allocates this activity to theYes. It does say that.
> second part of the Sprint planning meeting, after the team has
> determined with the PO which backlog items to take on in the sprint,
> and the PO has optionally left, the team then comes up with the list
> of tasks required to implement each backlog item.
> Which is a great idea. It forces estimates and planning etc to focusPlanning at this time allows us to focus on the system as it is, and
> on the problem rather than getting bogged down in discussions and
> details about the solution.
the system as it needs to be after this backlog item is done. That's
a good thing.
Considering the tasks that need to be done is one way to do this.
Estimates are not a good thing in most organizations: they are used
as commitments and bludgeons. They also lead to a mechanistic
approach to deciding how much work to take on, adding up points or
hours, rather than a deeper look at what the team can accomplish,
and how. As such, I no longer recommend doing such estimates and
have never recommended publishing them.
Scrum calls for the team to draw a line in the proposed Sprint
backlog, saying "we can do this much".
Actually parceling out the tasks across the team turns out not to be
the best idea. This tends to leave no one feeling responsible for
getting the actual feature done. When Sprint Backlog Items are all
tasks, it is quite common for ninety percent of the tasks to be
done, and no stories done.
Bottom line, on the ground, I find that breaking features down into
smaller features, and doing the work at that level works better. I
find that estimates beyond "OK, we can do that many" are often
harmful and quite often waste.
I'm not bad, I'm just drawn that way. -- Jessica Rabbit
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