Re: estimating user stories or use cases?
- To be fair, the product owner only heard of Agile/Scrum about the time
I was taking the training. The other folks I'm working with vary
between not knowing anything about it to knowing about it from what
they read on agilealliance and other sources. It's not really been
implemented the way it should within our part of the organization.
I'm really trying to shoehorn Scrum into something that was already
well underway by the time I came along with my newly minted CSM
certificate. Therefore, it's going to take a bit of churn to get
everyone to understand Scrum and agree to use it in ways that will
benefit the project.
If you have tips for how to turn a non-Scrum project into a Scrum
project, I'd be grateful.
Thanks again for the advice and guidance.
--- In email@example.com, Nicholas Cancelliere
> It sounds like a standard "plan for failure" type of project. I hear
> the scenario all too often. So is it that you need to estimate the
> work and then decide from the "vendor" how many resources you need to
> hire to get it out the door by X date? Or is it that if the advanced
> estimates come out to be no-doable the entire project is going to be
> I guess I would need to understand why the dates are so critical.
> In any regards - having your team estimate work that the vendors will
> be doing, that seems like an issue. Does your product owner
> understand his role in the project? Is there a backlog developed in
> priority order?
> On Feb 1, 2008, at 1:46 PM, proud2b4family wrote:
> > I agree that those not doing the work should not be estimating the
> > work. Thanks for the clarification. This is one of those projects
> > where estimates are being asked for in advance of the vendors coming
> > on board because we have such short turnaround time and we need
> > answers as to the schedule start and end dates. I'll have to find
> > some other way to deal with that matter. Does Scrum say what to do
> > when product owners have gone completely nuts? ;)
> > --- In firstname.lastname@example.org, Nicholas Cancelliere
> > <nickaustin74@> wrote:
> >> 1) The people who will be doing the work should be estimating the
> >> stories ... not someone else. (So have your vendors estimate them.)
> >> 2) If your team isn't doing the work (eg because the vendor is) I
> >> don't see how they can estimate it.
> >> I am a little worried about your approach, as it sounds like command
> >> and control. I worry about the idea that you're having individuals
> >> (regardless how savvy they are) doing estimates for work being done
> >> by
> >> other individuals. This doesn't feel like a good practice to me and
> >> not one that I encourage with my own Scrum implementations.
> >> You want to have the people doing the work be the ones estimating and
> >> committing to the work. This means you will need to include the
> >> vendor's folks on your own team, as integrated team members. Then do
> >> group estimation using planning poker on story items, get gross and
> >> detailed estimates on the backlog, let the team then commit to work
> >> they feel they can accomplish sprint by sprint, etc.
> >> You can't have a self-directing, self-organizing team unless they are
> >> the ones committed to the sprint goal, one of their own making. Else
> >> you're taking some responsibility away from them, and the more you do
> >> that the more you're being C&C.
> >> Nicholas
> >> On Feb 1, 2008, at 9:22 AM, proud2b4family wrote:
> >>> I've just gotten back from Ken's seminar and am now attempting to
> >>> introduce it to my team. There are several issues I'd like to ask
> >>> about:
> >>> 1) Our immediate task is estimation of user stories, but:
> >>> a. we have a limited team of 3 technology savvy individuals
> >>> who won't necessarily be the implementers of the user stories
> >>> (vendors are coming on for that, but later)
> >>> b. the 3 team members don't feel the user stories are "fleshed
> >>> out" enough to estimate, even in spite of my training them on
> >>> planning poker and the idea that estimating and prioritizing user
> >>> stories is an incremental approach and not meant to be the final
> >>> estimate.
> >>> c. they still want to write full-blown use cases and estimate
> >>> those using planning poker. Is that going to cause any problems?
> >>> 2) The team members are not used to the "self-managed teams"
> >>> approach to development. As a consequence, I feel that I need to
> >>> take on too much of a command-and-control role when my intention is
> >>> just to train them on the principles of self-managed teams and then
> >>> observe and advise (as well as help the team with the mountain of
> >>> work). What transition techniques have any of you found successful
> >>> in switching over from the top-down management to the self-managed
> >>> team? Is it appropriate for the Scrummaster to actually do some of
> >>> the work?
> >>> (Sorry, I know, RTFM and RTFAQ, but I'm hoping for forgiveness just
> >>> this once and to get real-world perspective vs. "running to the
> >>> prescriptive process").
> >>> Thanks.
> >> --
> >> Nicholas Cancelliere, CSM/CSP
> >> Austin, TX
> >> Certified Scrum Practitioner
> >> Certified Scrum Master
> >> Over 10 years of web application development experience and an Agile
> >> nut!
> > To Post a message, send it to: scrumdevelopment@...
> > To Unsubscribe, send a blank message to:
> > Yahoo! Groups Links
> Nicholas Cancelliere
> Austin, TX