scrumdevelopment : Messages : 15933-15962 of 56894

http://www.scrumalliance.org/

There's also one in London late Sept; for the full list see

#15934

From: "Michael Vizdos" <mvizdos@...>
Date: Wed Sep 6, 2006 3:13 pm
Subject: Re: Scrumming in Boston at SD Best Practices

mikev_work

Hi all,

3200 people would be fine, although the dynamics will be different (smile). Once I know the room number, I will post it so people can meet outside. Nothing to stop us from having an informal BoF either....

If anyone if interested in one-on-one meetings, let me know off-line and we can schedule something for Monday or Tuesday next week.

- mike vizdos
www.michaelvizdos.com

On 9/4/06, Mike Cohn <mike@...> wrote:

I got a couple of off-list replies that seem to suggest that many of us want to get together and talk about Scrum even though there's no official "Birds Of a Feather" (BOF) this year at the conference.

Mike Vizdos (Scrum Trainer and member of this group) is running a Scrum roundtable discussion on Tuesday (12 September) at 10:30. I suggest all 3200 members of this list show up at his roundtable and we can discuss Scrum there. (I hope Mike's OK with this and isn't hoping for a small six-person turnout as I haven't run this by him!)

We can also follow up with some lunch discussions. I can't think of a predefinable meeting place for lunch so those who can't attend Mike's Scrum Roundtable, please meet us right outside whatever room that's in. Hopefully all of us interested in further Scrum discussions can travel en masse from the Roundtable to get our lunch boxes and find a suitable place.

I'll see you there.

Regards,
Mike Cohn
Author:
Agile Estimating and Planning
User Stories Applied
www.mountaingoatsof tware.com

Reply | Messages in this Topic (3)

#15935

From: "keiffster" <keith@...>
Date: Wed Sep 6, 2006 3:21 pm
Subject: Re: Scrum Certification in the UK

keiffster

--- In scrumdevelopment@yahoogroups.com, "keiffster" <keith@...> wrote:
>
> Can anyone point me to a Scrum certification course in the UK, the
> only ones I keep finding are either US or Norway based.
>
> Cheers in advance
>
> Keith
>

Cheers everyone for the replies, a bit of more detailed searching on
the news group and some excellent replies found me something in
Manchester in October ( given I am in Leeds, its the closest ).

Not the easiest to find tho, does anyone know of a single source for
Agile training in the UK, or perhaps we need to create one ?

#15936

From: Mike Cohn <mike@...>
Date: Wed Sep 6, 2006 4:44 pm
Subject: Re: Re: Scrum Certification in the UK

mikewcohn

The ScrumAlliance site is meant to be a single source for all training. If you found a class that isn't listed there please notify the trainer. We're trying to make this simple for anyone looking for classes by having that as one place where all classes are listed.

Mike Cohn

Author:

� Agile Estimating and Planning

� User�Stories Applied

www.mountaingoatsoftware.com

On Sep 6, 2006, at 9:21 AM, keiffster wrote:

--- In scrumdevelopment@yahoogroups.com, "keiffster" <keith@...> wrote:
>
> Can anyone point me to a Scrum certification course in the UK, the
> only ones I keep finding are either US or Norway based.
>
> Cheers in advance
>
> Keith
>

Cheers everyone for the replies, a bit of more detailed searching on
the news group and some excellent replies found me something in
Manchester in October ( given I am in Leeds, its the closest ).

Not the easiest to find tho, does anyone know of a single source for
Agile training in the UK, or perhaps we need to create one ?

#15937

From: "Michael Vizdos" <mvizdos@...>
Date: Wed Sep 6, 2006 4:28 pm
Subject: Re: Re: Scrum Certification in the UK

mikev_work

Hi all,

One of the things [anyone] on this list can do is reach out to the independent trainers (yes, I am one) and let them know you are interested. I know I am available, interested, and able to travel (as other trainers are) IF there is enough interest in a location to confirm a workshop.

A group in South America pulled this off successfully using this model.

Hope this helps.

- mike vizdos
www.michaelvizdos.com/scrum

On 9/6/06, keiffster <keith@...> wrote:

--- In scrumdevelopment@yahoogroups.com, "keiffster" <keith@...> wrote:
>
> Can anyone point me to a Scrum certification course in the UK, the
> only ones I keep finding are either US or Norway based.
>
> Cheers in advance
>
> Keith
>

Cheers everyone for the replies, a bit of more detailed searching on
the news group and some excellent replies found me something in
Manchester in October ( given I am in Leeds, its the closest ).

Not the easiest to find tho, does anyone know of a single source for
Agile training in the UK, or perhaps we need to create one ?

#15938

From: Joseph Little <jhlittle@...>
Date: Thu Sep 7, 2006 4:02 am
Subject: ANN: Agile-Carolinas -- talk Sept 14

jhlittle1

We will have the next meeting of the Agile-Carolinas group on
Thursday, Sept 14th.

Arlen Bankston will lead a discussion on Lean, Six Sigma and Agile,
focusing on how they can complement and enhance one another. Arlen
has done work in these areas at a number of large clients in Virginia
and elsewhere, so he can share his real-world experiences. Arlen
works for CC Pace.

The meeting will start at 6:30pm with free pizza and networking. At
7pm Arlen will start his talk/discussion and we will go until 8:30pm
or so. Location in Charlotte (see website below for details).

Please RSVP to jhlittle@... if you will be attending.

The talk with Mark Pushinsky has been re-scheduled for October 5th.

The Agile-Carolinas group has the following resources. Among other
things, you may join (for free):
Web site: http://agile-carolinas.pbwiki.com/
Discussion group: http://finance.groups.yahoo.com/group/agile-carolinas/

Your interest and comments regarding Agile-Carolinas are welcome.
Happy to answer any questions you may have. Especially if you are a
business person and/or not familiar with Agile.

Please pass this on to a colleague or others who may be interested.

Thanks, Joe


Joseph Little
917-887-1669 (cell)

Reply | Messages in this Topic (1)

#15939

From: PaulOldfield1@...
Date: Thu Sep 7, 2006 4:18 am
Subject: Re: Re: Scrum Certification in the UK

pauloldfield1

(responding to Keith)

> Not the easiest to find tho, does anyone know of a single

> source for Agile training in the UK, or perhaps we need to

> create one ?

There is, in theory, a single definitive list of Scrum training

(though I note Boris hasn't added the Manchester gig to

this list.) This includes quite a broad range of Agile topics

but not everything, and is (AFAIK) restricted to certified

Scrum trainers. This list is global, not just UK, but for

now it's easy enough to spot the UK gigs. (see

scrumalliance.org, as previously mentioned)

In case there's enough demand for such a list, maybe one

or more of the local agile interest groups would be prepared

to collaborate to compile one. I know Agile Scotland has

also occasionally organised training courses when enough

local interest has been generated.

Paul Oldfield

#15940

From: "Mark Levison" <mlevison@...>
Date: Thu Sep 7, 2006 1:49 pm
Subject: When to estimate the product backlog?

marklevison

After reading the Ken's first scrum book and some of Mike Cohn's Agile Estimation book � I'm a little confused as to when the team should estimate the product backlog. It seems clear that during the sprint planning meeting we should look at the product backlog and choose the stories that we will work with the Product Owner. Once we've selected the stories, we will break them down into tasks and estimate the number of hours involved etc.

But this begs the question when do we estimate the initial product backlog?

When new stories are added to the backlog do we estimate them as they're added or do we wait until there is a batch?

Thanks
Mark Levison
----------------------------------------------------------------------
Blog: http://www.notesfromatooluser.com/

#15941

From: "Hubert Smits" <hubert.smits@...>
Date: Thu Sep 7, 2006 2:16 pm
Subject: Re: When to estimate the product backlog?

hubert_g_smits

Hi Mark,

Estimate every story when it goes onto the backlog. Few reasons to do this: it gives the product owner information which she can use to prioritize (geeeeee, this is a biggie and it has little value, let me give it a low priority), and it gives an indicator of the total effort to complete the product with all the features listed.

--Hubert

On 9/7/06, Mark Levison <mlevison@...> wrote:

After reading the Ken's first scrum book and some of Mike Cohn's Agile Estimation book � I'm a little confused as to when the team should estimate the product backlog. It seems clear that during the sprint planning meeting we should look at the product backlog and choose the stories that we will work with the Product Owner. Once we've selected the stories, we will break them down into tasks and estimate the number of hours involved etc.
But this begs the question when do we estimate the initial product backlog?
When new stories are added to the backlog do we estimate them as they're added or do we wait until there is a batch?
Thanks
Mark Levison
----------------------------------------------------------------------
Blog: http://www.notesfromatooluser.com/

--

All opinions in this message are my own, and are not necessarily shared by my employer.

#15942

From: "Mark Levison" <mlevison@...>
Date: Thu Sep 7, 2006 2:20 pm
Subject: Do you re-estimate tasks within a sprint?

marklevison

In the first scrum book Ken talks about re-estimating the tasks daily within a sprint. Is that how people are working?

We're working our way through our first sprint and are finding a number of small tasks that we didn't think of during the sprint planning session. Do we generate new estimates for these? Do we do a daily update of the tasks we did think of?

My original leaning was not to do this. My thinking: During every planning session there will be some tasks that we miss and others that we estimate poorly. So instead of trying to update the estimates constantly over the course of our first few sprints I expected we would learn roughly how many estimated hours we could complete in a sprint.

When it comes to updating the estimates constantly � it just seems like additional overhead with only some value. What do you do?

Thanks in advance
Mark Levison
----------------------------------------------------------------------
Blog: http://www.notesfromatooluser.com/

#15943

From: "Thomas Stagl" <tstagl@...>
Date: Thu Sep 7, 2006 2:22 pm
Subject: RE: When to estimate the product backlog?

t.stagl

this is something where we also struggle sometimes. we are two scrum masters within our department, and even we are on two we are doing it different.

the approach which i like a lot is to have the team to estimate the uncommitted backlog items during the running sprint. for sure, it is not possible to estimate all the tasks. but at least it is a good starting point for the next sprint planning meeting.

1) every team member is familiar with the uncommitted backlog

2) some of the hours just need to be reviewed

3) less discussions are needed

this lowers the duration for the sprint planning.

the tasks for the initial uncommitted backlog (for a new customer and a new project) were, until i find something better, always defined in one shot during the first sprint planning meeting. fur sure, the product owner has to have the backlog fully prepared prior to the sprint planning meeting.

any suggestions for improvements are highly appreciated!!!

thanks, tom

From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mark Levison
Sent: Donnerstag, 07. September 2006 15:49
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] When to estimate the product backlog?

After reading the Ken's first scrum book and some of Mike Cohn's Agile Estimation book – I'm a little confused as to when the team should estimate the product backlog. It seems clear that during the sprint planning meeting we should look at the product backlog and choose the stories that we will work with the Product Owner. Once we've selected the stories, we will break them down into tasks and estimate the number of hours involved etc.

But this begs the question when do we estimate the initial product backlog?

When new stories are added to the backlog do we estimate them as they're added or do we wait until there is a batch?

Thanks
Mark Levison
----------------------------------------------------------------------
Blog: http://www.notesfromatooluser.com/

#15944

From: David H <dmalloc@...>
Date: Thu Sep 7, 2006 2:23 pm
Subject: Re: When to estimate the product backlog?

darianlanx

Hubert Smits wrote:

> Hi Mark,
>
> Estimate every story when it goes onto the backlog. Few reasons to do
> this: it gives the product owner information which she can use to
> prioritize (geeeeee, this is a biggie and it has little value, let me
> give it a low priority), and it gives an indicator of the total effort
> to complete the product with all the features listed.
>

Also, in addition to that. The 20% odd something Buffer that you have
during Sprint planning also has about 5% (of those 20%) to estimate new
backlog items that go into the _Produc Backlog_ as you work on the Sprint.

However, please do not make the mistake of trying to estimate a new
backlog item down to the minute.

-d

#15945

From: David H <dmalloc@...>
Date: Thu Sep 7, 2006 2:33 pm
Subject: Re: Do you re-estimate tasks within a sprint?

darianlanx

Mark Levison wrote:

> In the first scrum book Ken talks about re-estimating the tasks daily
> within a sprint. Is that how people are working?
>

If they are diligent, yes.

> We're working our way through our first sprint and are finding a number
> of small tasks that we didn't think of during the sprint planning
> session. Do we generate new estimates for these? Do we do a daily update
> of the tasks we did think of?
>

Yes, definately so.

> My original leaning was not to do this. My thinking: During every
> planning session there will be some tasks that we miss and others that
> we estimate poorly. So instead of trying to update the estimates
> constantly over the course of our first few sprints I expected we would
> learn roughly how many estimated hours we could complete in a sprint.
>

Have a look at Agile estimation and planning and learn not to see hours
as a measure.

>  When it comes to updating the estimates constantly – it just seems like
> additional overhead with only some value. What do you do?
>

The value is transparancy. For your team, for the Scrum Master and the
Product Owner. How else will you know when you are actually done?

-d

#15946

From: "Mark Levison" <mlevison@...>
Date: Thu Sep 7, 2006 2:29 pm
Subject: Re: When to estimate the product backlog?

marklevison

On 9/7/06, Hubert Smits <hubert.smits@...> wrote:

Hi Mark,

Estimate every story when it goes onto the backlog. Few reasons to do this: it gives the product owner information which she can use to prioritize (geeeeee, this is a biggie and it has little value, let me give it a low priority), and it gives an indicator of the total effort to complete the product with all the features

Thanks for the feedback Hubert - doesn't that suggest that I might be getting the team together to estimate every few days (especially in the early phase of the project). In addition I was concerned about the quality of one off estimates. My thinking if we estimate 4-5 stories at once we're likely to have a better sense of their relative costs.

Mark

----------------------------------------------------------------------
Blog: http://www.notesfromatooluser.com/

#15947

From: "Leandro Saad" <leandro.saad@...>
Date: Thu Sep 7, 2006 2:43 pm
Subject: Re: Do you re-estimate tasks within a sprint?

leandro.saad

Yes.

This is how I do it. We update the estimates for Sprint tasks, not Product Backlog items.

It doesn't matter if your estimate is poor or you miss something on the Sprint planning meeting. What matters is that you inspect and adapt frequently and update your estimates.
I generally add itens on the Sprint Backlog during the sprint. All team members are required to update their estimates at the end of the day. Without this, the burn down chart would be useless for you.

--
Leandro Rodrigo Saad Cruz
software developer - certified scrum master
:: scrum.com.br
:: db.apache.org/ojb
:: guara-framework.sf.net
:: xingu.sf.net

On 9/7/06, Mark Levison <mlevison@...> wrote:

In the first scrum book Ken talks about re-estimating the tasks daily within a sprint. Is that how people are working?

We're working our way through our first sprint and are finding a number of small tasks that we didn't think of during the sprint planning session. Do we generate new estimates for these? Do we do a daily update of the tasks we did think of?

My original leaning was not to do this. My thinking: During every planning session there will be some tasks that we miss and others that we estimate poorly. So instead of trying to update the estimates constantly over the course of our first few sprints I expected we would learn roughly how many estimated hours we could complete in a sprint.

When it comes to updating the estimates constantly � it just seems like additional overhead with only some value. What do you do?
Thanks in advance
Mark Levison
----------------------------------------------------------------------

#15948

From: "Jeff Heinen" <jheinen@...>
Date: Thu Sep 7, 2006 2:40 pm
Subject: RE: Do you re-estimate tasks within a sprint?

vercinget_xx

In our teams, the team is the sole owner of the task list. They are encouraged to use it to manage their work (though it's not required), and they add or remove tasks as necessary. They also update estimates daily with how much work is left on the task. We do not track estimates vs. actuals, since the hours spent on tasks are not used to determine how much work the team can commit to. For that we use velocity and team commitment. The task is there largely to show how much work is left in the sprint so that the team can gauge if they are on track to successfully meet the sprint goals, or if they have to adjust their plan for getting it done.

-Jeff

From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mark Levison
Sent: Thursday, September 07, 2006 7:20 AM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Do you re-estimate tasks within a sprint?

In the first scrum book Ken talks about re-estimating the tasks daily within a sprint. Is that how people are working?

We're working our way through our first sprint and are finding a number of small tasks that we didn't think of during the sprint planning session. Do we generate new estimates for these? Do we do a daily update of the tasks we did think of?

My original leaning was not to do this. My thinking: During every planning session there will be some tasks that we miss and others that we estimate poorly. So instead of trying to update the estimates constantly over the course of our first few sprints I expected we would learn roughly how many estimated hours we could complete in a sprint.

When it comes to updating the estimates constantly – it just seems like additional overhead with only some value. What do you do?
Thanks in advance
Mark Levison
----------------------------------------------------------------------
Blog: http://www.notesfromatooluser.com/

#15949

From: "Timothy H. Lund" <thl@...>
Date: Thu Sep 7, 2006 2:48 pm
Subject: RE: Do you re-estimate tasks within a sprint?

thl5901

You're right about wanting to learn roughly how many estimated <units> you can complete during a sprint (this is your velocity), however that estimate should be associated with the backlog item, not the tasks. There is an important distinction that it sounds like you may be missing...

You commit to a set of backlog items which have an associated estimate (days/hours/points, etc) and that estimate should be fixed. However, for each of those items you create tasks which have an hours value associated with them, and that hours value should fluctuate (and hopefully decline) over the course of the sprint.You'll want to generate estimates for any new tasks you find. In addition, you'll want to have the most up-to-date estimate for any given task at any time. The idea is to know how much effort is needed to complete the current sprint's committed backlog.

~Tim

From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Mark Levison
Sent: Thursday, September 07, 2006 10:20 AM
To: scrumdevelopment@yahoogroups.com
Subject: [scrumdevelopment] Do you re-estimate tasks within a sprint?

In the first scrum book Ken talks about re-estimating the tasks daily within a sprint. Is that how people are working?

When it comes to updating the estimates constantly – it just seems like additional overhead with only some value. What do you do?

Thanks in advance
Mark Levison
----------------------------------------------------------------------
Blog: http://www.notesfromatooluser.com/

#15950

From: David H <dmalloc@...>
Date: Thu Sep 7, 2006 2:45 pm
Subject: Re: When to estimate the product backlog?

darianlanx

Thomas Stagl wrote:

> this is something where we also struggle sometimes. we are two scrum
> masters within our department, and even we are on two we are doing it
> different.
>

Not good. As it paints a picture of inconsistence. You should sit down
and adjust this policy so that it i becomes consistent.

> the approach which i like a lot is to have the team to estimate the
> uncommitted backlog items during the running sprint.


As it should be and has been taught :P ( :) )

> for sure, it is not
> possible to estimate all the tasks. but at least it is a good starting
> point for the next sprint planning meeting.
>

Correct, forget about the tasks, estimate the 'story'

-d

#15951

From: "Thomas Stagl" <tstagl@...>
Date: Thu Sep 7, 2006 3:09 pm
Subject: RE: Do you re-estimate tasks within a sprint?

t.stagl

that's also exactly the way we do it. the sprint backlog has to be updated at least on a daily basis.

because, all team members need to know what needs to be done to reach the state DONE on the end of the sprint. it is not transparent for everyone if there is something to be done which is not in the sprint backlog.

when you compare a sprint backlog with a roadmap you can tell on a daily basis where you are exactly to reach your goal, but only when the sprint backlog is maintained. you can just estimate "i think we are here, or maybe way off where we think we are". as David H. mentioned: transparency is important.

From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Leandro Saad
Sent: Donnerstag, 07. September 2006 16:43
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] Do you re-estimate tasks within a sprint?

On 9/7/06, Mark Levison <mlevison@gmail.com> wrote:

In the first scrum book Ken talks about re-estimating the tasks daily within a sprint. Is that how people are working?

We're working our way through our first sprint and are finding a number of small tasks that we didn't think of during the sprint planning session. Do we generate new estimates for these? Do we do a daily update of the tasks we did think of?

My original leaning was not to do this. My thinking: During every planning session there will be some tasks that we miss and others that we estimate poorly. So instead of trying to update the estimates constantly over the course of our first few sprints I expected we would learn roughly how many estimated hours we could complete in a sprint.

When it comes to updating the estimates constantly – it just seems like additional overhead with only some value. What do you do?
Thanks in advance
Mark Levison
----------------------------------------------------------------------

#15952

From: "Hubert Smits" <hubert.smits@...>
Date: Thu Sep 7, 2006 3:25 pm
Subject: Re: When to estimate the product backlog?

hubert_g_smits

Hi Mark,

Thanks for the reply. I've seen different approaches for the estimation of new stories, depending on how confident the team is with the problem domain. If they're really confident, then a single person may estimate new stories. If he gets it wrong then the Sprint planning will correct it, but the overall accuracy should be good enough. If the team is new, then more people look at the stories, maybe in a weekly session with the product owner. If the domain is really complex and new then a few members may work continuously with the product owner during the Sprint, and transfer their knowledge through rotations within the team. Over time you will go from one extreme to the other.

--Hubert

On 9/7/06, Mark Levison <mlevison@...> wrote:

On 9/7/06, Hubert Smits < hubert.smits@...> wrote:

Hi Mark,

Estimate every story when it goes onto the backlog. Few reasons to do this: it gives the product owner information which she can use to prioritize (geeeeee, this is a biggie and it has little value, let me give it a low priority), and it gives an indicator of the total effort to complete the product with all the features

Thanks for the feedback Hubert - doesn't that suggest that I might be getting the team together to estimate every few days (especially in the early phase of the project). In addition I was concerned about the quality of one off estimates. My thinking if we estimate 4-5 stories at once we're likely to have a better sense of their relative costs.

Mark
----------------------------------------------------------------------
Blog: http://www.notesfromatooluser.com/

--

All opinions in this message are my own, and are not necessarily shared by my employer.

#15953

From: Mike Cohn <mike@...>
Date: Thu Sep 7, 2006 5:25 pm
Subject: Re: When to estimate the product backlog?

mikewcohn

Hi Mark--

My recommendation is to�

--first estimate the product backlog before the project starts. A typical team has some level of product backlog written before they "really start" because somebody usually had to write something down to get a project funded or started.

--two or three days before each sprint starts estimate any new stories that came in during the sprint. I usually do this by holding it right after the daily scrum. Suppose our sprint will start on Monday. On the preceding Wednesday I'd normally say something like, "Remember, tomorrow is Thursday so right after the daily Scrum let's hang around for an extra 5-10 minutes to estimate the 4 new product backlog items we've got."� The reason for doing this right before the next sprint is so that the product owner has an estimate on each item. And--as was pointed out--grouping them is more efficient.

Regards,

Mike Cohn

Author:

� Agile Estimating and Planning

� User�Stories Applied

www.mountaingoatsoftware.com

On Sep 7, 2006, at 7:49 AM, Mark Levison wrote:

After reading the Ken's first scrum book and some of Mike Cohn's Agile Estimation book � I'm a little confused as to when the team should estimate the product backlog. It seems clear that during the sprint planning meeting we should look at the product backlog and choose the stories that we will work with the Product Owner. Once we've selected the stories, we will break them down into tasks and estimate the number of hours involved etc.
But this begs the question when do we estimate the initial product backlog?
When new stories are added to the backlog do we estimate them as they're added or do we wait until there is a batch?
Thanks
Mark Levison
----------------------------------------------------------------------
Blog: http://www.notesfromatooluser.com/

#15954

From: Guy Davis <davis@...>
Date: Thu Sep 7, 2006 5:55 pm
Subject: How to plan for "critical issues" that arise

guy_davis2001

Hi all,

I was hoping for some advice.  Our development team runs 2 week
iterations.  We do a mix of release stream fixes and development stream
work during an iteration.  My role is as a developer on the team with
"Scrum Master" duties as well. With only a few key customers, we are
expected to respond very quickly when a problem in the release stream
arises.

We've tried to deal with this by allocating "placeholder" time in a
"release stream" fixes story during the planning meeting. We use
placeholder time (undefined stories) since we never have a full list of
all the issues which will be raised by client services during the
sprint.  All of these issues have been classified as "critical,
show-stopper issues", everything which isn't critical is placed in the
product backlog.

Are these placeholder hours approach a good idea?  Ideally, we wouldn't
allow any new requests (fixes) into the iteration once it begins, but I
haven't been able to sell this to our management who are very concerned
about responsiveness to key customers.

Also, how have teams dealt with being under on sprint estimates?  In the
current sprint, we underestimated some tasks and had many more sick days
taken than expected.  This left us with more hours of effort remaining
than we can complete.

What should be the proper response?  On one hand, we could just say "no
big deal", but then the team will start to not take their commitments
seriously.  On the other extreme, I could start asking for overtime to
meet the original planned commitment.  Is overtime ever a good idea?
Would I be better to "lead by example", putting in overtime just by
myself and hope others might as well.

During the next planning meeting, we'll try to better adjust our
estimates, but I'm wondering about what, if anything, needs to be done
now with 4 days to go.

Thanks in advance for responses,
Guy

Reply | Messages in this Topic (21)

#15955

From: "Pato Jutard" <pato@...>
Date: Thu Sep 7, 2006 6:05 pm
Subject: Burndown Charts and Earned Value

patojutard

I’m starting to implement Scrum in Three Melons, a game studio in Argentina after becoming CSM with the excellent course given by Tobias Mayer over here.

We are going great, but now I want to make progress visible and make some velocity-based estimations, anticipate deviations, have a clear picture of remaining work, know when the team performance is going down and need further motivation, etc

For this purposes I know some people is working with Burndown charts. Am I correct?

I have this resource: http://alistair.cockburn.us/index.php/Earned-value_and_burn_charts

Can someone guide me in this aspect?

What are you people using?

Can you provide any advice or any reference to material that treats this subject?

Thank you very much!

Patricio Jutard
Technology Orchestrator- Three Melons
Argentina: +54 11 4878-0130 int. 201

New York: +1 212 202-1458 ext. 201
pato@...

www.threemelons.com

#15956

From: "Arrowood, Paul (ELS-STL)" <P.Arrowood@...>
Date: Thu Sep 7, 2006 6:20 pm
Subject: RE: When to estimate the product backlog?

arrowoodpaul

Agreeing with Tom Stagl, we had 1-2-3 initial release planning sessions where we quickly put nebulous units of time (NUTs) on every card. Where I’m less confident in what we “should have done” is that our story card detail is the same for those a month out as those that are 3 months out (simple description and very high-level detail if we knew it at the time…..no acceptance criteria or specific design applied). Meaning, we didn’t keep those later stories very high level (i.e. themes or epics)—although we do have some that are 1600 and 3200 points (and we’re only getting 1200-1600 done per iteration) which would really imply there ARE epics right now (until they get decomposed into 1 or more stories that individually fit within an iteration). We use this aggregated number + velocity to discuss backlog (burndown/up) and project dates (if scope is fixed) or scope (if date is fixed). When we get to planning the next sprint/iteration, we identify missing tasks, other work, challenge/update the estimate (merely for the sake of helping identify when the next iteration/sprint is ‘full’). ß Insert Taco Bell joke here. “I’m FULLLLLL!” We do nothing more with that new information regarding estimates, backlog, projecting, velocity, etc.

Agreed on new tasks: we have an “inbox” plastic sleeve up on our wall (on the release plan) and estimate those every week.

Regarding reestimating based on past work, we’re trying to follow Mike Cohn’s recommendation of only reestimating when a stories relative complexity has changed. Velocity tracking/projecting is used as the “great equalizer” to accommodate general inaccuracies. We are trying to get to the point of at least asking the question of each completed card, “Was this estimate accurate?” Maybe the word ‘accurate’ is wrong, but what we’re after is NOT whether it should have been a 4.0 instead of a 2.0, but rather didn’t we learn something significant during the development that changed the card’s relative complexity? If so, we’d want to re-estimate other cards who maybe were based on the same assumption (that changed).

From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Hubert Smits
Sent: Thursday, September 07, 2006 9:16 AM
To: scrumdevelopment@yahoogroups.com
Subject: Re: [scrumdevelopment] When to estimate the product backlog?

On 9/7/06, Mark Levison <mlevison@gmail.com> wrote:

But this begs the question when do we estimate the initial product backlog?

When new stories are added to the backlog do we estimate them as they're added or do we wait until there is a batch?

Thanks
Mark Levison
----------------------------------------------------------------------
Blog: http://www.notesfromatooluser.com/

--

All opinions in this message are my own, and are not necessarily shared by my employer.

#15957

From: Rosemarie Camacho <rosemarie@...>
Date: Thu Sep 7, 2006 6:10 pm
Subject: ScrumMaster Training Opportunities

rolos4slp

The following is the twice-monthly list of ScrumMaster Certification, Product Owner Certification, and other classes taught by Certified Scrum Trainers.

September 11-12 ScrumMaster Certification
Halifax, NS Mishkin Berteig
https://www.berteigconsulting.com/a.php?r=ScrumAlliance

September 11-12 ScrumMaster Certification
Karlsruhe, Germany Boris Gloger
http://www.scrumeducation.com/scrumedu/Class/id~81

September 12-13 ScrumMaster Certification (in Swedish)
Uppsala, Sweden Tobias Fors and Mikael Lundgren
http://www.citerus.se

September 18-19 ScrumMaster Certification (French)
Montreal, Canada Francois Beauregard
http://www.pyxis-tech.com/fr/calendrier/

September 19-20 ScrumMaster Certification
Boulder, CO One of Rally’s trainers: Jean Tabaka, Hubert Smits or Stacia Broderick
http://www.rallydev.com/csm_registration.jsp

September 19-20 ScrumMaster Certification
Fairfax, Virginia Jim York
http://www.ccpace.com/Training_LeanAgile_AgileProjectManagement_SCRUMMasterTraining.htm

September 19-20 ScrumMaster Certification
Atlanta, GA Paul Hodgetts
http://www.agilelogic.com/courses.html

September 21 Implementing Scrum with VersionOne
Atlanta, GA Paul Hodgetts
http://www.agilelogic.com/courses.html

September 20-21 ScrumMaster Certification
Helsinki, Finland Jens Ostergaard, Boris Gloger
http://www.scrumeducation.com/scrumedu/Class/id~108

September 21-22 ScrumMaster Certification
Boston, MA Jeff Sutherland, Ph.D.
http://jeffsutherland.com/scrum/2006/07/scrummaster-certification-in-boston.html

September 23-24 ScrumMaster Certification - Rare Weekend Course!
Toronto, ON Mishkin Berteig
https://www.berteigconsulting.com/a.php?r=ScrumAlliance

September 26-27 ScrumMaster Certification
London, UK Mike Cohn
http://www.conchango.com/Web/Public/Content/Events/ThinkTank.aspx#TT1

September 27-28 Program Management with Scrum Training
Newton, MA Rally’s trainers Hubert Smits, Jean Tabaka and Rally’s Partner, Jeff Sutherland
http://www.rallydev.com/csm_registration.jsp

September 28 Effective User Stories for Agile Requirements
London, UK Mike Cohn
http://www.conchango.com/Web/Public/Content/Events/ThinkTank.aspx#TT1

September 29 Agile Estimating and Planning
London, UK Mike Cohn
http://www.conchango.com/Web/Public/Content/Events/ThinkTank.aspx#TT1

October 9-10 ScrumMaster Certification
Copenhagen, Denmark Jens Ostergaard, Jeff Sutherland
http://www.scrumeducation.com/scrumedu/Class/id~111

October 10-11 ScrumMaster Certification
Santa Clara, CA One of Rally’s trainers: Jean Tabaka, Hubert Smits or Stacia Broderick
http://www.rallydev.com/csm_registration.jsp

October 11-12 ScrumMaster Certification
Kansas City, MO Lowell Lindstrom
http://www.visionpace.com/developereducation.html

October 16-17 ScrumMaster Certification
Manchester, UK Boris Gloger, Tobias Mayer
http://www.scrumeducation.com/scrumedu/Class/id~117

October 19-20 ScrumMaster Certification
Boston, MA Jeff Sutherland, Ph.D.
http://jeffsutherland.com/scrum/2006/07/scrummaster-certification-in-boston.html

October 24-25 ScrumMaster Certification
Las Vegas, NV Paul Hodgetts
http://www.agilelogic.com/courses.html

October 25-26 ScrumMaster Certification
Bellevue, WA One of Rally’s trainers: Jean Tabaka, Hubert Smits or Stacia Broderick and Rally’s Partner, Brent Barton with SolutionsIQ
http://www.rallydev.com/csm_registration.jsp

October 26 Implementing Scrum with VersionOne
Las Vegas, NV Paul Hodgetts
http://www.agilelogic.com/courses.html

October 26-27 ScrumMaster Certification
Weston (Ft. Lauderdale area), Florida Peter Borsella
http://www.winnowmanagement.com

October 26-27 ScrumMaster Certification
Sydney, Australia Jens Ostergaard, Boris Gloger
http://www.scrumeducation.com/scrumedu/Class/id~103

November 2-3 ScrumMaster Certification
Santiago, Chile Tobias Mayer
http://agilethinking.net/latinscrum.html?csm=chile01

November 2-3 ScrumMaster Certification
Melbourne, Australia Jens Ostergaard, Boris Gloger
http://www.scrumeducation.com/scrumedu/Class/id~102

November 7-8 ScrumMaster Certification
Santa Clara, CA Mike Cohn
http://www.acteva.com/booking.cfm?bevaid=112667

November 7-8 ScrumMaster Certification
Buenos Aires, Argentina Tobias Mayer
http://agilethinking.net/latinscrum.html?csm=argentina02

November 9 Agile Estimating and Planning
Santa Clara, CA Mike Cohn
http://www.acteva.com/booking.cfm?bevaid=112667

November 13-16 The Scrum Gathering
Minneapolis, MN The Scrum Alliance
http://tinyurl.com/za9yn

November 29-30 Product Owner Certification
Boulder, CO Ken Schwaber and Mike Cohn
http://www.acteva.com/booking.cfm?bevaid=112909

November 30-1 ScrumMaster Certification
Boulder, CO One of Rally’s trainers: Jean Tabaka, Hubert Smits or Stacia Broderick
http://www.rallydev.com/csm_registration.jsp

November 30 - December 1 ScrumMaster Certification
Johannesburg, South Africa Jens Ostergaard, Boris Gloger
http://www.scrumeducation.com/scrumedu/Class/id~109

December 4-5 ScrumMaster Certification
Cape Town, South Africa Jens Ostergaard, Boris Gloger
http://www.scrumeducation.com/scrumedu/Class/id~110

December 4-5 ScrumMaster Certification
London, UK Mike Cohn
http://www.conchango.com/Web/Public/Content/Events/ThinkTank.aspx#TT1

December 6-7 ScrumMaster Certification
Bellevue, WA One of Rally’s trainers: Jean Tabaka, Hubert Smits or Stacia Broderick and Rally’s Partner, Brent Barton with SolutionsIQ
http://www.rallydev.com/csm_registration.jsp

December 14-15 ScrumMaster Certification
Boulder, CO One of Rally’s trainers: Jean Tabaka, Hubert Smits or Stacia Broderick
http://www.rallydev.com/csm_registration.jsp

December 14-15 ScrumMaster Certification
Boston, MA Jeff Sutherland, Ph.D.
http://jeffsutherland.com/scrum/2006/07/scrummaster-certification-in-boston.html

January 16-17, 2007 ScrumMaster Certification
Lake Mary (Orlando), FL Ken Schwaber and Mike Cohn
http://www.mountaingoatsoftware.com

Feb 8-9, 2007 ScrumMaster Certification
Orlando, Florida Peter Borsella
http://www.winnowmanagement.com

Attachment: vcard [not shown]

Reply | Messages in this Topic (69)

#15958

From: "Hubert Smits" <hubert.smits@...>
Date: Thu Sep 7, 2006 7:02 pm
Subject: Re: Burndown Charts and Earned Value

hubert_g_smits

You mean Tobias didn't teach you this? Oh man, that s*cks :-) Only kidding, I know Tobias is a great trainer.

Possibly better info on Burnbdown charts is on Mountaingoatsoftware.com , with some examples. The principle is that you daily estimate the remaining time for each task. The sum of these (daily) estimates should show a graph going down (hence burndown). The trick is to make the line cross the x-axis on the last day of the sprint! Also look at my site for an example: hubert.blogs.com.

--Hubert

On 9/7/06, Pato Jutard <pato@... > wrote:

I'm starting to implement Scrum in Three Melons, a game studio in Argentina after becoming CSM with the excellent course given by Tobias Mayer over here.

We are going great, but now I want to make progress visible and make some velocity-based estimations, anticipate deviations, have a clear picture of remaining work, know when the team performance is going down and need further motivation, etc

For this purposes I know some people is working with Burndown charts. Am I correct?

I have this resource: http://alistair.cockburn.us/index.php/Earned-value_and_burn_charts

Can someone guide me in this aspect?

What are you people using?

Can you provide any advice or any reference to material that treats this subject?

Thank you very much!

Patricio Jutard
Technology Orchestrator- Three Melons
Argentina: +54 11 4878-0130 int. 201

New York : +1 212 202-1458 ext. 201
pato@...

www.threemelons.com

--

All opinions in this message are my own, and are not necessarily shared by my employer.

#15959

From: Mike Cohn <mike@...>
Date: Thu Sep 7, 2006 7:17 pm
Subject: Re: Burndown Charts and Earned Value

mikewcohn

Brent Barton and some colleagues from Solutions IQ presented a great paper on Earned Value at the Agile 2006 conference. I don't know if a copy of it is online anywhere. Maybe Brent can enlighten us.

Congratulations on taking your game studio to Scrum. Other game developers are having tremendous success with Scrum as well.

Regards,

Mike Cohn

Author:

� Agile Estimating and Planning

� User�Stories Applied

www.mountaingoatsoftware.com

On Sep 7, 2006, at 12:05 PM, Pato Jutard wrote:

I�m starting to implement Scrum in Three Melons, a game studio in Argentina after becoming CSM with the excellent course given by Tobias Mayer over here.
�
We are going great, but now I want to make progress visible and make some velocity-based estimations, anticipate deviations, have a clear picture of remaining work, know when the team performance is going down and need further motivation, etc
�
For this purposes I know some people is working with Burndown charts. Am I correct?
�
I have this resource:http://alistair.cockburn.us/index.php/Earned-value_and_burn_charts
�
Can someone guide me in this aspect?
�
What are you people using?
�
Can you provide any advice or any reference to material that treats this subject?
�
Thank you very much!
�
�
Patricio Jutard
Technology Orchestrator- Three Melons
Argentina: +54 11 4878-0130 int. 201
New York: +1�� 212 202-1458 ext. 201
pato@threemelons.com
�
<image001.jpg>
www.threemelons.com
�
�

#15960

From: "Gregor Dodson" <notacrime@...>
Date: Thu Sep 7, 2006 7:23 pm
Subject: Re: How to plan for "critical issues" that arise

dodsongr

Guy

Here are my thoughts:

>We've tried to deal with this by allocating "placeholder" time in a
"release stream" fixes story during the planning meeting. We use
placeholder time (undefined stories) since we never have a full list of
all the issues which will be raised by client services during the
sprint. All of these issues have been classified as "critical,
show-stopper issues", everything which isn't critical is placed in the
product backlog.

Any items you know about before the planning meeting need to be included in that meeting as backlog items to be prioritized. Anything that arises during the sprint that does not fall under any of the backlog items being worked on but HAS to be worked on right there and then should either be made in to a backlog item on the spot and worked on, or should just be worked on with the understanding that your velocity is going to suffer. If there is a standard amount of these types of issues then over time they will become an accepted part of the background noise in each sprint, and your velocity measure will take that into account.

If you find that most of your work is of this nature then you probably have to question whether these problems really need to be addresses during that sprint, or if they can wait until the next one. You should also try to figure out whether these are items that were really known about in time for the planning meeting, but someone is not willing to get them on the backlog in time for whatever reason (this will give you a headache and therefore is not your problem, but it is a problem you need to make visible to the PO.)

>Also, how have teams dealt with being under on sprint estimates? In the
current sprint, we underestimated some tasks and had many more sick days
taken than expected. This left us with more hours of effort remaining
than we can complete.

This is normal, and actually kind of the point. You are inspecting what you are actually able to achieve in a sprint, with all these factors included (sick days etc.) After 3 or 4 sprints you will have a much better idea of what you can actually achieve in a sprint, and you will be much better at estimating. Don't fret about not hitting your estimates in the first sprint. Why do you think the team won't take it's commitments seriously? Are they not a little bit embarrassed by not achieving their goals? They should be, just a little. Either they are crappy at estimating, or they are crappy developers. Let's hope it's the former and that they are smart enough to want to inspect and adapt.

Raise all of these issues at the retrospective and have the team suggest answers. They are the ones that are responsible for delivery, and if they can figure out how to estimate better and to deliver more then you should be listening to them. But stick to the scrum rules, it's only sprint 1.

Gregor

On 9/7/06, Guy Davis <davis@...> wrote:

Hi all,

I was hoping for some advice. Our development team runs 2 week
iterations. We do a mix of release stream fixes and development stream
work during an iteration. My role is as a developer on the team with
"Scrum Master" duties as well. With only a few key customers, we are
expected to respond very quickly when a problem in the release stream
arises.

We've tried to deal with this by allocating "placeholder" time in a
"release stream" fixes story during the planning meeting. We use
placeholder time (undefined stories) since we never have a full list of
all the issues which will be raised by client services during the
sprint. All of these issues have been classified as "critical,
show-stopper issues", everything which isn't critical is placed in the
product backlog.

Are these placeholder hours approach a good idea? Ideally, we wouldn't
allow any new requests (fixes) into the iteration once it begins, but I
haven't been able to sell this to our management who are very concerned
about responsiveness to key customers.

Also, how have teams dealt with being under on sprint estimates? In the
current sprint, we underestimated some tasks and had many more sick days
taken than expected. This left us with more hours of effort remaining
than we can complete.

What should be the proper response? On one hand, we could just say "no
big deal", but then the team will start to not take their commitments
seriously. On the other extreme, I could start asking for overtime to
meet the original planned commitment. Is overtime ever a good idea?
Would I be better to "lead by example", putting in overtime just by
myself and hope others might as well.

During the next planning meeting, we'll try to better adjust our
estimates, but I'm wondering about what, if anything, needs to be done
now with 4 days to go.

Thanks in advance for responses,
Guy

Reply | Messages in this Topic (21)

#15961

From: "Pato Jutard" <pato@...>
Date: Thu Sep 7, 2006 8:00 pm
Subject: RE: Burndown Charts and Earned Value

patojutard

http://www.solutionsiq.com/PDF/Sulaiman-AgileEVM.pdf

Thanks Hubert, thanks Mike.

Hubert, of course Tobias is a great trainer and he taught us Burndown charts, but I’m the bad pupil J

Mike, I looked for the Paper you mentioned, I think I find it so I’ll share it with the list:

Cheers,

Patricio

www.threemelons.com

De: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] En nombre de Mike Cohn
Enviado el: Jueves, 07 de Septiembre de 2006 04:18 p.m.
Para: scrumdevelopment@yahoogroups.com
CC: Brent Barton
Asunto: Re: [scrumdevelopment] Burndown Charts and Earned Value

Brent Barton and some colleagues from Solutions IQ presented a great paper on Earned Value at the Agile 2006 conference. I don't know if a copy of it is online anywhere. Maybe Brent can enlighten us.

Congratulations on taking your game studio to Scrum. Other game developers are having tremendous success with Scrum as well.

Regards,

Mike Cohn

Author:

Agile Estimating and Planning

User Stories Applied

www.mountaingoatsoftware.com

On Sep 7, 2006, at 12:05 PM, Pato Jutard wrote:

I’m starting to implement Scrum in Three Melons, a game studio in Argentina after becoming CSM with the excellent course given by Tobias Mayer over here.

For this purposes I know some people is working with Burndown charts. Am I correct?

I have this resource:http://alistair.cockburn.us/index.php/Earned-value_and_burn_charts

Can someone guide me in this aspect?

What are you people using?

Can you provide any advice or any reference to material that treats this subject?

Thank you very much!

Patricio Jutard
Technology Orchestrator- Three Melons
Argentina: +54 11 4878-0130 int. 201
New York: +1 212 202-1458 ext. 201
pato@threemelons.com

www.threemelons.com

#15962

From: Mike Cohn <mike@...>
Date: Thu Sep 7, 2006 8:12 pm
Subject: Re: Burndown Charts and Earned Value

mikewcohn

That's the paper. Thanks for sharing it.

Mike Cohn

Author:

� Agile Estimating and Planning

� User�Stories Applied

www.mountaingoatsoftware.com

On Sep 7, 2006, at 2:00 PM, Pato Jutard wrote:

Thanks Hubert, thanks Mike.
�
Hubert, of course Tobias is a great trainer and he taught us Burndown charts, but I�m the bad pupil J
�
Mike, I looked for the Paper you mentioned, I think I find it so I�ll share it with the list:
�
http://www.solutionsiq.com/PDF/Sulaiman-AgileEVM.pdf
�
Cheers,
�
Patricio
www.threemelons.com
�
De: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] En nombre de Mike Cohn
Enviado el: Jueves, 07 de Septiembre de 2006 04:18 p.m.
Para: scrumdevelopment@yahoogroups.com
CC: Brent Barton
Asunto: Re: [scrumdevelopment] Burndown Charts and Earned Value
�
Brent Barton and some colleagues from Solutions IQ presented a great paper on Earned Value at the Agile 2006 conference. I don't know if a copy of it is online anywhere. Maybe Brent can enlighten us.
Congratulations on taking your game studio to Scrum. Other game developers are having tremendous success with Scrum as well.
Regards,
Mike Cohn
Author:
� Agile Estimating and Planning
� User�Stories Applied
www.mountaingoatsoftware.com

�
On Sep 7, 2006, at 12:05 PM, Pato Jutard wrote:

�
I�m starting to implement Scrum in Three Melons, a game studio in Argentina after becoming CSM with the excellent course given by Tobias Mayer over here.
�
We are going great, but now I want to make progress visible and make some velocity-based estimations, anticipate deviations, have a clear picture of remaining work, know when the team performance is going down and need further motivation, etc
�
For this purposes I know some people is working with Burndown charts. Am I correct?
�
I have this resource:http://alistair.cockburn.us/index.php/Earned-value_and_burn_charts
�
Can someone guide me in this aspect?
�
What are you people using?
�
Can you provide any advice or any reference to material that treats this subject?
�
Thank you very much!
�
�
Patricio Jutard
Technology Orchestrator- Three Melons
Argentina: +54 11 4878-0130 int. 201
New York: +1�� 212 202-1458 ext. 201
pato@threemelons.com
www.threemelons.com
�