## Hyper productive...

Expand Messages
• I hear the term hyper productive a lot but I m confused about how the measurement is calculated. In a recent paper
Message 1 of 22 , May 21, 2009
I hear the term hyper productive a lot but I'm confused about how the measurement is calculated.

In a recent paper (http://jeffsutherland.com/scrum/SelfOrganizationShockTherapyBT2Apr2009.pdf) from Jeff Sutherland, Scott Downey & Bjorn Granvik they have some sample tables (p.40) that they reference hyper productive numbers. In the tables they calculate % increase by taking the story points delivered in Sprint 1 from a team and divide that by each delivery for the next n sprints. So in one of the examples Team E commits to 24 story points and delivers 5, making 5 the baseline number for that team. In Sprint 2 they commit to 26 story points and deliver 22, given them a 440% increase in productivity after 1 week. Are they now hyper productive?

Is sprint 1 a good baseline measurement of a new team to scrum, don't most teams over commit? What if they delivered 1 story point Sprint 1, then 22 Sprint 2? 2200% increase. wooohoooo!!!

Does anyone else have a measurement for hyper-productive?
• Most of us believe that teams become progressively more productive (i.e. deliver more running, tested features) during the early stages of a project. Some of
Message 2 of 22 , May 21, 2009
Most of us believe that teams become progressively more productive
(i.e. deliver more running, tested features) during the early stages
of a project. Some of us have seen this happen. Nonetheless, I am
quite dubious of any attempts to quantify this. Story points are not
necessarily comparable, although they seem to converge over time (e.g.
five story points in iteration one is likely not comparable to five
story points in iteration five. However, five story points in
iteration five likely is comparable to five story points in iteration
six.)

So, the increases in productivity we see through the course of an
Agile project are anecdotal. We have seen them. We know they exist,
but we lack any definitive way to measure them.

To truly quantify increases in productivity we would need a measure
that was always comparable. For instance, other methods might measure
something like KLOC/man-month and see how that changes over time,
attempting to correlate changes to different practices. We reject KLOC
as a measure of productivity, because it measures only work done and
not value produced.

In order to make story points comparable we would have to be comparing
stories that were very similar. However, if I have any idea what I am
doing then comparable stories should require progressively less effort
to complete (Through generalization, reuse, accumulation of knowledge,
etc.) If stories aren't similar it is very difficult to equate them. I
have a general sense of how much effort each takes, but that is
subjective (by design.)

In my personal opinion, this whole line of inquiry while quite well
intentioned is a waste of time. The things that matter are:

1) Are we delivering working software that is valuable - continuously,
every iteration?

2) Are we expending effort in a manner which is sustainable? Can we
continue to deliver at this pace indefinitely? Can we improve?

3) Are we wasting effort on things which do not contribute directly to
the delivery of value? How do we eliminate such waste?

On Thu, May 21, 2009 at 12:35 PM, D <dmahlitz@...> wrote:
>
>
> I hear the term hyper productive a lot but I'm confused about how the
> measurement is calculated.
>
> In a recent paper
> (http://jeffsutherland.com/scrum/SelfOrganizationShockTherapyBT2Apr2009.pdf)
> from Jeff Sutherland, Scott Downey & Bjorn Granvik they have some sample
> tables (p.40) that they reference hyper productive numbers. In the tables
> they calculate % increase by taking the story points delivered in Sprint 1
> from a team and divide that by each delivery for the next n sprints. So in
> one of the examples Team E commits to 24 story points and delivers 5, making
> 5 the baseline number for that team. In Sprint 2 they commit to 26 story
> points and deliver 22, given them a 440% increase in productivity after 1
> week. Are they now hyper productive?
>
> Is sprint 1 a good baseline measurement of a new team to scrum, don't most
> teams over commit? What if they delivered 1 story point Sprint 1, then 22
> Sprint 2? 2200% increase. wooohoooo!!!
>
> Does anyone else have a measurement for hyper-productive?
>
>
• I agree with Adam, this hyper-productivity measuring is mostly a waste of time -- and a way of selling snake oil. Estimation of stories is not a constant
Message 3 of 22 , May 21, 2009
I agree with Adam, this "hyper-productivity" measuring is mostly a waste of time -- and a way of selling snake oil.  Estimation of stories is not a constant thing; teams change the way they do this over time as much as they improve their ability to deliver.  And as Adam points out comparably complex stories require less and less effort as we get better.

I think such "quantified" claims do a disservice to Scrum, and as the original poster points out, if you set your baseline low enough, everything can appear as hyper-productive.  What if a team completed nothing at all in sprint one?  Then getting one story point done in sprint two would represent an infinity% increase.  It is all nonsense.

Yes, we do see teams improve over time.  Let's just use that shared knowledge.  Scrum does better with real-life subjective metrics than fake objective ones.  I reckon.

Tobias

• Hello, Tobias. On Thursday, May 21, 2009, at 6:46:40 PM, you ... I m not sure why I think this, not having visited them, but my money says Jeff s teams really
Message 4 of 22 , May 21, 2009
Hello, Tobias. On Thursday, May 21, 2009, at 6:46:40 PM, you
wrote:

> I agree with Adam, this "hyper-productivity" measuring is
> mostly a waste of time -- and a way of selling snake oil.
> Estimation of stories is not a constant thing; teams change the
> way they do this over time as much as they improve their ability
> to deliver.  And as Adam points out comparably complex stories
> require less and less effort as we get better.

I'm not sure why I think this, not having visited them, but my money
says Jeff's teams really do kick butt. And he does have some
external productivity measures that back that up ...

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
• Dear All, We have recently defined initial draft of scrum processes.I am trying to integrate Specific practices from IPM-Integrated project management (at
Message 5 of 22 , May 21, 2009
Dear All,
We have recently defined initial draft of scrum processes.I am trying to integrate Specific practices from IPM-Integrated project management (at CMMIL3) with SCRUM Planning.
Problem 1 : The following was the trigger for this thought:
There are teams following scrum cycle at multiple locations (more than 2 ) with only 1 scrum master and product owner.
I found it little strange , as to how is possible for scrum master to manage sprint with teams located at multiple locations
and also stand-up meetings(daily scrum) are really difficult in this scenario.This makes me think that , may be
it will be good idea if we include some practices from IPM at CMMIL3 to ensure integrated teaming.
I am looking at two aspects:
Involving scrum teams (from multiple locations with only one scrum master or may be 2) effectively in sprint planning
Involving scrum teams (from multiple locations with only one scrum master or may be 2) effectively in sprint execution and closure

Just to share my thought on :
Daily scrums:
Here scrum master sets up daily scrum meeting with the Scrum Team for 10-15 mins.
Typically focus is on:
• What was done yesterday?
• What is planned for today/next working day?
• What are the impediments faced?
• What the status of previously identified impediments?

Scrum of scrums:
Here scrum master (scrum masters , in case of multiple scrum masters) sets up weekly scrum meeting with PO and update the status
of sprint in terms of:
• What was done last week?
• What is the plan for next week?
• What are the impediments faced
Problem 2 : When does really the resource allocation takes place in scrum.To my knowledge, scrum is project management methodology.
I have no where found planning for resources (human and non-human).Is it during the release planning or sprint planning.To my knowledge during the release planning the scrum master may get involved the very first time,but I am not sure, if the scrum team is really decided here at this stage.Request someone to guide me on this.

I need expert advice on whether my thought (in problem 1) is feasible and if yes, has anyone done this earlier and what chalenges are there in doing it.
It will be really great, if anyone amongst you can throw some light on it.I have already referred to couple of websites on agile-scrum, but they do not address my 2 problems.

Regards,
Vikas

From: Ron Jeffries <ronjeffries@...>
To: scrumdevelopment@yahoogroups.com
Sent: Friday, 22 May, 2009 6:52:19 AM
Subject: Re: [scrumdevelopment] Hyper productive...

Hello, Tobias. On Thursday, May 21, 2009, at 6:46:40 PM, you
wrote:

> I agree with Adam, this "hyper-productivity " measuring is
> mostly a waste of time -- and a way of selling snake oil.
> Estimation of stories is not a constant thing; teams change the
> way they do this over time as much as they improve their ability
> to deliver.  And as Adam points out comparably complex stories
> require less and less effort as we get better.

I'm not sure why I think this, not having visited them, but my money
says Jeff's teams really do kick butt. And he does have some
external productivity measures that back that up ...

Ron Jeffries
www.XProgramming. com
www.xprogramming. com/blog
The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer

Explore and discover exciting holidays and getaways with Yahoo! India Travel Click here!
• Hi Vikas, Your analysis of the Daily Scrum is basically correct, except you don t need the fourth question. If something is still an impediment, it should be
Message 6 of 22 , May 21, 2009
Hi Vikas,

Your analysis of the Daily Scrum is basically correct, except you don't need the fourth question. If something is still an impediment, it should be mentioned as an answer to the third question.

Regarding the Scrum of Scrums - I have seen a lot of variation in this. The book gives you a suggestion for where to start, but teams should self organize and figure out what works for them.

Like the Daily Scrum, the purpose of the Scrum of Scrums is to enable self organization. The teams keep each other up to date and warn each other when they may cause each other problems. ("Hey, we want to upgrade the jquery library next week..."). The teams coordinate with *each other*.

It is not a status update for the benefit of the Product Owner. The status update occurs and the Sprint Review.

My experience with the SoS between the Scrum Masters has not been very good. The S-M is responsible for Process, not Substance (even worse is if the Scrum Master also has some leadership role, like team leader and/or chief architect). The Team is responsible for the substance.  In a recent project with two teams on two sites, the teams decided to designate one person responsible for each major topic, e.g. build master, architect, technical infrastructure, testing, etc. These people then decided how often they needed to talk to each other, which ranged from once / day, to once per week, depending on how intense the actual problems were. Some of them followed the SoS structure and others did not. This worked much better.

You question actually touches on one of the philosophical differences (at least as I understand it) between Scrum and CMMI - Scrum says, "ensure the communication and let people self organize and continuously improve". CMMI gets translated to "write it down from the top". As soon as you write it down, the self organization and continuous improvement stop.

Having the Scrum Master remote (either to the team or two management) is a problem - it makes it difficult to accomplish the primary task, recognize and resolve impediments. Co-location is almost always better, if you can make it happen.

Personel planning in Scrum should occur at the team level. As a manager, you put a team together, provide them with a coach (the Scrum Master) to help them get the optimal performance out of the team, but let the coach and team worry about how the team actually plays the game. Yes, there will occasionally be changes in the team, but that should happen infrequently. At the program management level, consider the team to be your atomic entity which you manage and allocate to projects.

Hope this helps,

Cheers,

Peter

Vikas Atri schrieb:
Dear All,
We have recently defined initial draft of scrum processes.I am trying to integrate Specific practices from IPM-Integrated project management (at CMMIL3) with SCRUM Planning.
Problem 1 : The following was the trigger for this thought:
There are teams following scrum cycle at multiple locations (more than 2 ) with only 1 scrum master and product owner.
I found it little strange , as to how is possible for scrum master to manage sprint with teams located at multiple locations
and also stand-up meetings(daily scrum) are really difficult in this scenario.This makes me think that , may be
it will be good idea if we include some practices from IPM at CMMIL3 to ensure integrated teaming.
I am looking at two aspects:
Involving scrum teams (from multiple locations with only one scrum master or may be 2) effectively in sprint planning
Involving scrum teams (from multiple locations with only one scrum master or may be 2) effectively in sprint execution and closure

Just to share my thought on :
Daily scrums:
Here scrum master sets up daily scrum meeting with the Scrum Team for 10-15 mins.
Typically focus is on:
• What was done yesterday?
• What is planned for today/next working day?
• What are the impediments faced?
• What the status of previously identified impediments?

Scrum of scrums:
Here scrum master (scrum masters , in case of multiple scrum masters) sets up weekly scrum meeting with PO and update the status
of sprint in terms of:
• What was done last week?
• What is the plan for next week?
• What are the impediments faced
Problem 2 : When does really the resource allocation takes place in scrum.To my knowledge, scrum is project management methodology.
I have no where found planning for resources (human and non-human).Is it during the release planning or sprint planning.To my knowledge during the release planning the scrum master may get involved the very first time,but I am not sure, if the scrum team is really decided here at this stage.Request someone to guide me on this.

I need expert advice on whether my thought (in problem 1) is feasible and if yes, has anyone done this earlier and what chalenges are there in doing it.
It will be really great, if anyone amongst you can throw some light on it.I have already referred to couple of websites on agile-scrum, but they do not address my 2 problems.

Regards,
Vikas

From: Ron Jeffries <ronjeffries@ acm.org>
To: scrumdevelopment@ yahoogroups. com
Sent: Friday, 22 May, 2009 6:52:19 AM
Subject: Re: [scrumdevelopment] Hyper productive.. .

Hello, Tobias. On Thursday, May 21, 2009, at 6:46:40 PM, you
wrote:

> I agree with Adam, this "hyper-productivity " measuring is
> mostly a waste of time -- and a way of selling snake oil.
> Estimation of stories is not a constant thing; teams change the
> way they do this over time as much as they improve their ability
> to deliver.  And as Adam points out comparably complex stories
> require less and less effort as we get better.

I'm not sure why I think this, not having visited them, but my money
says Jeff's teams really do kick butt. And he does have some
external productivity measures that back that up ...

Ron Jeffries
www.XProgramming. com
www.xprogramming. com/blog
The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer

Explore and discover exciting holidays and getaways with Yahoo! India Travel Click here!

```--
Peter Stevens, CSM, CSP
Ken Schwaber CSM Training in Zürich: www.tinyurl.com/Ken-in-ZH
www.scrum-breakfast.com
tel: +41 44 586 6450
```
• Hi Vikas, One of the major things you need to do for the distributed teams is that how efficiently you can handle the communication between the teams. I did a
Message 7 of 22 , May 21, 2009
Hi Vikas,

One of the major things you need to do for the distributed teams is that how efficiently you can handle the communication between the teams. I did a write some time back for the distributed teams to handle typical scrum meetings in case of distributed teams with some overlap time difference and with no overlapping time difference.

http://jaibeermalik.wordpress.com/2009/03/30/sprint-in-action-typical-vs-distributed-team/

This can give you some idea:
-how you can break up the stanup into local and distributed stanups.
-how you can break the planning meetings into first and second part of planning meetings etc.
-how can you share demo updated with other teams
-what you can do in terms of communication and knowledge sharing.

And to have a local Scrum master can definitely help the team in terms of communication and resolving the impediments more effectively.

-Jai

--- In scrumdevelopment@yahoogroups.com, Vikas Atri <vikasait25@...> wrote:
>
> DearÂ All,
> We have recently defined initial draft of scrum processes.I am trying to integrate Specific practices from IPM-Integrated project managementÂ (at CMMIL3) with SCRUM Planning.
> Problem 1 : The following was the trigger for this thought:
> There are teams following scrum cycle at multiple locations (more than 2 ) with only 1 scrum master and product owner.
> I found it little strange , as to how is possible for scrum master to manage sprint with teams located at multiple locations
> and also stand-up meetings(daily scrum) are really difficult in this scenario.This makes me think that , may be
> it will be good idea if we include some practices from IPM at CMMIL3 to ensure integrated teaming.
> I am looking at two aspects:
> Involving scrum teams (from multiple locations with only one scrum master or may be 2) effectively in sprint planning
> Involving scrum teams (from multiple locations with only one scrum master or may be 2) effectively in sprint execution and closure
>
> Just to share my thought on :
> Daily scrums:
> Here scrum master sets up daily scrum meeting with the Scrum Team for 10-15 mins.
> Typically focus is on:
> â¢Â What was done yesterday?
> â¢Â What is planned for today/next working day?
> â¢Â What are the impediments faced?
> â¢Â What the status of previously identified impediments?
>
> Scrum of scrums:
> Here scrum master (scrum masters , in case of multiple scrum masters) sets up weekly scrum meeting with PO and update the status
> of sprint in terms of:
> â¢Â What was done last week?
> â¢Â What is the plan for next week?
> â¢Â What are the impediments faced
>
> Problem 2 :Â When does really the resource allocation takes place in scrum.To my knowledge, scrum is project management methodology.
> I have no where found planning for resources (human and non-human).Is it during the release planning or sprint planning.To my knowledge during the release planning the scrum master may get involved the very first time,but I am not sure, if the scrum team is really decided here at this stage.Request someone to guide me on this.
>
> I need expert advice on whether my thought (in problem 1)Â is feasible and if yes, has anyone done this earlier and what chalenges are there in doing it.
> It will be really great, if anyone amongst you can throw some light on it.I have already referred to couple of websites on agile-scrum, but they do not address my 2 problems.
> www.implementingscr um.com
> www.mountaingoatsof tware.com
> www.scrumalliance. org
>
> Regards,
> Vikas
>
>
>
>
>
> ________________________________
> From: Ron Jeffries <ronjeffries@...>
> To: scrumdevelopment@yahoogroups.com
> Sent: Friday, 22 May, 2009 6:52:19 AM
> Subject: Re: [scrumdevelopment] Hyper productive...
>
>
>
>
>
> Hello, Tobias. On Thursday, May 21, 2009, at 6:46:40 PM, you
> wrote:
>
> > I agree with Adam, this "hyper-productivity " measuring is
> > mostly a waste of time -- and a way of selling snake oil.Â
> > Estimation of stories is not a constant thing; teams change the
> > way they do this over time as much as they improve their ability
> > to deliver.Â  And as Adam points out comparably complex stories
> > require less and less effort as we get better.Â
>
> I'm not sure why I think this, not having visited them, but my money
> says Jeff's teams really do kick butt. And he does have some
> external productivity measures that back that up ...
>
> Ron Jeffries
> www.XProgramming. com
> www.xprogramming. com/blog
> The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
>
>
>
>
>
> Explore and discover exciting holidays and getaways with Yahoo! India Travel http://in.travel.yahoo.com/
>
• Hi, I will extend Ron s thought. I agree there can be a lot of gush in talk about hyperproductivity. This does not mean all talk about hyperproductivity is
Message 8 of 22 , May 21, 2009
Hi,

I will extend Ron's thought.

I agree there can be a lot of gush in talk about hyperproductivity. This does not mean all talk about hyperproductivity is gush.

Specifically, I think it is the more adult teams that challenge themselves to become hyperproductive (and at the same time use known velocity to push back at those magical-thinking managers who "demand" double the productivity in one Sprint...this 2nd use seems contradictory to the 1st, but still right and important).

While I agree that delivery of BV is more important, teams must have a known velocity (at least for the 2 reasons mentioned above).

And, having the known velocity, they must say "which impediments do we remove to double velocity?" Usually the comment comes back: "Well, if we just make a few minor changes, we can't double productivity (velocity)!" And then someone must say: "OK, let's make major changes. What do we have to change?" (Ron might well say, "right, and that's why we call it extreme programming".)

A velocity measure (and a velocity challenge) allows you to learn which impediments removed will lead to greater velocity. In a fact-based way, rather than hand-waving and stamping of feet.

As to others' comments about BV. Yes, important. From my experience, usually I find that teams need some minimal help first with BV. Then need to get a known velocity. Then need to focus on removing impediments so that improvement is demonstrable. And then can come back to improving what I will call BV Engineering.

How: Well, if I were doing Shock Therapy, I would take the average Velocity of the 1st three sprints. I would also gut check with key people that "if you had to guess, does this feel like as productive on avg as we used to be??" Usually they have no clue, but at least the avg seems like as reasonable a baseline as we can get (usually somewhat high). Then the next challenge, to the team as professionals, is to figure out what to change to double the velocity.
Often one must say forcefully "No, we don't want muri!!" (overstressing the system).

One might say the whole thing is like a koan. It is only by transcending seeming contradictions that the team bursts through to a new level of productivity.

To a lot of the complaints some of you have about this: you are looking at explicit things and ignoring the Tacit Knowledge. The Team and the Coach must have established the right relationship. Done badly, yes this could be bad. Done by the right coach (and, yes, the right Team), this is completely in alignment with Agile principles. And successful...for the customers, for the workers, for the stakeholders.

To another complaint: Yes, this is all problematic. (Ex: fudging the metrics.) Yes, and all of life is problematic. You know enough already to make it work. Tell the truth, work hard (in a reasonable timebox), be creative.

Let me be a tad blunter: Things are so screwed up in SW dev, that doubling a team's productivity is not that hard. Still, this approach is not a silver bullet, and, for many reasons, it might fail. Is that a good reason not to try it (assuming you are competent to do so)?

Hyperproductivity is defined as at least 4x normal productivity (the best data say normal is 2 Function Points per Developer Month). So, 2x is not there yet. But if you can get to 2x, you can get to 4x.

Regards, Joe

--- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
>
> Hello, Tobias. On Thursday, May 21, 2009, at 6:46:40 PM, you
> wrote:
>
> > I agree with Adam, this "hyper-productivity" measuring is
> > mostly a waste of time -- and a way of selling snake oil.
> > Estimation of stories is not a constant thing; teams change the
> > way they do this over time as much as they improve their ability
> > to deliver.  And as Adam points out comparably complex stories
> > require less and less effort as we get better.
>
> I'm not sure why I think this, not having visited them, but my money
> says Jeff's teams really do kick butt. And he does have some
> external productivity measures that back that up ...
>
> Ron Jeffries
> www.XProgramming.com
> www.xprogramming.com/blog
> The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
>
• ... I suspect that is true. And, I didn t read the article the OP referred to. Possibly their analysis was quite informative. I just don t think there is much
Message 9 of 22 , May 22, 2009
On Thu, May 21, 2009 at 6:22 PM, Ron Jeffries <ronjeffries@...> wrote:
>
>
> Hello, Tobias. On Thursday, May 21, 2009, at 6:46:40 PM, you
> wrote:
>
>> I agree with Adam, this "hyper-productivity" measuring is
>> mostly a waste of time -- and a way of selling snake oil.
>> Estimation of stories is not a constant thing; teams change the
>> way they do this over time as much as they improve their ability
>> to deliver.  And as Adam points out comparably complex stories
>> require less and less effort as we get better.
>
> I'm not sure why I think this, not having visited them, but my money
> says Jeff's teams really do kick butt. And he does have some
> external productivity measures that back that up ...
>

I suspect that is true. And, I didn't read the article the OP referred
to. Possibly their analysis was quite informative.

I just don't think there is much point in trying to quantify
productivity. Even if I could demonstrate and improvement in velocity,
what does that mean? Is it likely that if I attempt to double my
velocity I will succeed? Does than necessarily mean I will double (or
even increase, or even not *decrease*) the value I produce?

The following measure is good enough for me:

Value produced in iteration one: some.
Value produced in iteration two: some more.

:-)
• ... One of the big lessons to be found in the ball-tossing game is that we can improve our work ... get some more ... or /change/ our work ... and get a lot.
Message 10 of 22 , May 22, 2009
Hello, Adam. On Friday, May 22, 2009, at 3:17:49 AM, you wrote:

> The following measure is good enough for me:

> Value produced in iteration one: some.
> Value produced in iteration two: some more.

One of the big lessons to be found in the ball-tossing game is that
we can improve our work ... get "some more" ... or /change/ our work
... and get a lot.

Ron Jeffries
www.XProgramming.com
www.xprogramming.com/blog
A man hears what he wants to hear, and disregards the rest. -- Paul Simon
• Jai/Peter,   Thanks a lot for inputs.Inputs were really valuable and Infact it has helped me to some degree. Let me elaborate you my thoughts, I was trying
Message 11 of 22 , May 22, 2009

Jai/Peter,

Thanks a lot for inputs.Inputs were really valuable and Infact it has helped me to some degree.

Let me elaborate you my thoughts, I was trying to use CMMI reference at CMMIL3,IPM which has added IPPD (integrated product and process development) steps that enables achieving  a timely collaboration of relevant stakeholders throughout the product lifecycle to better satisfy customer needs

Infact, I found it interesting and I was trying to adopt them to our scrum processes mainly sprint planning, execution, and closure processes:

Below are the practices mentioned and what is expected after implementing the practice.

Practice 1: Establish the Project’s Shared Vision

Expected: Documented shared vision, Communications strategy, Published principles, shared vision statement, mission statement, and objectives (e.g., posters, wallet cards, and presentations)

Practice 2:  Establish the Integrated Team Structure

Expected:

a. Assessments of the product and product architectures, including risk and complexity

b. Integrated team structure

Practice 3. Allocate Requirements to Integrated Teams

Expected:

a. Responsibilities allocated to each integrated team

b. Work product requirements, technical interfaces, and business (e.g., cost accounting and project management) interfaces each integrated team will be responsible for satisfying

c. List of integrated team sponsors

Practice 4: Establish Integrated Teams

Expected:

b. List of team members assigned to each integrated team

c. Integrated team charters

d. Measures for evaluating the performance of integrated teams

5. Ensure Collaboration among Interfacing Teams

Expected: a. Work product ownership agreements

b. Team work plans

c. Commitment lists

According to me, lot of things will happen during sprint planning and they will be tracked during sprint execution to closure.

Looking for opinions from you guys, on how to accomplish any or all of above mentioned practices in sprint planning, execution and closure.

Regards,

Vikas

From: jaibeer_malik <jaibeer_malik@...>
To: scrumdevelopment@yahoogroups.com
Sent: Friday, 22 May, 2009 12:03:04 PM
Subject: [scrumdevelopment] Re: IPM @CMMIL3

Hi Vikas,

One of the major things you need to do for the distributed teams is that how efficiently you can handle the communication between the teams. I did a write some time back for the distributed teams to handle typical scrum meetings in case of distributed teams with some overlap time difference and with no overlapping time difference.

http://jaibeermalik .wordpress. com/2009/ 03/30/sprint- in-action- typical-vs- distributed- team/

This can give you some idea:
-how you can break up the stanup into local and distributed stanups.
-how you can break the planning meetings into first and second part of planning meetings etc.
-how can you share demo updated with other teams
-what you can do in terms of communication and knowledge sharing.

And to have a local Scrum master can definitely help the team in terms of communication and resolving the impediments more effectively.

-Jai

--- In scrumdevelopment@ yahoogroups. com, Vikas Atri <vikasait25@ ...> wrote:
>
> DearÂ All,
> We have recently defined initial draft of scrum processes.I am trying to integrate Specific practices from IPM-Integrated project managementÂ (at CMMIL3) with SCRUM Planning.
> Problem 1 : The following was the trigger for this thought:
> There are teams following scrum cycle at multiple locations (more than 2 ) with only 1 scrum master and product owner.
> I found it little strange , as to how is possible for scrum master to manage sprint with teams located at multiple locations
> and also stand-up meetings(daily scrum) are really difficult in this scenario.This makes me think that , may be
> it will be good idea if we include some practices from IPM at CMMIL3 to ensure integrated teaming..
> I am looking at two aspects:
> Involving scrum teams (from multiple locations with only one scrum master or may be 2) effectively in sprint planning
> Involving scrum teams (from multiple locations with only one scrum master or may be 2) effectively in sprint execution and closure
>
> Just to share my thought on :
> Daily scrums:
> Here scrum master sets up daily scrum meeting with the Scrum Team for 10-15 mins.
> Typically focus is on:
> â€¢Â What was done yesterday?
> â€¢Â What is planned for today/next working day?
> â€¢Â What are the impediments faced?
> â€¢Â What the status of previously identified impediments?
>
> Scrum of scrums:
> Here scrum master (scrum masters , in case of multiple scrum masters) sets up weekly scrum meeting with PO and update the status
> of sprint in terms of:
> â€¢Â What was done last week?
> â€¢Â What is the plan for next week?
> â€¢Â What are the impediments faced
>
> Problem 2 :Â When does really the resource allocation takes place in scrum.To my knowledge, scrum is project management methodology.
> I have no where found planning for resources (human and non-human).Is it during the release planning or sprint planning.To my knowledge during the release planning the scrum master may get involved the very first time,but I am not sure, if the scrum team is really decided here at this stage.Request someone to guide me on this.
>
> I need expert advice on whether my thought (in problem 1)Â is feasible and if yes, has anyone done this earlier and what chalenges are there in doing it.
> It will be really great, if anyone amongst you can throw some light on it.I have already referred to couple of websites on agile-scrum, but they do not address my 2 problems.
> www.implementingscr um.com
> www.mountaingoatsof tware.com
> www.scrumalliance. org
>
> Regards,
> Vikas
>
>
>
>
>
> ____________ _________ _________ __
> From: Ron Jeffries <ronjeffries@ ....>
> To: scrumdevelopment@ yahoogroups. com
> Sent: Friday, 22 May, 2009 6:52:19 AM
> Subject: Re: [scrumdevelopment] Hyper productive... .
>
>
>
>
>
> Hello, Tobias. On Thursday, May 21, 2009, at 6:46:40 PM, you
> wrote:
>
> > I agree with Adam, this "hyper-productivity " measuring is
> > mostly a waste of time -- and a way of selling snake oil.Â
> > Estimation of stories is not a constant thing; teams change the
> > way they do this over time as much as they improve their ability
> > to deliver.Â  And as Adam points out comparably complex stories
> > require less and less effort as we get better.Â
>
> I'm not sure why I think this, not having visited them, but my money
> says Jeff's teams really do kick butt. And he does have some
> external productivity measures that back that up ...
>
> Ron Jeffries
> www.XProgramming. com
> www.xprogramming. com/blog
> The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
>
>
>
>
>
> Explore and discover exciting holidays and getaways with Yahoo! India Travel http://in.travel. yahoo.com/
>

• Hi, Some comments, then a story. Comments first. ... Expected: PO has defined and shared the project vision and mission with development team(s) and
Message 12 of 22 , May 23, 2009
Hi,

> Practice 1: Establish the Projectâs Shared Vision
> Expected: Documented shared vision, Communications strategy, Published principles, shared vision statement, mission statement, and objectives (e.g., posters, wallet cards, and presentations)

Expected: PO has defined and shared the project vision and mission with development team(s) and stakeholders, the PO and the development team have agreed the principles and objectives of the project

> Practice 2: Â Establish the Integrated Team Structure
> Expected:
> a. Assessments of the product and product architectures, including risk and complexity
> b. Integrated team structure

I don't see what a. has to do with "Integrated Team Structure".

I assume "integrated team" to mean a cross-functional team. Right?

b. probably assumes that there is a fixed responsibility structure between the teams. If not, merely list the teams and their members (see 4 also).

> Practice 3. Allocate Requirements to Integrated Teams
> Expected:
>   a. Responsibilities allocated to each integrated team
>   b. Work product requirements, technical interfaces, and business (e.g., cost accounting and project management) interfaces each integrated team will be responsible for satisfying
>   c. List of integrated team sponsors

Expected:
a. At each sprint planning, each integrated team accepts user stories to be developed in the iteration
b. There are existing agreed practices for communicating and agreeing dependencies between the teams

What are c.?

> Practice 4: Establish Integrated Teams
> Expected:
> a. List of team leaders
>   b. List of team members assigned to each integrated team
>   c. Integrated team charters
>   d. Measures for evaluating the performance of integrated teams

a. is not there in Scrum environment.
b. is okay.
c. What are these??
d. Watch out for these, they tend screw up things...

> 5. Ensure Collaboration among Interfacing Teams
> Expected:
> a. Work product ownership agreements
>   b. Team work plans
>   c. Commitment lists

a. sounds a bit silly, given that all teams contribute to the same product. These are ofc made during sprint planning for each sprint.

b. Sprint backlogs.

c. Happen daily as team members pick up tasks. If necessary, show the names from the sprint backlog at the end of a sprint.

Looks to me, you either have to make up a lot of things, or you have some explaining to do.

> According to me, lot of things will happen during sprint planning and they will be tracked during sprint execution to closure.
> Looking for opinions from you guys, on how to accomplish any or all of above mentioned practices in sprint planning, execution and closure.

I'll share a recent story from a colleague. We had an external audit recently and one of the assessed projects was a Scrum project where this colleague was the Scrum Master. The auditor, a lady, had a lot of experience on assessments, projects and the traditional way, so she had trouble getting into grips with the project. The discussions were typically something like this:

Auditor: Do you have a quality plan?
SM: Well... no, not really, as a document, but we have a Definition of Done. <showed and explained it>
A: How do you ensure the quality of the final product to avoid surprises at the end?
SM: Well, we don't have a final product release per se, since we deliver a working version from every iteration. We want every iteration to meet the quality criteria, so we don't really see how we could have any surprises since we know any problems immediately.
A: Do you have any quality metrics you track?
SM: No, not really...
A: Well, what could you measure to follow the quality of the project?
SM: <thinks hard> ... how about bugs in sprint releases?
A: <excited> Yes, for example! Do you have a database or similar where you store the bugs?
SM: No, we don't... How many bugs have we had reported by the customer in the last 5 months?
Developer: Two?
...

And so on :).

The auditor said that she didn't really understand how the project worked, but could clearly see that the project had everything in control. She was clearly intrigued by the approach and its results.

Bottom line, I wouldn't try to conform to any waterfall-based process framework, but if you do have to, do stand tall and show what you have. It is very likely to be something much better than what the framework expects. This ofc assuming that you do have the project under control the Scrum way. :)

Yours Sincerely,

Petri

---
Petri Heiramo
Process Development Manager, Agile Coach (CST)
Digia Plc., Finland
• Frankly, I am at a total loss as to how to measure either personal or team productivity in any statistical or mathematical manner. First, you must define
Message 13 of 22 , May 26, 2009
Frankly, I am at a total loss as to how to 'measure' either personal or team productivity in any statistical or mathematical manner.

First, you must define your concept of 'productivity'. Is it 'lines of code per hour'? Is it 'story points achieved?'. Is it hours to do a particular job? What?

I believe that productivity is almost entirely a qualitative measure, in software development. In manufacturing you can measure producivity in terms of machine utilisation, units produced per hour, etc. etc. Of course, these may be dud values, useless for any real purpose, because you may be utilising your machines at close to 100% (which is a good thing) to produce more items per hour than last time (which is also a good thing) so that you have a large on-hand stock (which is not a good thing) because there is noone to buy those highly-productively produced items (which really is a very bad thing).

If we look at the old management saying that 'if you can't measure it you can't manage it', there may be a grain of truth in that. BUT agile practices indicate that you do not have 'managers', you have leaders, you have mentors and helpful people like Scrum Masters. Is there a saying amongst agile practitioners 'you can't provide leadership if you can't measure it'?

Why do we have this incessant discussion about something as, frankly, inappropriate and irrelevant in agile systems development as 'productivity measurement'? Isn't delivering useful, working software as fast as the team can manage to do so, and doing that apparently better than last 'time', a sufficient measure?

Regards,
Roy Morien

To: scrumdevelopment@yahoogroups.com
Date: Thu, 21 May 2009 15:27:36 -0700
Subject: Re: [scrumdevelopment] Hyper productive...

Most of us believe that teams become progressively more productive
(i.e. deliver more running, tested features) during the early stages
of a project. Some of us have seen this happen. Nonetheless, I am
quite dubious of any attempts to quantify this. Story points are not
necessarily comparable, although they seem to converge over time (e.g.
five story points in iteration one is likely not comparable to five
story points in iteration five. However, five story points in
iteration five likely is comparable to five story points in iteration
six.)

So, the increases in productivity we see through the course of an
Agile project are anecdotal. We have seen them. We know they exist,
but we lack any definitive way to measure them.

To truly quantify increases in productivity we would need a measure
that was always comparable. For instance, other methods might measure
something like KLOC/man-month and see how that changes over time,
attempting to correlate changes to different practices. We reject KLOC
as a measure of productivity, because it measures only work done and
not value produced.

In order to make story points comparable we would have to be comparing
stories that were very similar. However, if I have any idea what I am
doing then comparable stories should require progressively less effort
to complete (Through generalization, reuse, accumulation of knowledge,
etc.) If stories aren't similar it is very difficult to equate them. I
have a general sense of how much effort each takes, but that is
subjective (by design.)

In my personal opinion, this whole line of inquiry while quite well
intentioned is a waste of time. The things that matter are:

1) Are we delivering working software that is valuable - continuously,
every iteration?

2) Are we expending effort in a manner which is sustainable? Can we
continue to deliver at this pace indefinitely? Can we improve?

3) Are we wasting effort on things which do not contribute directly to
the delivery of value? How do we eliminate such waste?

On Thu, May 21, 2009 at 12:35 PM, D <dmahlitz@gmail. com> wrote:
>
>
> I hear the term hyper productive a lot but I'm confused about how the
> measurement is calculated.
>
> In a recent paper
> (http://jeffsutherla nd.com/scrum/ SelfOrganization ShockTherapyBT2A pr2009.pdf)
> from Jeff Sutherland, Scott Downey & Bjorn Granvik they have some sample
> tables (p.40) that they reference hyper productive numbers. In the tables
> they calculate % increase by taking the story points delivered in Sprint 1
> from a team and divide that by each delivery for the next n sprints. So in
> one of the examples Team E commits to 24 story points and delivers 5, making
> 5 the baseline number for that team. In Sprint 2 they commit to 26 story
> points and deliver 22, given them a 440% increase in productivity after 1
> week. Are they now hyper productive?
>
> Is sprint 1 a good baseline measurement of a new team to scrum, don't most
> teams over commit? What if they delivered 1 story point Sprint 1, then 22
> Sprint 2? 2200% increase. wooohoooo!!!
>
> Does anyone else have a measurement for hyper-productive?
>
>

• Hi Petri, Thanks for the reply. Infact, it was a real detailed reply, in context to CMMI practices. I come from CMMI background and your inputs have really
Message 14 of 22 , May 27, 2009
Hi Petri,

Infact, it was a real detailed reply, in context to CMMI practices.
I come from CMMI background and your inputs have really helped out.
I really want to understand the measures for evaluating the performance of integrated teams.
What kind of measures is one supposed to look for?
for "Assessments of the product and product architectures, including risk and complexity"
My understanding for this point is that it happens in Pre-Gaming phase wherein the
product backlog evolves and the product owner continuously  assess the product and product
architectures, including risk and complexity.
Please let me know, if I ma thinking in the right direction.
And I was looking forward to really demonstarte it using some form of template as an evidence.
Regards,
Vikas

From: Petri Heiramo <petri.heiramo@...>
To: scrumdevelopment@yahoogroups.com
Sent: Sunday, 24 May, 2009 12:46:34 AM
Subject: [scrumdevelopment] Re: IPM @CMMIL3

Hi,

> Practice 1: Establish the Projectâ€™s Shared Vision
> Expected: Documented shared vision, Communications strategy, Published principles, shared vision statement, mission statement, and objectives (e.g., posters, wallet cards, and presentations)

Expected: PO has defined and shared the project vision and mission with development team(s) and stakeholders, the PO and the development team have agreed the principles and objectives of the project

> Practice 2: Â Establish the Integrated Team Structure
> Expected:
> a. Assessments of the product and product architectures, including risk and complexity
> b. Integrated team structure

I don't see what a. has to do with "Integrated Team Structure".

I assume "integrated team" to mean a cross-functional team. Right?

b. probably assumes that there is a fixed responsibility structure between the teams. If not, merely list the teams and their members (see 4 also).

> Practice 3. Allocate Requirements to Integrated Teams
> Expected:
>   a. Responsibilities allocated to each integrated team
>   b. Work product requirements, technical interfaces, and business (e.g., cost accounting and project management) interfaces each integrated team will be responsible for satisfying
>   c. List of integrated team sponsors

Expected:
a. At each sprint planning, each integrated team accepts user stories to be developed in the iteration
b. There are existing agreed practices for communicating and agreeing dependencies between the teams

What are c.?

> Practice 4: Establish Integrated Teams
> Expected:
> a. List of team leaders
>   b. List of team members assigned to each integrated team
>   c. Integrated team
charters
>   d. Measures for evaluating the performance of integrated teams

a. is not there in Scrum environment.
b. is okay.
c. What are these??
d. Watch out for these, they tend screw up things....

> 5. Ensure Collaboration among Interfacing Teams
> Expected:
> a. Work product ownership agreements
>   b. Team work plans
>   c. Commitment lists

a. sounds a bit silly, given that all teams contribute to the same product. These are ofc made during sprint planning for each sprint.

b. Sprint backlogs.

c. Happen daily as team members pick up tasks. If necessary, show the names from the sprint backlog at the end of a sprint.

Looks to me, you either have to make up a lot of things, or you have some explaining to do.

> According to me, lot of things will happen during sprint planning and they will be tracked during sprint execution to closure.
>
Looking for opinions from you guys, on how to accomplish any or all of above mentioned practices in sprint planning, execution and closure.

I'll share a recent story from a colleague. We had an external audit recently and one of the assessed projects was a Scrum project where this colleague was the Scrum Master. The auditor, a lady, had a lot of experience on assessments, projects and the traditional way, so she had trouble getting into grips with the project. The discussions were typically something like this:

Auditor: Do you have a quality plan?
SM: Well... no, not really, as a document, but we have a Definition of Done. <showed and explained it>
A: How do you ensure the quality of the final product to avoid surprises at the end?
SM: Well, we don't have a final product release per se, since we deliver a working version from every iteration. We want every iteration to meet the quality criteria, so we don't really see how we could have any surprises since we know any problems immediately.
A: Do you have any quality metrics you track?
SM: No, not really...
A: Well, what could you measure to follow the quality of the project?
SM: <thinks hard> ... how about bugs in sprint releases?
A: <excited> Yes, for example! Do you have a database or similar where you store the bugs?
SM: No, we don't... How many bugs have we had reported by the customer in the last 5 months?
Developer: Two?
...

And so on :).

The auditor said that she didn't really understand how the project worked, but could clearly see that the project had everything in control. She was clearly intrigued by the approach and its results.

Bottom line, I wouldn't try to conform to any waterfall-based process framework, but if you do have to, do stand tall and show what you have. It is very likely to be something much better than what the framework expects. This ofc assuming that you do have the project under control the Scrum way. :)

Yours Sincerely,

Petri

---
Petri Heiramo
Process Development Manager, Agile Coach (CST)
Digia Plc., Finland

• Guys, Any thoughts on mail below. I would really appreciate , if anyone can guide me on mail below. Regards, Vikas ________________________________ From: Vikas
Message 15 of 22 , May 28, 2009
Guys,

Any thoughts on mail below.

I would really appreciate , if anyone can guide me on mail below.

Regards,
Vikas

From: Vikas Atri <vikasait25@...>
To: scrumdevelopment@yahoogroups.com
Sent: Wednesday, 27 May, 2009 6:12:22 PM
Subject: Re: [scrumdevelopment] Re: IPM @CMMIL3

Hi Petri,

Infact, it was a real detailed reply, in context to CMMI practices.
I come from CMMI background and your inputs have really helped out.
I really want to understand the measures for evaluating the performance of integrated teams.
What kind of measures is one supposed to look for?
for "Assessments of the product and product architectures, including risk and complexity"
My understanding for this point is that it happens in Pre-Gaming phase wherein the
product backlog evolves and the product owner continuously  assess the product and product
architectures, including risk and complexity.
Please let me know, if I ma thinking in the right direction.
And I was looking forward to really demonstarte it using some form of template as an evidence.
Regards,
Vikas

From: Petri Heiramo <petri.heiramo@ sysopendigia. com>
To: scrumdevelopment@ yahoogroups. com
Sent: Sunday, 24 May, 2009 12:46:34 AM
Subject: [scrumdevelopment] Re: IPM @CMMIL3

Hi,

> Practice 1: Establish the Projectâ€™s Shared Vision
> Expected: Documented shared vision, Communications strategy, Published principles, shared vision statement, mission statement, and objectives (e.g., posters, wallet cards, and presentations)

Expected: PO has defined and shared the project vision and mission with development team(s) and stakeholders, the PO and the development team have agreed the principles and objectives of the project

> Practice 2: Â Establish the Integrated Team Structure
> Expected:
> a. Assessments of the product and product architectures, including risk and complexity
> b. Integrated team structure

I don't see what a. has to do with "Integrated Team Structure".

I assume "integrated team" to mean a cross-functional team. Right?

b. probably assumes that there is a fixed responsibility structure between the teams. If not, merely list the teams and their members (see 4 also).

> Practice 3. Allocate Requirements to Integrated Teams
> Expected:
>   a. Responsibilities allocated to each integrated team
>   b. Work product requirements, technical interfaces, and business (e.g., cost accounting and project management) interfaces each integrated team will be responsible for satisfying
>   c. List of integrated team sponsors

Expected:
a. At each sprint planning, each integrated team accepts user stories to be developed in the iteration
b. There are existing agreed practices for communicating and agreeing dependencies between the teams

What are c.?

> Practice 4: Establish Integrated Teams
> Expected:
> a. List of team leaders
>   b. List of team members assigned to each integrated team
>   c. Integrated team
charters
>   d. Measures for evaluating the performance of integrated teams

a. is not there in Scrum environment.
b. is okay.
c. What are these??
d. Watch out for these, they tend screw up things.....

> 5. Ensure Collaboration among Interfacing Teams
> Expected:
> a. Work product ownership agreements
>   b. Team work plans
>   c. Commitment lists

a. sounds a bit silly, given that all teams contribute to the same product. These are ofc made during sprint planning for each sprint.

b. Sprint backlogs.

c. Happen daily as team members pick up tasks. If necessary, show the names from the sprint backlog at the end of a sprint.

Looks to me, you either have to make up a lot of things, or you have some explaining to do.

> According to me, lot of things will happen during sprint planning and they will be tracked during sprint execution to closure.
>
Looking for opinions from you guys, on how to accomplish any or all of above mentioned practices in sprint planning, execution and closure.

I'll share a recent story from a colleague. We had an external audit recently and one of the assessed projects was a Scrum project where this colleague was the Scrum Master. The auditor, a lady, had a lot of experience on assessments, projects and the traditional way, so she had trouble getting into grips with the project. The discussions were typically something like this:

Auditor: Do you have a quality plan?
SM: Well... no, not really, as a document, but we have a Definition of Done. <showed and explained it>
A: How do you ensure the quality of the final product to avoid surprises at the end?
SM: Well, we don't have a final product release per se, since we deliver a working version from every iteration. We want every iteration to meet the quality criteria, so we don't really see how we could have any surprises since we know any problems immediately.
A: Do you have any quality metrics you track?
SM: No, not really...
A: Well, what could you measure to follow the quality of the project?
SM: <thinks hard> ... how about bugs in sprint releases?
A: <excited> Yes, for example! Do you have a database or similar where you store the bugs?
SM: No, we don't... How many bugs have we had reported by the customer in the last 5 months?
Developer: Two?
...

And so on :).

The auditor said that she didn't really understand how the project worked, but could clearly see that the project had everything in control. She was clearly intrigued by the approach and its results.

Bottom line, I wouldn't try to conform to any waterfall-based process framework, but if you do have to, do stand tall and show what you have. It is very likely to be something much better than what the framework expects. This ofc assuming that you do have the project under control the Scrum way. :)

Yours Sincerely,

Petri

---
Petri Heiramo
Process Development Manager, Agile Coach (CST)
Digia Plc., Finland

Explore and discover exciting holidays and getaways with Yahoo! India Travel Click here!
• Message 16 of 22 , Jun 14, 2009
On Tue, May 26, 2009 at 09:16, Roy Morien wrote:

If we look at the old management saying that 'if you can't measure it you can't manage it', there may be a grain of truth in that. BUT agile practices indicate that you do not have 'managers', you have leaders, you have mentors and helpful people like Scrum Masters. Is there a saying amongst agile practitioners 'you can't provide leadership if you can't measure it'?

Why do we have this incessant discussion about something as, frankly, inappropriate and irrelevant in agile systems development as 'productivity measurement'? Isn't delivering useful, working software as fast as the team can manage to do so, and doing that apparently better than last 'time', a sufficient measure?

.

• Sorry for previous useless message sent accidentally. If we look at the old management saying that if you can t measure it you ... I think these measurements
Message 17 of 22 , Jun 14, 2009
Sorry for previous useless message sent accidentally.

If we look at the old management saying that 'if you can't measure it you can't manage it', there may be a grain of truth in that. BUT agile practices indicate that you do not have 'managers', you have leaders, you have mentors and helpful people like Scrum Masters. Is there a saying amongst agile practitioners 'you can't provide leadership if you can't measure it'?

Why do we have this incessant discussion about something as, frankly, inappropriate and irrelevant in agile systems development as 'productivity measurement'? Isn't delivering useful, working software as fast as the team can manage to do so, and doing that apparently better than last 'time', a sufficient measure?

I think these measurements are at least useful during Scrum adoption phase where existing 'old management' should believe that the change to Agile/Scrum worth the effort (i.e. should be convinced in a language that they understand before paradigm shift).

And yes, after the shift, we may want to measure other things for other purposes, removing waste.

Dorin
• Hi Tobias, Apologies for coming late to this discussion but I feel I can add something worthwhile. ... It *can* be that but it does not have to. Estimation of
Message 18 of 22 , Jun 14, 2009
Hi Tobias,

Apologies for coming late to this discussion but I feel I can add
something worthwhile.

Tobias Mayer wrote:
>
> I agree with Adam, this "hyper-productivity" measuring is mostly a waste of time
> -- and a way of selling snake oil.

It *can* be that but it does not have to.

Estimation of stories is not a constant
> thing; teams change the way they do this over time as much as they improve their
> ability to deliver. And as Adam points out comparably complex stories require
> less and less effort as we get better.
>
> I think such "quantified" claims do a disservice to Scrum, and as the original
> poster points out, if you set your baseline low enough, everything can appear as
> hyper-productive. What if a team completed nothing at all in sprint one? Then
> getting one story point done in sprint two would represent an infinity%
> increase. It is all nonsense.

Well, what if a team measured their work in iteration 1 and used the
prevailing metrics in the software industry as well as those metrics are
being used by anyone else in the industry? How big an increase would it
take to have significance?

I agree that using iteration 1 story points, as determined by a newly
agile team is very weak. Early on when I first had the chance to have my
team use agile methods, I needed to have something more than anecdotes
to help me keep interference away and show skeptics that this was
valuable, and not just some fluke. Metrics, so long as they were no more
flawed than everyone else's, served that purpose.

But the metrics I took did something totally unexpected - even by me,
and I thought I had a very complete view of things since I was coding
plus managing every day. "It's what you learn *after* you know it all
that really counts", as one of my college profs used to say.

When I analyzed our numbers (many months after starting because I'd
been "too busy" - another mistake, I learned from) I found that the team
was far more productive than I had believed. Not so sure of my data and
its validity, I searched for comparisons. It was at least a couple more
years before I was satisfied with the info I found, and yes, our truly
the amazing productivity increase was real. *

So my view is that we should try to think of meaningful, honest
measurements and use them. We have to watch for sub-optimization of
course. Metrics is a way to get a new vantage point on a situation that
you think you know well. Radio telescopes changed astronomy hugely by
making new views available.

Too often people are using metrics either to sell snake oil, or to
convince people whose minds are made up and aren't going to change no
matter what. But there's a 3rd use - to give ourselves new insights and
confidence in what we've discovered.

>
> Yes, we do see teams improve over time. Let's just use that shared knowledge.
> Scrum does better with real-life subjective metrics than fake objective ones. I
> reckon.
>

It is true that if we simply do better this iteration than last, we
are on the right track. I respect those who want to leave it at that.
But I want more insight. Exploring different people's views helps me get
that. So does the attempt to measure what we're doing. I say "attempt"
because I doubt there will ever be a clear definitive measure, but I
find much value in the attempt, so long as it is conducted *primarily*
to understand, and does not take much overhead to conduct.

- njv

* I presented this at Agile 2006 as "Embedded Agile Project by the
Numbers With Newbies". The paper is on the Publications page of
Sutherland has used Capers Jones' figures for metrics and so did I in
that paper. There's even a way you can compare your own team's metrics
with charts given in the paper.

--
............................................
Nancy Van Schooenderwoert, Lean-Agile Partners Inc.

781 301 1822 US mobile
nancyv@...

http://www.leanagilepartners.com

Specialties: Agile coaching for Embedded Systems, for Data Migrations,
and for leadership of Lean-Agile change organization wide
............................................
• Hi Nancy, Thanks for your thoughtful response. I agree that sometimes metrics present themselves and we d be foolish to discard them. When I first used
Message 19 of 22 , Jun 14, 2009
Hi Nancy,

Thanks for your thoughtful response.  I agree that sometimes metrics present themselves and we'd be foolish to discard them.

When I first used Scrum-like methods at Yahoo! the project was a complete rebuild of a previous product that was basically a mess in all the usual waterfall ways.  The metric I discovered to be useful, after the implementation was complete, was a measure of bugs filed in Bugzilla on the two projects.  The Scrum-like project showed a clear 700% improvement, and no bug was open for more than a couple of days (compared to about 3-4 weeks in the previous project).  This was useful data, and I used it to say to management "look what we did -- other properties could do this too".  I like to believe it played some small part in the Scrum adoption that followed a few months later.

Tobias

• Tobias, Interesting information. In your Scrum like project, using Bugzilla, when was a bug recognised and acknowledged as a bug to be recorded in
Message 20 of 22 , Jun 14, 2009
Tobias,

Interesting information. In your 'Scrum like' project, using Bugzilla, when was a 'bug' recognised and acknowledged as a bug to be recorded in Bugzilla?

Anticipating your answer a little, if 'bugs' were recorded during post-sprint usage of the processes, doesn't that imply that your in-sprint and sprint review activities failed, inasmuch as the bugs should have been discovered then, and not allowed through to become part of the released software?

Regards,
Roy Morien

To: scrumdevelopment@yahoogroups.com
From: scrum@...
Date: Sun, 14 Jun 2009 15:25:35 -0700
Subject: Re: [scrumdevelopment] Hyper productive...

Hi Nancy,

Thanks for your thoughtful response.  I agree that sometimes metrics present themselves and we'd be foolish to discard them.

When I first used Scrum-like methods at Yahoo! the project was a complete rebuild of a previous product that was basically a mess in all the usual waterfall ways.  The metric I discovered to be useful, after the implementation was complete, was a measure of bugs filed in Bugzilla on the two projects.  The Scrum-like project showed a clear 700% improvement, and no bug was open for more than a couple of days (compared to about 3-4 weeks in the previous project).  This was useful data, and I used it to say to management "look what we did -- other properties could do this too".  I like to believe it played some small part in the Scrum adoption that followed a few months later.

Tobias

Click here to find out more POP access for Hotmail is here!
• Hi Roy, Scrum-like isn t Scrum. There was no active product owner, and therefore no reviews. There were also not clearly delineated sprints. Most bugs were
Message 21 of 22 , Jun 14, 2009
Hi Roy,

Scrum-like isn't Scrum.  There was no active product owner, and therefore no reviews.  There were also not clearly delineated sprints.  Most bugs were caught and fixed within a few days as the testers worked side by side with the developers (this was innovative for Yahoo! at that time; almost all testing was of the "over-the-wall" type).  Bugzilla was the tracking system we had been using, and we had not yet thought not to use it.  Which, as it turned out, was just as well as we were able to generate the reports I mentioned.

So, if you are looking to be critical of our Scrum-like process, be my guest :-)  There is much to criticize. And yet, it was a first step on a great journey -- I mean for me, not Yahoo! ;-)  But enough of that.

I should also add, that at the time I wasn't looking to sell Scrum to Yahoo!, but to encourage teams to use the Agile development practices of collaborative team work, pair programming, TDD, early acceptance testing, continuous refactoring and build scripting.

Tobias

--
Tobias Mayer
Agile Thinking | Agile Anarchy

• No, No ... never critical ... I was honestly seeking an explanation. I very much understand about the often necessary implementation of Scrum like
Message 22 of 22 , Jun 14, 2009
No, No ... never critical ... I was honestly seeking an explanation.

I very much understand about the often necessary implementation of 'Scrum like' development processes, and introducing concepts and practices slowly, to avoid 'change indigestion'. Change is often opposed because, to change, can be seen as an implication that what you have been doing (particularly if you have been earnestly supporting and advocating, maybe in the face of opposing views) is wrong, and you have been making a mistake all this time. This is, of course, an unfortunate attitude, very real, but is denying 'progress' and 'learning' as valid activities.

Regards,
Roy Morien

To: scrumdevelopment@yahoogroups.com
From: scrum@...
Date: Sun, 14 Jun 2009 23:06:09 -0700
Subject: Re: [scrumdevelopment] Hyper productive...

Hi Roy,

Scrum-like isn't Scrum.  There was no active product owner, and therefore no reviews.  There were also not clearly delineated sprints.  Most bugs were caught and fixed within a few days as the testers worked side by side with the developers (this was innovative for Yahoo! at that time; almost all testing was of the "over-the-wall" type).  Bugzilla was the tracking system we had been using, and we had not yet thought not to use it.  Which, as it turned out, was just as well as we were able to generate the reports I mentioned.

So, if you are looking to be critical of our Scrum-like process, be my guest :-)  There is much to criticize. And yet, it was a first step on a great journey -- I mean for me, not Yahoo! ;-)  But enough of that.

I should also add, that at the time I wasn't looking to sell Scrum to Yahoo!, but to encourage teams to use the Agile development practices of collaborative team work, pair programming, TDD, early acceptance testing, continuous refactoring and build scripting.

Tobias

--
Tobias Mayer
Agile Thinking | Agile Anarchy