Estimations measured in bananas or gummie bears divided by Velocity of your team measured in bananas or gummie bears per sprint equals Amount of sprintsMessage 1 of 3 , May 25, 2007View Source"Estimations measured in bananas or gummie bears" divided by "Velocity of your team measured in bananas or gummie bears per sprint"
equals "Amount of sprints required to complete the job" equals time.
If you know the velocity of your team, and you know the amount of gummy bears to do the job, basically you know the time you will deliver.
If this is your first sprint and you don't know your velocity, you should first make an assumption based on how fast the team thinks they can go, and then as you complete a couple of sprints you get a more realistic number so you update your velocity and this updates your delivery time estimates.
BTW, this has nothing to do with fixed-date projects. In fixed-date projects normally you have to be flexible on features, unless of course you are willing to compromise on quality. Flexing on budget normally doesn't work as adding resources late into the project just makes it worse (mythical man-month).
XavierOn 5/25/07, dc_chat_noir <dc_chat_noir@...> wrote:
What do people think about backlog estimation in time. I only ask
because our product is held for external delivery on a fixed date.
Therefore, as a reality check, time estimation on the product backlog
helps communicate and reassure us and our partner that we at least
believe we can deliver what features we're saying we can deliver to a
The backlog estimates in bananas or gummie bears doesn't really convey
I know, of course, the reality is time estimates may change which is
why the "size" of the backlog item is the thing.
But this is a common conundrum in the game industry where fixed-date
delivery and regular milestone submissions to a fixed set of features
is the norm. The only solution is having a different relationship and
a mutual acceptance that features change (which most parties know.)
Either way though letting go of this fixed-date, agreed feature
delivery is a common problem and makes the Backlog estimation in
"size" alone difficult.
Anyone got any thoughts on this?