28471Re: [scrumdevelopment] Re: What's the meaning of "Adjusted Planning Velocity"?
- Apr 7, 2008Velocity number to be used as a tool, it assumes "all things being the same..." So the team can look at it to tweak their commitments: Do we feel our pace is sustainable? No - take on less work, yes - take on more work. As a product owner you can use velocity to try and guess when features will be taken on by the development team.
Anything beyond this and you're starting to move away from empirical methods -- which I think Scrum is about. Scrum is an empirical approach to project management, we go with what we know and what we've observed. Crazy math computations to divine the future are not what Scrum is about. (I still want to know how you quantify "togetherness" as a factor of 0.6 to 1!)
Change a team membership, change the technology stack, etc ... the velocity will change too. There is no magic formula other than time and observation.
NicholasOn Mon, Apr 7, 2008 at 2:12 PM, Dan Rawsthorne <dan.rawsthorne@...> wrote:
I agree with Jim. In fact, I like to use velocity only for release
strategies, to look way into the future. For sprint planning I prefer
commitment based planning, which causes the team to actually look at the
stories in front of them,
Dan Rawsthorne, PhD, CST
Senior Coach, Danube Technologies
dan@..., 425-269-8628> <mailto:scrumdevelopment%40yahoogroups.com>, "Mark Levison" <mlevison@...>
James S. Fosdick, PMP, CSP wrote:
> I don't deny that that's what it's for. My argument is that it is a
> flawed strategy. In my opinion velocity based planning in sprint 1 is
> very dangerous. It takes several sprints to calibrate your velocity
> metrics so trying to base a committment on them (before you have them)
> doesn't make sense and is certainly not improved by adding a bunch of
> cruft. Rather the team should decompose backlog items until their
> available time is filled up and than back off one or two items.
> Pretending that we have a "scientific" way of estimating initial
> velocity by adding a bunch of multiplication factors feels very
> "waterfallish" to me. In any case it is definitely 100% voodoo which
> is something agile tries to get away from.
> --- In email@example.com> wrote:
> > I'm sorry James - I think your wrong. I don't have time to go
> through the
> > slide decks from the course but I really do think that this was
> involved in
> > answering the problem of estimating initial capacity so the team has
> > clue as to how many stories they can safely commit to.
> > Of course no someone will cite line and verse proving me a fool.
> > Mark
> > ----------------------------------------------------------
> > Blog: http://www.notesfromatooluser.com/
> > One Year of Scrum: Lessons Learned
> > http://www.notesfromatooluser.com/2007/10/one-year-of-scr.html
> > Aperture vs. Lightroom - best comparisons
> > http://www.notesfromatooluser.com/2007/02/aperture_vs_lig.html
> > Customer Retention Department - Vonage Customer Service Sucks
> > http://www.notesfromatooluser.com/2007/06/customer_retent.html
To Post a message, send it to: scrumdevelopment@...
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links
<*> To visit your group on the web, go to:
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
Nicholas Cancelliere - Austin, TX
CSM/CSP and Rails Developer
"Try not to become a man of success but rather to become a man of value." --Albert Einstein
- << Previous post in topic