Re: Re: Maintenance Projects? (Re: Scrum Exception Cases Summary for feedbac

Hello, David!

If a feature has a defect, it is not done.  There are a couple of ways  
to handle it, fix it or put it on a list somewhere.  My preference is  
to fix it, then inspect our engineering practices to identify ways to  
improve and adapt so that we don't release defects to our customers.

We will never be perfect, but we can get better!  8^)

GB.

Quoting David A Barrett <dave.barrett <at> lawpro.ca>:

>> Now in this situation when you have a bug in the
>> process you cannot wait: it has to be fixed now
>> (within the minute for critical things and most often
>> within the day)
>
> One thing strikes me about this.  A bug that can be fixed "within a
> minute" is by definition trivial.  Any bug that has an urgency level of
> "fix within a minute" is also going to require handling outside of any
> formal project management methodology (other than tell the users, "Here's
> the number you call when this happens"), simply because there won't be any
> time to do any project management.
>
> So it seems that as long as your team has the ability to determine whether
> or not something is trivial, or whether or not the business really does
> need it fixed "right now", you shouldn't have trouble with Scrum.
>
> Seriously, a problem that you can fix "within a minute" isn't going to

Re: When managers estimate on behalf of the team in sprint planning

>
> As a scrum master, what approach you have done to convince the manager to
> let the team do the estimation in sprint planning? In one organization, the
> manager does not trust the team to do the estimation hence he makes all the
> story points instead of the team.
> 
> Anyone care to share?
> 
Here is a simpler, direct approach I use - my belief is the people who do the work get to estimate the work.  If
the individual in question provides the estimate, then he\she is suggesting that he\she will complete
the task. 

I would ask if he\she is making a commitment to complete the task since he\she is the one providing the estimate?

See where that goes...

Carlton 

------------------------------------

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

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:

Re: When managers estimate on behalf of the team in sprint planning

>
> Well, you could start by not inviting him to the Sprint planning meetings.
> 
+1

That works very well.

Carlton

------------------------------------

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

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    scrumdevelopment-digest <at> yahoogroups.com 
    scrumdevelopment-fullfeatured <at> yahoogroups.com

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

Re: When managers estimate on behalf of the team in sprint planning

I was being somewhat facetious, but...

This one is so fundamental, so basic, it's not something you finesse. 

There's three points that come to mind right away.  The first is that the manager, if he's not the PO or on the
Development Team, is a chicken.  Chickens don't come to Sprint Planning meetings, and if they do, the sit
quietly in a corner and keep their mouths shut.  

Secondly, but just as important.  One of the keystones of Scrum is that the developers estimate and get to
pick how much they are going to commit to for each Sprint.  Nobody.  Nobody gets to tell the Development Team
how much they will commit to.

Thirdly.  This is what the Scrum Master is for.  He has two jobs:  clear impediments and make sure that the Scrum
process is followed properly.  This is a clear breach of the Scrum process and the SM here needs to step in and
stop the manager from getting involved in the planning process.  End of story.  Otherwise this is going to be
another one of those companies that say, "Oh, we tried Agile/Scrum but it didn't work for us".

I'd put this in the same class as Ken's story about not being able to get whiteboard for the Team room.  So he
started writing on the walls.  Whiteboards showed up the next day.

dave

--- In scrumdevelopment <at> yahoogroups.com, Joshua Partogi <joshua.java <at> ...> wrote:
>
> On Mon, Oct 31, 2011 at 10:30 PM, David A Barrett <dave.barrett <at> ...>wrote:
> 
> > **
> >
> >
> > Well, you could start by not inviting him to the Sprint planning meetings.

Re: When managers estimate on behalf of the team in sprint planning

I agree with you on the 2nd point, but not the first. I assume the manager is a stakeholder, so they have a right
to attend the planning meeting and provide input.

Where is it written that stakeholders do not attend the planning meetings?

Unless they are a complete pointy-haired boss, I assume they have some insight into the business and
technical side of things, otherwise they're probably just using up oxygen.

That said, at some point after the details of the PBI's have been discussed, and the team feels they have
enough information to estimate the item, the manager should butt out and let the team estimate the item.

Mark

--- In scrumdevelopment <at> yahoogroups.com, "barrettdab" <dave.barrett <at> ...> wrote:
>
> I was being somewhat facetious, but...
> 
> This one is so fundamental, so basic, it's not something you finesse. 
> 
> There's three points that come to mind right away.  The first is that the manager, if he's not the PO or on the
Development Team, is a chicken.  Chickens don't come to Sprint Planning meetings, and if they do, the sit
quietly in a corner and keep their mouths shut.  
> 
> Secondly, but just as important.  One of the keystones of Scrum is that the developers estimate and get to
pick how much they are going to commit to for each Sprint.  Nobody.  Nobody gets to tell the Development Team
how much they will commit to.
> 
> Thirdly.  This is what the Scrum Master is for.  He has two jobs:  clear impediments and make sure that the
Scrum process is followed properly.  This is a clear breach of the Scrum process and the SM here needs to step

Re: Re: When managers estimate on behalf of the team in sprint planning

On Nov 1, 2011, at 8:48 AM, "woynam" <woyna <at> argonne.com> wrote:

> Where is it written that stakeholders do not attend the planning meetings?

If what's written is important to you, you could read the last two of Ken's books for a pretty good starting
point. 

I remember a Sprint Planning Meeting at one of the most bureaucratic places I've seen.  The Team and PO were
there, along with a dozen observers.  Even though the tourists kept quiet, the conversation between team
and PO was stilted.  The next time we did it without the tourists and got a much more candid negotiation.  The
place for observers is the Sprint Review Meeting. 

--mj

------------------------------------

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

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

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/scrumdevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:

Re: When managers estimate on behalf of the team in sprint planning

I would argue that regardless if you're agile or not, noone is better at estimating than the ones building
the stuff. 

--- In scrumdevelopment <at> yahoogroups.com, "woynam" <woyna <at> ...> wrote:
>
> 
> Unfortunately, a percentage of individuals will not embrace agility. Many of us have seen this
throughout the years. After investing in training and coaching, they're not ready to give up their
command and control ways. I've seen this happen with developers as much as managers. As much as we like to
think that people embrace self-determination, there are those who simple want to show up to work and be
told a) what to do, and b) how long to take. Sigh.
> 
> We often joke that developers have "Miranda Rights". 
> 
> "You have the right to estimate your tasks. If you do not provide an estimate, one will be provided for you
free of charge." 
> 
> This poor attempt at humor often helps get newcomers over the hump, typically people who were used to
having estimates handed to them.
> 
> In some cases, as others have pointed out, the inability to provide an estimate is a sign of deeper
organizational issues. In one case, I spoke with a developer offline who was worried that any number they
give could contradict a number that their boss had given someone outside the team. Rather than possibly
incur the "wrath" of the boss, it was better to just shut up and let the boss do the estimating, since they
always provided estimates in the past. Double sigh.
> 
> Mark
> 
> 
> --- In scrumdevelopment <at> yahoogroups.com, "frede_swe" <fredrik.vestin <at> > wrote:

Re: Re: When managers estimate on behalf of the team in sprint planning

Re: Re: When managers estimate on behalf of the team in sprint planning

Re: Re: When managers estimate on behalf of the team in sprint planning