Sprint retrospective meeting question...

I have a question about the SECOND part of the sprint retrospective meeting.

I see that most training allows only "pigs" to attend the retrospective
meeting; 
i.e. the Product Owner is NOT allowed to attend.
(I view this is a good thing.)

Why is it not acceptable for the Product Owner to attend?   

What about other non-team members attending?    E.g. management?

(I'm expecting there can be psychological issues if 
management or other members of the company attend.  E.g. the 
Team does not get the opportunity to have an open meeting to 
discuss any issue.  I fear such a meeting will not be 
viewed as something "for the Team's benefit".)

Thanks for any input.

Jeff

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:

Re: Sprint Review vs Serial Report

On 28 Feb 2006 at 16:33, Thierry Thelliez wrote:

> 
> I am looking for ideas to improve our Sprint reviews. The main issue I
> see is that not all the team members are engaged in the review. The
> Sprint Review ends up being like a `Serial Report´ meeting where
> some individuals seem to be loosing their time. 

Our review format is pretty straight forward.

Agenda:

10 minutes -- Review improvements made since the last retrospective.  This is the "We 
listened" part of the meeting.  If there isn't at least one thing there, then what was the point of 
the last retrospective (or you are executing perfectly -- This hasn't happened yet).

30 minutes -- I go around the room asking each person for a constructive observation about 
the previous iteration.  It's key to get everyone to provide input.  If they can't think of 
something constructive to say, then say something positive (something that went well, that 
you'd like to see us continue doing).  During this period, I allow some discussion.  It's not a 
traditional brainstorming format.

15 minutes - I go through the list of items, and I ask folks to silently "vote" for those things 
that they feel "impacted" them the most.  I put in place the "silent" rule because I found a few 
louder individuals were "talking up" points in prior retrospectives.

I make a quick "High / Medium / Low / none" estimation based on the number of hands.  I 
circle the Highs, and we talk a bit about what we might do in the upcoming iteration to 
alleviate some of the concerns.

Re: User Stories

On Tuesday, February 28, 2006, at 10:44:46 AM, p.eckert wrote:

> I have a qustion about user stories (or features, or whatever people
> wish to call them).

> Online there is a bunch of information on what makes a 'good' stoy or
> a 'bad' story, but the examples do not seem to help me much.  I do not
> have a context to put them in.

> Would any of you be willing to share with me some of your 'good'
> stories, just so I can visualize how they should look?  I would like
> to see how real stories look vs the ones I see in books and online.

There's a wide range of "good". See my remarks on Card,
Conversation, Confirmation for reasons why I find the following
stories just fine.
http://www.xprogramming.com/xpmag/EXPCardConversationConfirmation.htm

  When ATM is out of cash, display an error message until customer
  hits Enter key or for 15 seconds. Then return customer's card.

  Overtime work accrues hours at 1.5 times hours worked on any day
  except Sunday. On Sunday, hours accrue at 2 times hours worked.

  After ten days, remove a new book from the "Just Came In" display
  page on the Library Web Site.

  Customer can order paint color and interior color according to
  this table:
    PAINT   INTERIOR

Scrum and XP...

Another scrum question...

The more I "do scrum" the more I suspect XP is more appropriate for applying
scrum-like methodology to developing software.

After all, scrum (afaict) embodies a lot of XP's "project methodology"
aspects, though scrum does not address any coding/programming aspects.

I'm starting to find that effective scrum requires programming models such
as TDD.  XP already has this all sorted out.

Do scrum teams end up migrating to XP?

Jeff

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Re: Scrum and XP...

On Tuesday, February 28, 2006, at 7:07:31 PM, Jeff wrote:

> Do scrum teams end up migrating to XP?

Many do. Much of what I've been doing lately is introducing XP
practices to Scrum teams.

The thing is that for Scrum to work, the team has to come up somehow
with technical practices that let them produce software that is
known to work by the end of each Sprint. XP offers core practices
that are a good start at doing this.

Some time ago, if I'm not mistaken, Mike Beedle talked about a blend
of XP and Scrum that he called XP <at> Scrum. More recently he has taken
the position that practices much like the XP practices have always
been a part of Scrum. That may be the case, though they aren't
mentioned in the Scrum books, as far as I know.

But primacy of invention or whose name is on the book isn't what's
important. What's important is that a Scrum team needs to come up
with some coherent and effective set of technical practices, in
order to do their jobs effectively. The XP literature offers one
convenient package of practices that are a good start.

Regards,

Ron Jeffries
www.XProgramming.com
One test is worth a thousand expert opinions.
  -- Bill Nye (The Science Guy)

Re: Sprint Review vs Serial Report

Re: Sprint Review vs Serial Report

what benefits can sub tasking bring to developers?

Re: what benefits can sub tasking bring to developers?

On Tuesday, February 28, 2006, at 10:50:24 PM, kittys shu wrote:

>   How can we persuade developers to do this? Or, in other words, what are the big and obvious
> benefits for them to show their private working steps?

I like to see the team brainstorm the technical tasks that are to be
done, but to see user stories signed up for, not tasks. (By the way
"user story" is, as far as I know, an XP term, not a Scrum term.)

Brainstorming the technical tasks is an explicit albeit small design
step and therefore it benefits the team by keeping everyone aware of
the intended design of each story, and allowing everyone to
contribute.

Signing up for stories rather than tasks keeps the team focused on
story completion, not task completion. Thus, I prefer it.

Ron Jeffries
www.XProgramming.com
It is a bad plan that admits of no modifications. -- Publius Syrus (ca. 42 BCE)

To Post a message, send it to:   scrumdevelopment <at> eGroups.com
To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe <at> eGroups.com 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/scrumdevelopment/

<*> To unsubscribe from this group, send an email to:
    scrumdevelopment-unsubscribe <at> yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Re: Scrum and XP...