Browse Groups

• Ron, Yes! I think Pareto would be rolling in his grave if he heard someone talking like: High = 3 and Low = 1 . Does not sound like a Pareto Principle to
Message 1 of 20 , Mar 1, 2009
View Source
Ron,

Yes! I think Pareto would be rolling in his grave if he heard someone
talking like: "High = 3 and Low = 1". Does not sound like a Pareto
Principle to me.

My experience is that the highest BV is about 3 *orders of magnitude*
bigger than the lowest. I have seen this and it was important to know.

Things can vary. But for most populations, I think the safest
assumption should be that 20% of the stories (story points?) give 80%
of the value.

Eyesight varies even more than things...(especially if you don't clean
your glasses). Put more seriously, it takes a really good person
(I'll call 'em a really good Product Owner) to see the dispersion of
things across the 3 orders of magnitude. A bunch of us seem to have
the foolish notion: "absent other info, let's assume all stories have

I am not a Pareto expert. Anyone know what his ideas would postulate?

Now: Should we also do cost-benefit analysis? (ratio of BV points to
Story Points) Yes, that would tend to help some.

Thanks, Joe

--- In leanagile@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
>
> Hello, Drew. On Saturday, February 28, 2009, at 12:09:35 AM, you
> wrote:
>
> > If you want to measure the business value received by effort for a
> > sprint, there's a method I like. Let's say you have your stories
> > prioritized as High Value = 3, Medium Value = 2, and Low Value = 1.
> > You can then sum the values of the priorities and divide by the story
> > points delivered in a Sprint.
>
> Do you actually use different numbers from these? Seems to me that
> the best story is a lot more than 3x the value of the worst.
>
> Ron Jeffries
> www.XProgramming.com
> www.xprogramming.com/blog
> Attend our CSM Plus Course!
> http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
> The rules are ways of thinking, not ways to avoid thinking.
>
• ... magnitude* ... know. ... We actually use the same point sizes for business value as we use for story sizing - 1, 2, 3, 5, 8, 13, 20, 40, 100, 200, 400,
Message 1 of 20 , Mar 1, 2009
View Source
--- In leanagile@yahoogroups.com, "Joseph Little" <jhlittle@...>
wrote:
>
> My experience is that the highest BV is about 3 *orders of
magnitude*
> bigger than the lowest. I have seen this and it was important to
know.
>

We actually use the same point sizes for business value as we use for
story sizing - 1, 2, 3, 5, 8, 13, 20, 40, 100, 200, 400, 800.

We do this because we take a top-down approach and size from features
which we then break down into stories. At some point stories will be
small but they don't represent the true business value because they
only represent part of what has to be released.

Sizing of business value should be done at the Minimum Marketable
Feature (MMF) as well as at the story level.

While I believe in the pareto rule that 20% of the work will give you
80% of the of the value, you find that 20% by focusing on MMFs.
Another shortcut is if you can't establish business value, don't
bother doing story sizing.

Alan Shalloway
CEO, Net Objectives
Achieving Enterprise and Team Agility
• ... We ve actually used that in the past but have run into issues with it. A couple of them include: 1) Establishing a baseline unit of business value (what
Message 1 of 20 , Mar 1, 2009
View Source
Alan wrote:
> We actually use the same point sizes for business value as we use for
> story sizing - 1, 2, 3, 5, 8, 13, 20, 40, 100, 200, 400, 800.

We've actually used that in the past but have run into issues with it.
A couple of them include:

1) Establishing a baseline unit of business value (what does 1 mean?)
2) Arriving at a single number. In a given product there are a number
of stakeholders that have say in the product/project. Customer Service
claims that there is high value in "feature a", Product Management
claims that there is higher value in adding "feature b". Who's right?
They both have different objectives in the organization. We started
out just taking an average of the value points, but switched to using
a combination of average and standard deviation to resolve
differences.

I also began to wonder if the level of precision is appropriate. Using
0-3 gives us what we need quickly without much debate amongst the
stakeholders.

I'd be willing to give the Fibonacci series another try if the list
has suggestions on how to resolve these issues. For now, using the 0-3
attribute scoring mechanism is working great for us.

Thanks!
Brandon

On Sun, Mar 1, 2009 at 3:00 PM, Alan Shalloway
<alshall@...> wrote:
> --- In leanagile@yahoogroups.com, "Joseph Little" <jhlittle@...>
> wrote:
>
>>
>> My experience is that the highest BV is about 3 *orders of
> magnitude*
>> bigger than the lowest. I have seen this and it was important to
> know.
>>
>
> We actually use the same point sizes for business value as we use for
> story sizing - 1, 2, 3, 5, 8, 13, 20, 40, 100, 200, 400, 800.
>
> We do this because we take a top-down approach and size from features
> which we then break down into stories. At some point stories will be
> small but they don't represent the true business value because they
> only represent part of what has to be released.
>
> Sizing of business value should be done at the Minimum Marketable
> Feature (MMF) as well as at the story level.
>
> While I believe in the pareto rule that 20% of the work will give you
> 80% of the of the value, you find that 20% by focusing on MMFs.
> Another shortcut is if you can't establish business value, don't
> bother doing story sizing.
>
> Alan Shalloway
> CEO, Net Objectives
> Achieving Enterprise and Team Agility
>
>
• ... for ... it. ... mean?) ... number ... Service ... right? ... using ... Using ... 0-3 ... 0-3 doesn t give a baseline number as well. The idea really is
Message 1 of 20 , Mar 1, 2009
View Source
--- In leanagile@yahoogroups.com, Brandon Carlson <bcarlso@...> wrote:
>
> Alan wrote:
> > We actually use the same point sizes for business value as we use
for
> > story sizing - 1, 2, 3, 5, 8, 13, 20, 40, 100, 200, 400, 800.
>
> We've actually used that in the past but have run into issues with
it.
> A couple of them include:
>
> 1) Establishing a baseline unit of business value (what does 1
mean?)
> 2) Arriving at a single number. In a given product there are a
number
> of stakeholders that have say in the product/project. Customer
Service
> claims that there is high value in "feature a", Product Management
> claims that there is higher value in adding "feature b". Who's
right?
> They both have different objectives in the organization. We started
> out just taking an average of the value points, but switched to
using
> a combination of average and standard deviation to resolve
> differences.
>
> I also began to wonder if the level of precision is appropriate.
Using
> 0-3 gives us what we need quickly without much debate amongst the
> stakeholders.
>
> I'd be willing to give the Fibonacci series another try if the list
> has suggestions on how to resolve these issues. For now, using the
0-3
> attribute scoring mechanism is working great for us.
>
> Thanks!
> Brandon

0-3 doesn't give a baseline number as well. The idea really is that
the business value is relative - that's why tying it in with team
estimation is so good.

I've worked with clients who have a feature whose implementation will
take a day, while others have features that will take 6 months to do.
Although I am talking effort here, you can imagine a corresponding
size in business value and therefore a 3-1 ratio won't work.

that is something that needs to be addressed. Most companies have
their development team steer (whether it be IT or product companies) -
not a good thing.

Again, relative estimation makes things easier, and is all that is
really needed.

Alan Shalloway
CEO, Net Objectives
Achieving Enterprise and Team Agility

>
> On Sun, Mar 1, 2009 at 3:00 PM, Alan Shalloway
> <alshall@...> wrote:
> > --- In leanagile@yahoogroups.com, "Joseph Little" <jhlittle@>
> > wrote:
> >
> >>
> >> My experience is that the highest BV is about 3 *orders of
> > magnitude*
> >> bigger than the lowest. I have seen this and it was important to
> > know.
> >>
> >
> > We actually use the same point sizes for business value as we use
for
> > story sizing - 1, 2, 3, 5, 8, 13, 20, 40, 100, 200, 400, 800.
> >
> > We do this because we take a top-down approach and size from
features
> > which we then break down into stories. At some point stories will
be
> > small but they don't represent the true business value because
they
> > only represent part of what has to be released.
> >
> > Sizing of business value should be done at the Minimum Marketable
> > Feature (MMF) as well as at the story level.
> >
> > While I believe in the pareto rule that 20% of the work will give
you
> > 80% of the of the value, you find that 20% by focusing on MMFs.
> > Another shortcut is if you can't establish business value, don't
> > bother doing story sizing.
> >
> > Alan Shalloway
> > CEO, Net Objectives
> > Achieving Enterprise and Team Agility
> >
> >
>
• ... Agreed. I ve found that Indifferent , Low , Medium , and High is much easier to grok for the stakeholders than deciding between a 5, 8, or 13.
Message 1 of 20 , Mar 1, 2009
View Source
Alan wrote:
> 0-3 doesn't give a baseline number as well.

Agreed. I've found that "Indifferent", "Low", "Medium", and "High" is
much easier to grok for the stakeholders than deciding between a 5, 8,
or 13. Deciding whether it's a 1 or a 20 is much easier to do.

> Although I am talking effort here, you can imagine a corresponding
> size in business value and therefore a 3-1 ratio won't work.

If you are scoring a feature as a 1, 2, 3, then I tend to agree.
That's not what our model is about however. Each prioritization
"attribute" is socred between 0 and 3. The net value of the story is a
combination of all of the attributes' scores, with optional weighting
in certain categories of attributes. For example, some of our MMFs
have scores in the 70s-80s.

Agreed. Which what our system is about. Bringing to the forefront all
of the considerations of each of the stakeholders in a lightweight
manner.

Thanks!
Brandon

On Sun, Mar 1, 2009 at 3:25 PM, Alan Shalloway
<alshall@...> wrote:
> --- In leanagile@yahoogroups.com, Brandon Carlson <bcarlso@...> wrote:
>>
>> Alan wrote:
>> > We actually use the same point sizes for business value as we use
> for
>> > story sizing - 1, 2, 3, 5, 8, 13, 20, 40, 100, 200, 400, 800.
>>
>> We've actually used that in the past but have run into issues with
> it.
>> A couple of them include:
>>
>> 1) Establishing a baseline unit of business value (what does 1
> mean?)
>> 2) Arriving at a single number. In a given product there are a
> number
>> of stakeholders that have say in the product/project. Customer
> Service
>> claims that there is high value in "feature a", Product Management
>> claims that there is higher value in adding "feature b". Who's
> right?
>> They both have different objectives in the organization. We started
>> out just taking an average of the value points, but switched to
> using
>> a combination of average and standard deviation to resolve
>> differences.
>>
>> I also began to wonder if the level of precision is appropriate.
> Using
>> 0-3 gives us what we need quickly without much debate amongst the
>> stakeholders.
>>
>> I'd be willing to give the Fibonacci series another try if the list
>> has suggestions on how to resolve these issues. For now, using the
> 0-3
>> attribute scoring mechanism is working great for us.
>>
>> Thanks!
>> Brandon
>
> 0-3 doesn't give a baseline number as well. The idea really is that
> the business value is relative - that's why tying it in with team
> estimation is so good.
>
> I've worked with clients who have a feature whose implementation will
> take a day, while others have features that will take 6 months to do.
> Although I am talking effort here, you can imagine a corresponding
> size in business value and therefore a 3-1 ratio won't work.
>
> Most businesses aren't very good at quantifying business value - but
> that is something that needs to be addressed. Most companies have
> their development team steer (whether it be IT or product companies) -
> not a good thing.
>
> Again, relative estimation makes things easier, and is all that is
> really needed.
>
> Alan Shalloway
> CEO, Net Objectives
> Achieving Enterprise and Team Agility
>
>>
>> On Sun, Mar 1, 2009 at 3:00 PM, Alan Shalloway
>> <alshall@...> wrote:
>> > --- In leanagile@yahoogroups.com, "Joseph Little" <jhlittle@>
>> > wrote:
>> >
>> >>
>> >> My experience is that the highest BV is about 3 *orders of
>> > magnitude*
>> >> bigger than the lowest. I have seen this and it was important to
>> > know.
>> >>
>> >
>> > We actually use the same point sizes for business value as we use
> for
>> > story sizing - 1, 2, 3, 5, 8, 13, 20, 40, 100, 200, 400, 800.
>> >
>> > We do this because we take a top-down approach and size from
> features
>> > which we then break down into stories. At some point stories will
> be
>> > small but they don't represent the true business value because
> they
>> > only represent part of what has to be released.
>> >
>> > Sizing of business value should be done at the Minimum Marketable
>> > Feature (MMF) as well as at the story level.
>> >
>> > While I believe in the pareto rule that 20% of the work will give
> you
>> > 80% of the of the value, you find that 20% by focusing on MMFs.
>> > Another shortcut is if you can't establish business value, don't
>> > bother doing story sizing.
>> >
>> > Alan Shalloway
>> > CEO, Net Objectives
>> > Achieving Enterprise and Team Agility
>> >
>> >
>>
>
>
• ... I don t completely understand the question. I presume you mean things like Increase customer satisfaction by 10% , but I m not sure. ... That s the
Message 1 of 20 , Mar 1, 2009
View Source
Dick wrote:
> Don't you want to know what specific Business values are sought by
> management and how their achievement is to be measured?

I don't completely understand the question. I presume you mean things
like "Increase customer satisfaction by 10%", but I'm not sure.

> Then to pick what to do in the next sprint I'd tote up the anticipated
> gains, goal by goal, for each of the most promising stories to include and
> discuss the estimated costs and benefits with the Product Owner and perhaps
> higher management as well.

That's the challenge in my mind. What are the anticipated benefits?
It's all a big SWAG, and I'm not sure I am 100% comfortable with
leaving the "S" in the acronym. Often the decision is discussed to
death and then an emotional decision is made. This process takes much
of the discussion out of the picture and replaces it with a single
number. Then we make an emotional decision. :-)

Thanks!
Brandon

On Sat, Feb 28, 2009 at 7:38 PM, Richard Karpinski
<dickkarpinski@...> wrote:
> Hi Brandon,
>
> Don't you want to know what specific Business values are sought by
> management and how their achievement is to be measured? If management wants
> to ignore usability, customer satisfaction, reliability, and so forth, don't
> we have to accede to their wishes?
>
> I would make a passionate case for management to attend more to their
> customers needs, and I might leave the company if they refused, but if I
> stayed, I presume I'd try to achieve what management wanted.
>
> Then to pick what to do in the next sprint I'd tote up the anticipated
> gains, goal by goal, for each of the most promising stories to include and
> discuss the estimated costs and benefits with the Product Owner and perhaps
> higher management as well.
>
> I get the impression, that with Scrum just focused on the team, the PO just
> delivers her ranking of backlog items to the team without discussion. I hope
> that's not what is actually done or recommended, but that is my impression
>
> Surely Tom G. and Tom and Mary P. would not encourage that simplification of
> method. Perhaps I'm just too fond of the five (or more) whys to accept
> anybody's stories without seeking the ultimate Business purposes they are
> intended to serve.
>
> Usually I suspect a better path can be found than is initially proposed by
> someone not trained in architecture, software engineering, and usability.
> But user testing is the gold standard even for heroic designers, so short
> iteration cycles remain vital to success.
>
> Dick
>
> On Sat, Feb 28, 2009 at 1:35 PM, Brandon Carlson <bcarlso@...> wrote:
>>
>> Ron wrote:
>> > Do you actually use different numbers from these? Seems to me that
>> > the best story is a lot more than 3x the value of the worst.
>>
>> We use 0-3 in our scheme, and don't currently worry about relative
>> value. I'm interested in everyone's thoughts about our scheme:
>>
>>
>> http://blog.projectconnections.com/project_practitioners/2008/09/story-prioritiz.html
>>
>> Thanks!
>> Brandon
>>
>> On Sat, Feb 28, 2009 at 6:19 AM, Ron Jeffries <ronjeffries@...> wrote:
>> > Hello, Drew. On Saturday, February 28, 2009, at 12:09:35 AM, you
>> > wrote:
>> >
>> >> If you want to measure the business value received by effort for a
>> >> sprint, there's a method I like. Let's say you have your stories
>> >> prioritized as High Value = 3, Medium Value = 2, and Low Value = 1.
>> >> You can then sum the values of the priorities and divide by the story
>> >> points delivered in a Sprint.
>> >
>> > Do you actually use different numbers from these? Seems to me that
>> > the best story is a lot more than 3x the value of the worst.
>> >
>> > Ron Jeffries
>> > www.XProgramming.com
>> > www.xprogramming.com/blog
>> > Attend our CSM Plus Course!
>> > http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
>> > The rules are ways of thinking, not ways to avoid thinking.
>> >
>> >
>
>
>
> --
> Dick Karpinski, Nitpicker extraordinaire
> 148 Sequoia Circle, Santa Rosa, CA 95401
> Home: 707-546-6760    Cell: 707-228-9716
> http://nitpicker.pbwiki.com/
> My writings default to Creative Commons copyright licensing; for details,
> income.
>
>
>
• I thought I would follow-up with the group, since I did some research on this after posting my original message. Remember, my focus was software quality
Message 1 of 20 , Mar 1, 2009
View Source
I thought I would follow-up with the group, since I did some research
on this after posting my original message. Remember, my focus was
software quality metrics.

I found Stephen Kan's work on this subject pretty good and settled on
an initial set of metrics to further investigate.  I summarized some
of his work for the internal team.

Please note that the in-process metrics are context dependent. These
are the high level metrics Mr. Kan has in this book, but are not
necessarily correct for all organizations (for example, my
organization has to abide by some standards for safety critical
systems that would become an important part of our metrics program for
the projects/products that have to conform to those standards).

Hope this helps the group. I highly recommend Kan's book on the subject.

-- Hank

-----
Background:
Software metrics can be classified into three categories:  product,
process, and project metrics.  For purposes of this discussion, we
focus on product and process metrics.

Product metrics describe the characteristics of the product (e.g.,
size, complexity, design features, performance, quality level)

Process metrics can be used to improve software development and
maintenance (e.g., effectiveness of defect removal, pattern of defect
arrival, etc.).

Project metrics describe the project characteristics and execution
(e.g., number of development, cost, schedule, etc.).

Some metrics belong in multiple categories.

Software _quality_ metrics are a subset of software metrics focusing
on the quality aspects of the product, process, and project.  In
general these are more closely associated with process and product
metrics.  These can be further subdivided into end-product quality and
in-process quality.  Further, should view quality from the entire
software life-cycle, so should include metrics that measure quality
level of maintenance process.

Conclusion, three main categories of software quality metrics:
product quality, in process, and maintenance.

Product Quality Metrics:  Intrinsic Product Quality and Customer Satisfaction

Intrinsic:

Mean Time to Failure (MTTF), how long the software can run without
encountering a 'crash', usually associated with safety critical
systems, gathering this data is usually expensive (hence the usage
typically limited to safety critical systems)

Defect Density - used in many commercial software systems, in general
is number of defects over opportunities for error.  Defects can be
number found internally or by customers.  Opportunities for error can
be function points or lines of code; both have their drawbacks and
benefits; both have ways to game the system.   For each release have
to consider something like opportunities current release =
opportunities of previous release + changed opportunities for current
release (new and change lines of code or function points) - deleted
opportunities - changed opportunities (to avoid double counting).
However, from customer perspective defect rate not as important as
total number of defects that can affect their operations; this leads
to a goal of decreasing the total number of defect release-to-release.

These two metrics are correlated, but different.  There are standards
for defining a defect (or fault) from IEEE/ANSI (982.2)

Customer Satisfaction:

Customer problems:  total problems that customers reported (true
defects and non-defect oriented problems) for a time period / total
number of license months of the software during the period where
software x number of months in calculation.  Calculate each month
after release.  Reason to measure is because this includes items that
may not be totally under the control of the software development team
(i.e., it measure more than just 'defects', it is a measure of
intrinsic quality and other factors)

Customer satisfaction:  Very basic, measure on a scale of very
satisfied, satisfied, neutral, dissatisfied, and very dissatisfied (or
on scale of 10-1, like net promoter).  Important not just to average,
but to look at population distribution in each category.
In-process metrics:

Goal is to engineer quality into the process, in process metric play
an important role in programming.  These are less formally defined
that end product metrics and practices tend to vary greatly among
developers and are often context dependent (this is important).

Defect Density During Machine Testing (after code is integrated):
Highly correlated to defect density.  Simple metric of defects per
opportunity, important to measure release-to-release, depends on
effort of testing.  Basic decision tree on direction of product
quality or next action.

Defect Arrival Pattern During Machine Testing:  Looking at rate of
arrival of defects.  Should be decreasing and very low later in the
development cycle.  Also want to measure pattern of defect backlog
overtime (are defects getting removed fast or is a backlog of

Phase-Based Defect Removal Pattern: An addition to defect arrival,
includes measuring where (analysis, design, etc.) defect was removed.
Again, this is about a pattern over time, not an absolute number.
Looking to remove defects earlier in the cycle.  Can also include
metrics like inspection coverage (code inspections are best way to
remove defects) and inspection effort.  May include control
boundaries, etc.

Defect Removal Effectiveness: Defects removed during a development
phase / defects latent in product (as %).  Hard to measure latent
defects, so the denominator is usually approximated as (Defects
removed during the phase + defects found later).  Can be calculated
for entire development process, or by 'phase'.  Goal is for early
defect removal.

(Note, for iterative or agile processes, phase may be equal to
iteration or sprint and not the typical phases of analysis, design,
etc.).

Metrics for Software Maintenance:

When software enters market it enters maintenance phase.  What can be
done during maintenance is to fix defects as quickly as possible with
high quality.

Fix backlog and backlog management index:  number of problems closed
during month / number of problem arrivals during the month (as a %).
If greater than 100 then backlog of fixes to be done is reduced; if
less than 100 then it is growing.  May want to set control limits.

Fix response time and fix responsiveness:  simple metric, mean time of
all problems from open to closed.  From customer standpoint, may not
just be about short fix time, but committed fix time vs. actual fix
time (see next metric).

Percent Delinquent fixes: number of fixes that exceeded the response
time criteria by severity level / number of fixes delivered in a
specified time (as a %).  This is a sort of SLA for fixes.

Fix Quality:  Measures the number of fixes that were defective (didn't
fix the problem).  Measures absolute number, goal is zero.

Other metrics that may be important, but depend on context:

Object orient development has measurement of complexity and modularity
that are indicators of the quality of the product.

Availability is typically measure for hosted (e.g., SaaS) systems.
Availability includes uptime as well as time to recover.
-----

On Fri, Feb 20, 2009 at 7:51 AM, hhroark <Hank.Roark@...> wrote:
>
> I posted this over on the Scrum Development list first, but given the
> narrow focus of that list I'm afraid I asked the wrong group for
> input/help.
>
> Hello -
>
> There is some interested in my company in establishing some metrics
> for software product quality. We have the equivalent metrics for the
> manufacturing portion of our business that include things like returns
> and allowances, customer support readiness, product first pass yield, etc.
>
> We are thinking that our software centric products probably need some
> different metrics (while still including important metrics like
> returns and allowances and customer support readiness)...stuff like
> customer satisfaction, time to resolve 'defects', and for hosted
> systems availability. We are mostly focused on 'operational' metrics
> at this point, not design time metrics (but we understand the two are
> interrelated).
>
> Does anyone have any suggestions for material (books/articles) or
> benchmarks from companies that you would mind passing along?
>
> Cheers,
> Hank
>
>
• Brandon, When I read that I was moved to respond on that page: The question is what happens at the retrospective? Had the right choices been made? If so, your
Message 1 of 20 , Mar 1, 2009
View Source
Brandon,

When I read that I was moved to respond on that page:

The question is what happens at the retrospective? Had the right choices been made? If so, your method works, if not, then try something else. But how do you capture the experience so as to learn from it? To my mind, the top concern is how to keep getting better as we gain experience. Otherwise we lose the game.

When I had finished typing, I was informed: We're sorry, we cannot accept this data

Now that is cruel. This page, with your name on it invites me to invest my time and effort and then some robot rudely rejects my contribution with no explanation. Please don't be so mean to people you invite to your page. If you don't want my input, just don't ask for it.

Dick

On Sat, Feb 28, 2009 at 1:35 PM, Brandon Carlson wrote:

Ron wrote:
> Do you actually use different numbers from these? Seems to me that
> the best story is a lot more than 3x the value of the worst.

We use 0-3 in our scheme, and don't currently worry about relative
value. I'm interested in everyone's thoughts about our scheme:

http://blog.projectconnections.com/project_practitioners/2008/09/story-prioritiz.html

Thanks!
Brandon

On Sat, Feb 28, 2009 at 6:19 AM, Ron Jeffries <ronjeffries@...> wrote:
> Hello, Drew. On Saturday, February 28, 2009, at 12:09:35 AM, you
> wrote:
>
>> If you want to measure the business value received by effort for a
>> sprint, there's a method I like. Let's say you have your stories
>> prioritized as High Value = 3, Medium Value = 2, and Low Value = 1.
>> You can then sum the values of the priorities and divide by the story
>> points delivered in a Sprint.
>
> Do you actually use different numbers from these? Seems to me that
> the best story is a lot more than 3x the value of the worst.
>
> Ron Jeffries
> www.XProgramming.com
> www.xprogramming.com/blog
> Attend our CSM Plus Course!
> http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
> The rules are ways of thinking, not ways to avoid thinking.
>
>

--
Dick Karpinski, Nitpicker extraordinaire
148 Sequoia Circle, Santa Rosa, CA 95401
Home: 707-546-6760    Cell: 707-228-9716
http://nitpicker.pbwiki.com/

• ... I found I had to enable javascript for typepad.com to make the error message go away. There was no confirmation that my comment was accepted by the
Message 1 of 20 , Mar 2, 2009
View Source
Richard Karpinski wrote:
> When I had finished typing, I was informed: We're sorry, we cannot
> accept this data
>
> my time and effort and then some robot rudely rejects my contribution
> with no explanation. Please don't be so mean to people you invite to
> your page. If you don't want my input, just don't ask for it.

I found I had to enable javascript for typepad.com to make the error
message go away. There was no confirmation that my comment was accepted
by the system, however. I don't know if it got in, or not.

Re the subject line, by my count this is two complaints against the
commenting system. ;-)

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
• The HBS has an interesting article making similar points about metrics/goals that have recently been made here: http://hbswk.hbs.edu/item/5969.html
Message 1 of 20 , Mar 2, 2009
View Source

The HBS has an interesting article making similar points about metrics/goals that have recently been made here:

• ... Look into scorecards from the Design for Lean Six Sigma world. The idea is tie your metrics to your user needs and flow down
Message 1 of 20 , Mar 2, 2009
View Source
>
> Does anyone have any suggestions for material (books/articles) or
> benchmarks from companies that you would mind passing along?
>
Look into scorecards from the Design for Lean Six Sigma world. <vast
oversimplification>The idea is tie your metrics to your user needs and flow down metrics that
allow you to monitor the requirements that are critical-to-quality.</vast oversimplification>
If you would like to know more, please check out this blog post where I talk about how to
derive measures for an Agile transition.

http://lookforwardconsulting.com/?p=195

Carlton
• Message 1 of 20 , Mar 3, 2009
View Source
Re: [leanagile] Re: Metrics

On 3/2/09 12:18 AM, "Richard Karpinski" <dickkarpinski@...> wrote:

Brandon,

When I read that I was moved to respond on that page:

The question is what happens at the retrospective? Had the right choices been made? If so, your method works, if not, then try something else. But how do you capture the experience so as to learn from it? To my mind, the top concern is how to keep getting better as we gain experience. Otherwise we lose the game.

When I had finished typing, I was informed: We're sorry, we cannot accept this data

Now that is cruel. This page, with your name on it invites me to invest my time and effort and then some robot rudely rejects my contribution with no explanation. Please don't be so mean to people you invite to your page. If you don't want my input, just don't ask for it.

Dick

On Sat, Feb 28, 2009 at 1:35 PM, Brandon Carlson <bcarlso@...> wrote:

Ron wrote:
> Do you actually use different numbers from these? Seems to me that
> the best story is a lot more than 3x the value of the worst.

We use 0-3 in our scheme, and don't currently worry about relative
value. I'm interested in everyone's thoughts about our scheme:

http://blog.projectconnections.com/project_practitioners/2008/09/story-prioritiz.html

Thanks!
Brandon

On Sat, Feb 28, 2009 at 6:19 AM, Ron Jeffries <ronjeffries@... <mailto:ronjeffries%40acm.org> > wrote:
> Hello, Drew. On Saturday, February 28, 2009, at 12:09:35 AM, you
> wrote:
>
>> If you want to measure the business value received by effort for a
>> sprint, there's a method I like. Let's say you have your stories
>> prioritized as High Value = 3, Medium Value = 2, and Low Value = 1.
>> You can then sum the values of the priorities and divide by the story
>> points delivered in a Sprint.
>
> Do you actually use different numbers from these? Seems to me that
> the best story is a lot more than 3x the value of the worst.
>
> Ron Jeffries
> www.XProgramming.com <http://www.XProgramming.com>
> www.xprogramming.com/blog <http://www.xprogramming.com/blog>
> Attend our CSM Plus Course!
> http://hendricksonxp.com/index.php?option=com_eventlist&Itemid=28
> The rules are ways of thinking, not ways to avoid thinking.
>
>

Your message has been successfully submitted and would be delivered to recipients shortly.
• Changes have not been saved
Press OK to abandon changes or Cancel to continue editing
• Your browser is not supported
Kindly note that Groups does not support 7.0 or earlier versions of Internet Explorer. We recommend upgrading to the latest Internet Explorer, Google Chrome, or Firefox. If you are using IE 9 or later, make sure you turn off Compatibility View.