headers
Paul Epps | 21 Jun 2012 19:27
Favicon
Gravatar

Story sizes and productivity gains

I saw a presentation by Scott Downey last night at Agile SoCal on hyperproductive Scrum teams. Downey
defines a hyperproductive team as a team that achieves a 500% increase over its initial velocity, as
measured in story points.

I've seen Ron Jeffries recommend not using story points, instead sizing stories consistently around a
couple of days, and counting stories instead of points. That's always seemed like a good idea to me, but
after Downey's presentation, I was trying to think about how to measure productivity gains when sizing
stories at a couple of days. 

To take a simple example, if I can do a story every two days, then I can do five stories in a two-week sprint. By
definition (story = 2 days), I will continue to complete five stories per sprint forever. In order to
demonstrate improvement over time, I would need a new measurement, e.g., value, right?

Any ideas on how to measure team productivity over time using consistent story sizes?

Thanks...

Paul Epps
Permalink | Reply | 17 comments |
headers
Chet Hendrickson | 21 Jun 2012 19:44
Favicon

Re: Story sizes and productivity gains

Hello Paul,

Please describe the process that this 'productivity measure' will be input to.  What is its purpose?

chet

Thursday, June 21, 2012, 1:27:06 PM, you wrote:

  
I saw a presentation by Scott Downey last night at Agile SoCal on hyperproductive Scrum teams. Downey
defines a hyperproductive team as a team that achieves a 500% increase over its initial velocity, as
measured in story points.

I've seen Ron Jeffries recommend not using story points, instead sizing stories consistently around a
couple of days, and counting stories instead of points. That's always seemed like a good idea to me, but
after Downey's presentation, I was trying to think about how to measure productivity gains when sizing
stories at a couple of days. 

To take a simple example, if I can do a story every two days, then I can do five stories in a two-week sprint. By
definition (story = 2 days), I will continue to complete five stories per sprint forever. In order to
demonstrate improvement over time, I would need a new measurement, e.g., value, right?

Any ideas on how to measure team productivity over time using consistent story sizes?

Thanks...

Paul Epps

--

-- 
Best regards,
(Continue reading)

Permalink | Reply | 4 comments |
headers
Paul Epps | 21 Jun 2012 20:27
Favicon
Gravatar

Re: Story sizes and productivity gains

Hi Chet - 

> Please describe the process that this 'productivity measure' will be input to.  What is its purpose?

Downey described the purpose with this user story: AS A Scrum Product Owner who is trying to evaluate the
efficacy of the product directions I have chosen, I NEED a reliable way to measure the increased value 
contribution of the Team sprint-over-sprint SO THAT I can compare the Team's rate of value contribution
increase to the changes in revenue we are generating and adjust our direction if the value isn't being realized.

Thanks...

pe

> Thursday, June 21, 2012, 1:27:06 PM, you wrote:
> 
> 
>   
> I saw a presentation by Scott Downey last night at Agile SoCal on hyperproductive Scrum teams. Downey
defines a hyperproductive team as a team that achieves a 500% increase over its initial velocity, as
measured in story points.
> 
> I've seen Ron Jeffries recommend not using story points, instead sizing stories consistently around a
couple of days, and counting stories instead of points. That's always seemed like a good idea to me, but
after Downey's presentation, I was trying to think about how to measure productivity gains when sizing
stories at a couple of days. 
> 
> To take a simple example, if I can do a story every two days, then I can do five stories in a two-week sprint. By
definition (story = 2 days), I will continue to complete five stories per sprint forever. In order to
demonstrate improvement over time, I would need a new measurement, e.g., value, right?
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Steven Gordon | 21 Jun 2012 20:28
Picon

Re: Story sizes and productivity gains

I suspect the relationship is backwards here: We should be finding that the
bigger the stories a team works on, the slower the team would increase its
productivity.

Productivity should be measure as actual value delivered to the customer
over time, not something based on estimates.

(BTW, I really enjoy the pushback I get from management on that - that
development should be responsible for precise enough estimations to support
all sorts of management metrics whereas the business does not have to be
responsible for determining the actual value of being delivered what they
ask for).

SteveG

On Thu, Jun 21, 2012 at 10:27 AM, Paul Epps <paul <at> eppsnet.com> wrote:

> **
>
>
> I saw a presentation by Scott Downey last night at Agile SoCal on
> hyperproductive Scrum teams. Downey defines a hyperproductive team as a
> team that achieves a 500% increase over its initial velocity, as measured
> in story points.
>
> I've seen Ron Jeffries recommend not using story points, instead sizing
> stories consistently around a couple of days, and counting stories instead
> of points. That's always seemed like a good idea to me, but after Downey's
> presentation, I was trying to think about how to measure productivity gains
> when sizing stories at a couple of days.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Steven Gordon | 21 Jun 2012 20:33
Picon

Re: Story sizes and productivity gains

What else contributes to revenue changes?  How can knowing how much the
team delivered differentiate among all those contributions to revenue
changes?

Root cause the revenue problems and see where development, marketing,
sales, product ownership, etc. is involved.  Assuming that the quantity
delivered indicates whether development is the problem is lazy.

SteveG

On Thu, Jun 21, 2012 at 11:27 AM, Paul Epps <paul <at> eppsnet.com> wrote:

> **
>
>
> Hi Chet -
>
> > Please describe the process that this 'productivity measure' will be
> input to. What is its purpose?
>
> Downey described the purpose with this user story: AS A Scrum Product
> Owner who is trying to evaluate the efficacy of the product directions I
> have chosen, I NEED a reliable way to measure the increased value
> contribution of the Team sprint-over-sprint SO THAT I can compare the
> Team's rate of value contribution increase to the changes in revenue we are
> generating and adjust our direction if the value isn't being realized.
>
> Thanks...
>
> pe
(Continue reading)

Permalink | Reply | 0 comments |
headers
George Dinwiddie | 21 Jun 2012 20:38
Favicon

Re: Story sizes and productivity gains

Paul,

On 6/21/12 1:27 PM, Paul Epps wrote:
	[snip]
> Any ideas on how to measure team productivity over time using
> consistent story sizes?

Any ideas on how to measure team productivity?

  - George

--

-- 
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org
  ----------------------------------------------------------------------
Permalink | Reply | 5 comments |
headers
RonJeffries | 21 Jun 2012 20:43
Picon
Favicon
Gravatar

Re: Story sizes and productivity gains

Hi Paul,

On Jun 21, 2012, at 2:27 PM, Paul Epps wrote:

> Downey described the purpose with this user story: AS A Scrum Product Owner who is trying to evaluate the
efficacy of the product directions I have chosen, I NEED a reliable way to measure the increased value 
> contribution of the Team sprint-over-sprint SO THAT I can compare the Team's rate of value contribution
increase to the changes in revenue we are generating and adjust our direction if the value isn't being realized.

That strikes me as ... how can I put this nicely ... overly indirect. It's a red herring. 

I suspect the real purpose of wanting to know this is to "measure" how hard the team is working and how much
they are accomplishing. This is a cost focus. Scrum projects are supposed to have a value focus: the PO is
responsible for producing the highest possible value by the deadline. This is done quite simply: have the
highest value possible in every Sprint.

The team is producing valuable stories at some rate. The PO's job is to select them so as to have the best
possible value at every moment in time. If the stories are all the same "size", and the team is doing quality
work (suitable testing and design improvement), the flow of work will be perfectly clear: you can draw a
line to see how many more stories will be done.

If and when the team improves, the stories they can do in two days will be discernibly "larger". Everyone who
is paying attention will notice this and take it into account when guessing how much they'll get done.

BUT THIS IS NOT IMPORTANT, because the PO always has the highest possible value attainable at the current
moment, in potentially shippable form. 

If the revenue potential of an idea is anywhere near the cost of the team building it, it is an incredibly bad
idea and well past time to stop investing in the product. Therefore, at any moment in time, the PO can pick up
her most favorite story and say to herself "This will bring in $11,000 in revenue and the team costs me
(Continue reading)

Permalink | Reply | 0 comments |
headers
RonJeffries | 21 Jun 2012 20:44
Picon
Favicon
Gravatar

Re: Story sizes and productivity gains

George ...

On Jun 21, 2012, at 2:38 PM, George Dinwiddie wrote:

> Any ideas on how to measure team productivity?

Any ideas on WHY to measure team productivity?

Ron Jeffries
www.XProgramming.com
Wisdom begins when we understand the difference between "that makes no sense" and "I don't understand". --
Mary Doria Russell

[Non-text portions of this message have been removed]
Permalink | Reply | 4 comments |
headers
George Dinwiddie | 21 Jun 2012 21:03
Favicon

Re: Story sizes and productivity gains

Ron,

On 6/21/12 2:44 PM, RonJeffries wrote:
> George ...
>
> On Jun 21, 2012, at 2:38 PM, George Dinwiddie wrote:
>
>> Any ideas on how to measure team productivity?
>
>
> Any ideas on WHY to measure team productivity?

Another good question. My initial point is that the rest of the sentence 
is superfluous. Even if we think we have a good reason (or are just 
curious), we have /no/ way to measure this concept "productivity" in 
knowledge work.

  - George

--

-- 
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org
  ----------------------------------------------------------------------
Permalink | Reply | 3 comments |
headers
RonJeffries | 21 Jun 2012 21:17
Picon
Favicon
Gravatar

Re: Story sizes and productivity gains

Hi George,

On Jun 21, 2012, at 3:03 PM, George Dinwiddie wrote:

> My initial point is that the rest of the sentence 
> is superfluous. Even if we think we have a good reason (or are just 
> curious), we have /no/ way to measure this concept "productivity" in 
> knowledge work.

Yes, I do fully agree, of course. In addition, I've never seen a proposed measure that I could not
immediately game to my advantage.

Ron Jeffries
www.XProgramming.com
I try to Zen through it and keep my voice very mellow and low.
Inside I am screaming and have a machine gun.
Yin and Yang I figure.
  -- Tom Jeffries

[Non-text portions of this message have been removed]
Permalink | Reply | 1 comment |

Gmane