Loading ...
Sorry, an error occurred while loading the content.

User Story Maturity

Expand Messages
  • Charles Bradley - Scrum Coach CSM PSM I
    Hi, I m working on a User Story Maturity Survey of sorts, and I d be interested on others thoughts. User Story Maturity Survey Points Practice 15* 3
    Message 1 of 11 , Mar 31, 2011
    • 0 Attachment
      Hi,

      I'm working on a User Story Maturity Survey of sorts, and I'd be interested on others' thoughts.

      User Story Maturity Survey
       
      Points    Practice      
      15* 3 Components/2 Must Haves (* Required)      
      15   PO 100% Allocated to the team as PO
      5     PO Co-located(Talking Distance)      
      10   Weekly Backlog Grooming
      10   Multiple Acceptance Testing Styles(4+)      
      5     Immediate Story Signoff(Within 1 day)      
      20   Small Stories (2-3 days for one person or a pair)      
      20   Acceptance Tests 90+% Automated      

      Score    User Story Maturity Level      
      25-39    Beginning Team      
      40-89    Intermediate Team      
      90+      Advanced Team     

      If you do the practice generally 90% of the time, then give yourself the points for that practice, otherwise don't give yourself any points for that practice (i.e. no partial credit).

      Some Explanation:

      -3 Components/2 Must Haves (* Required)      
      This means every User Story has the 3 required components. 
          i.e. at least a title, some associated conversations, and acceptance tests/examples defined in at least prose/text.
          aka the 3 C's: Card, Conversation, Confirmation
      This means that every User Story confirms with 2 Must Have characteristics:
          1.  The story provides direct value to a non dev team stakeholder (i.e. anyone who is not a dev on the team)
          2.  The story describes new or changed functionality in the system.

      This practice + 10 points garnered from elsewhere, is required to even be a beginning User Stories team.

      - Multiple Acceptance Testing Styles
           This means the team uses at least 4 styles of expressing acceptance tests.  This is simply the conceptual form of an acceptance test(i.e. not an automated test) -- some people call this "High Level Test Cases".

      Some Example Styles are:

      "Test that..."  ^1
      "Test with..."  ^1
      Specification By Example
      Given/When/Then
      Flowcharts
      Pictures of White boards
      Notes/Bullets on an index card

      ^1 from Mike Cohn's User Stories book

      Please let me know if you need further clarification of any of the practices.
       
      -------
      Charles Bradley, CSM, PSM I
      Experienced Scrum Coach
      My blog: http://scrumcrazy.wordpress.com/

    • scrumnl
      What my worries a bit are with such ratings of a practice is that people want to get the highest score, as in the more points we have the better we are doing.
      Message 2 of 11 , Mar 31, 2011
      • 0 Attachment
        What my worries a bit are with such ratings of a practice is that people want to get the highest score, as in the more points we have the better we are doing.

        Let's say they don't have a PO 100% allocated, but still are doing perfectly fine with the interaction with this person. Your test would tell them that that is 'wrong'.

        I don't believe that there is a single way of telling how people should do Scrum, whether they should do users stories and if they do user stories how to do them.

        I'm afraid your test, or any other test with scoring, will radiate the message that there is 'A Single Way To Do Things'. People over process.
      • Peter Stevens (calendar)
        Hi Charles, I tend to agree with Maurice that an assessment which focuses on a score can lead people to a) game the system or b) focus on someone else s best
        Message 3 of 11 , Mar 31, 2011
        • 0 Attachment
          Hi Charles,

          I tend to agree with Maurice that an assessment which focuses on a score can lead people to a) game the system or b) focus on someone else's "best practice" without really thinking about their own problems.

          Have you looked at Henrik Kniberg's Scrum Checklist? A total of some 40 questions, grouped and prioritized.  You answer each with yes or no. I've found it useful as a self-assessment - the questions are more talking points than a number you want to achieve.

          Cheers,
          Peter


          On 4/1/11 8:28 AM, scrumnl wrote:
           

          What my worries a bit are with such ratings of a practice is that people want to get the highest score, as in the more points we have the better we are doing.

          Let's say they don't have a PO 100% allocated, but still are doing perfectly fine with the interaction with this person. Your test would tell them that that is 'wrong'.

          I don't believe that there is a single way of telling how people should do Scrum, whether they should do users stories and if they do user stories how to do them.

          I'm afraid your test, or any other test with scoring, will radiate the message that there is 'A Single Way To Do Things'. People over process.


        • charles_bradley_scrum_coach
          I finally got around to writing an article on the User Story Maturity Model that I created: http://scrumcrazy.wikispaces.com/User+Story+Maturity+Model
          Message 4 of 11 , Apr 15, 2011
          • 0 Attachment
            I finally got around to writing an article on the User Story Maturity Model that I created:

            http://scrumcrazy.wikispaces.com/User+Story+Maturity+Model

            Comments/feedback welcome.

            -------
            Charles Bradley, CSM, PSM I
            Experienced Scrum Coach
            My blog: http://scrumcrazy.wordpress.com/

            --- In scrumdevelopment@yahoogroups.com, Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...> wrote:
            >
            > Hi,
            >
            > I'm working on a User Story Maturity Survey of sorts, and I'd be interested on
            > others' thoughts.
            >
            > User Story Maturity Survey
            >
            > Points Practice
            > 15* 3 Components/2 Must Haves (* Required)
          • charles_bradley_scrum_coach
            I m not terribly worried about people gaming the system. I put a note in the article related to poor faith or poorly executed attempts at the best practices.
            Message 5 of 11 , Apr 15, 2011
            • 0 Attachment
              I'm not terribly worried about people gaming the system. I put a note in the article related to poor faith or poorly executed attempts at the best practices.

              The problem I have with checklists in general is that they don't indicate how important a particular practice is, or the relative importance of one practice to another.

              I didn't see any notes about priority order in Henrik's checklist. While overall I think his checklist is a good thing, I have several issues with it that I don't care to discuss now. After seeing his checklist, I'm now toying with the idea of creating my own Scrum Maturity Model. Ponder on this, I will. :-)

              -------
              Charles Bradley, CSM, PSM I
              Experienced Scrum Coach
              My blog: http://scrumcrazy.wordpress.com/

              --- In scrumdevelopment@yahoogroups.com, "Peter Stevens (calendar)" <peterstev@...> wrote:
              >
              > Hi Charles,
              >
              > I tend to agree with Maurice that an assessment which focuses on a score
              > can lead people to a) game the system or b) focus on someone else's
              > "best practice" without really thinking about their own problems.
              >
              > Have you looked at Henrik Kniberg's Scrum Checklist? A total of some 40
              > questions, grouped and prioritized. You answer each with yes or no.
              > I've found it useful as a self-assessment - the questions are more
              > talking points than a number you want to achieve.
              >
              > Cheers,
              > Peter
              >
              >
            • charles_bradley_scrum_coach
              Maurice, ... Yes, I think you ve got the idea! I don t know about better we are doing so much as the more points we have, the more mature we are in the
              Message 6 of 11 , Apr 15, 2011
              • 0 Attachment
                Maurice,

                > What my worries a bit are with such ratings of a practice is that people want to get the highest score, as in the more points we have the better we are doing.

                Yes, I think you've got the idea! I don't know about "better we are doing" so much as "the more points we have, the more mature we are in the practice"

                > Let's say they don't have a PO 100% allocated, but still are doing perfectly fine with the interaction with this person. Your test would tell them that that is 'wrong'.

                I don't know that the model says they are "wrong", so much as it says they will never get to the expert level without having a PO be 100% allocated.

                > I'm afraid your test, or any other test with scoring, will radiate the message that there is 'A Single Way To Do Things'. People over process.

                If you're saying "people over process" to refer to this line in the Agile Manifesto:
                "Individuals and interactions over processes and tools"

                ...Then I believe the User Story practice values individuals and interactions over processes and tools. I think this model also reflects that.

                -------
                Charles Bradley, CSM, PSM I
                Experienced Scrum Coach
                My blog: http://scrumcrazy.wordpress.com/


                --- In scrumdevelopment@yahoogroups.com, "scrumnl" <maurice.lerutte@...> wrote:
                >
                > What my worries a bit are with such ratings of a practice is that people want to get the
              • Ron Jeffries
                Hello, charles_bradley_scrum_coach. On Friday, April 15, 2011, at ... Remember: you did ask. I have rather a few concerns with this. First, since the total
                Message 7 of 11 , Apr 15, 2011
                • 0 Attachment
                  Hello, charles_bradley_scrum_coach. On Friday, April 15, 2011, at
                  6:21:48 AM, you wrote:

                  > I finally got around to writing an article on the User Story Maturity Model that I created:
                  > http://scrumcrazy.wikispaces.com/User+Story+Maturity+Model

                  > Comments/feedback welcome.

                  Remember: you did ask. I have rather a few concerns with this.

                  First, since the total possible score is 100, if I've done the
                  arithmetic right, it suggests strongly that doing these things is
                  perfect. There is no perfect.

                  Then the topics that are present ...

                  Why are there two separate items on story size?

                  PO allocation and presence are important. However I'd rather have a
                  competent PO half time than an incompetent one all the time. This
                  measure doesn't address true PO effectiveness very well at all.

                  Story grooming is important. It is doubtful whether one or two hours
                  is anywhere near enough. Again, full credit for going part way?

                  I am aware of no evidence that a team needs to be able to put story
                  tests in multiple styles. Seems quite an odd measure.

                  Story size two to three team days? Pair days? Programmer days?

                  And the topics that are absent ...

                  Definition of done;
                  Readiness to ship;
                  Defect levels;
                  Story improvement;
                  Use of cost estimates;
                  Use of value estimates;
                  ...

                  And the fundamental concerns ...

                  Assigning a numeric score makes attaining a numeric score the
                  objective, especially since the total score happens to be 100. A
                  radar diagram or some other more holistic presentation would be far
                  better IMO.

                  No part of Agile is more creative and human than story writing. This
                  list seems to squeeze all the humanity out and leave very little
                  room for the true art of story writing.

                  Writing good stories and testing them isn't even the most important
                  thing in Scrum. Selecting which stories to do and getting them done
                  is the most important thing. A team with well-written
                  poorly-selected stories will be crushed by a team with well-selected
                  stories less well parsed out.

                  Bottom line ...

                  I think the /ideas/ here are good, although they are mostly
                  surface-level ideas, not digging deeply into the real issues.

                  I think the presentation of numeric scores is likely harmful.

                  I think the notion of "maturity" is also harmful, as it communicates
                  something quite different from the cooperative focus of Scrum.

                  Story competence is only one dimension of a complex dance.
                  Addressing it in isolation may not be a good idea.

                  Ron Jeffries
                  www.XProgramming.com
                  Ron Jeffries, speaking for Boskone ... Out.
                • Maurice le Rutte
                  User stories in itself may, but Thy Shalt Use User Stories In The Prescribed Way isn t. And that is the feeling I get when you describe scoring user stories
                  Message 8 of 11 , Apr 15, 2011
                  • 0 Attachment
                    User stories in itself may, but Thy Shalt Use User Stories In The Prescribed Way isn't. And that is the feeling I get when you describe 'scoring' user stories and talk about maturaty in applying them. People get to expert level because they are knowing what they are doing, why and how to apply it to their own situation, not by saying 'hey, if we do Story Practice X we'll be 27 points closer to maturity!".

                    Maybe I should check out your website first.

                    Maurice.

                    Op 15-4-2011 12:54, charles_bradley_scrum_coach schreef:
                     

                    Maurice,

                    > What my worries a bit are with such ratings of a practice is that people want to get the highest score, as in the more points we have the better we are doing.

                    Yes, I think you've got the idea! I don't know about "better we are doing" so much as "the more points we have, the more mature we are in the practice"

                    > Let's say they don't have a PO 100% allocated, but still are doing perfectly fine with the interaction with this person. Your test would tell them that that is 'wrong'.

                    I don't know that the model says they are "wrong", so much as it says they will never get to the expert level without having a PO be 100% allocated.

                    > I'm afraid your test, or any other test with scoring, will radiate the message that there is 'A Single Way To Do Things'. People over process.

                    If you're saying "people over process" to refer to this line in the Agile Manifesto:
                    "Individuals and interactions over processes and tools"

                    ...Then I believe the User Story practice values individuals and interactions over processes and tools. I think this model also reflects that.


                    --
                    http://www.scrummaster.nl / http://twitter.com/scrumnl
                  • Charles Bradley - Scrum Coach CSM PSM I
                    Ron, Thanks for the feedback, and I think you have some valid concerns and feedback. (Same goes to Peter and Maurice. I m sorry I didn t start off my previous
                    Message 9 of 11 , Apr 15, 2011
                    • 0 Attachment
                      Ron,

                      Thanks for the feedback, and I think you have some valid concerns and feedback.
                      (Same goes to Peter and Maurice.  I'm sorry I didn't start off my previous emails to you that way.  I should have.  My bad.)

                      1.  I'm totally open to changing the numbers.  I'll do that. 

                      2.  > Why are there two separate items on story size?
                      Well, I thought I halfway explained that in the practice descriptions at the bottom of the page. 
                      "This isn't really a best practice. It's a good practice that is a stepping stone to getting to the best practice(Stories 2-3 days in size). I include it here to demonstrate that this good practice is a good first goal in terms of keeping stories small."

                      Two other reasons for two separate items:
                      1.  In the book "Extreme Programming Installed" (Wrote in part by none other than Ron Jeffries), it says:
                        • "Each one[story] is simple enough that the programmers can understand it and can see how to implement it in a week or so."
                      2.  In my experiences coaching, teams usually come from a background where a feature(Use Case, etc) is something that takes about 20-60 developer days.  Thus, cutting down immediately to 2-3 day stories is very difficult.

                      Any suggestions for how to improve?

                      3.  > This measure doesn't address true PO effectiveness very well at all.
                      Good point.  I tried to cover this here
                      "Modeling is not an exact science. That's why it's called a "model." As such, the purpose of the model is to help teams assess and improve. In particular, any poor faith or poorly executed attempt at implementing a best practice could have bad consequences."
                      I added this statement as a result of feedback from Peter and Maurice.
                      Any suggestions for how to improve?

                      4.  > Story grooming is important. It is doubtful whether one or two hours is anywhere near enough. Again, full credit for going part way?
                      Hmmmm.  I don't have a good answer for this one yet.  I need to think on this one.  I want to make the point about dedicated story grooming, but I think I also need to stress the constant conversational interaction between the dev team and PO in the model somewhow.  Any suggestions?  Do you have any feedback on how much of a PO's day should be spent grooming stories for the next iteration?  Time spent working with developers on current stories being implemented?  I don't remember seeing much on this in your and Cohn's books.

                      5.  > I am aware of no evidence that a team needs to be able to put story tests in multiple styles. Seems quite an odd measure.
                      Good point, I need to think on this one.

                      6.  > Story size two to three team days? Pair days? Programmer days?
                      Oversight on my part, I'll fix.

                      7.  > And the topics that are absent ...
                      > Definition of done;
                      > Readiness to ship;
                      I don't remember seeing this as part of the User Story practice in your and Mike's literature.  These seem more like Scrum topics to me.

                      8. >Use of cost estimates;
                      >
                      Use of value estimates;
                      Are you talking about Story Points and Value Points here?

                      8.  > Defect levels;
                      Can you point me to some User Story literature that talks about this?  I don't remember seeing much.  I think Mike Cohn speaks of batching a bunch of bugs together as a User Story.

                      9.  >Story improvement;
                      Not sure what you mean here

                      I'll try and cover the "fundamental concerns" at a later time.

                      -------
                      Charles Bradley, CSM, PSM I
                      Experienced Scrum Coach
                      My blog: http://scrumcrazy.wordpress.com/



                      From: Ron Jeffries <ronjeffries@...>
                      To: scrumdevelopment@yahoogroups.com
                      Sent: Fri, April 15, 2011 8:29:04 AM
                      Subject: Re: [scrumdevelopment] Re: User Story Maturity

                      Hello, charles_bradley_scrum_coach.  On Friday, April 15, 2011, at
                      6:21:48 AM, you wrote:

                      > I finally got around to writing an article on the User Story Maturity Model that I created:
                      > http://scrumcrazy.wikispaces.com/User+Story+Maturity+Model

                      > Comments/feedback welcome.

                      Remember: you did ask. I have rather a few concerns with this.

                      First, since the total possible score is 100, if I've done the
                      arithmetic right, it suggests strongly that doing these things is
                      perfect. There is no perfect.

                      Then the topics that are present ...

                      Why are there two separate items on story size?

                      PO allocation and presence are important. However I'd rather have a
                      competent PO half time than an incompetent one all the time. This
                      measure doesn't address true PO effectiveness very well at all.

                      Story grooming is important. It is doubtful whether one or two hours
                      is anywhere near enough. Again, full credit for going part way?

                      I am aware of no evidence that a team needs to be able to put story
                      tests in multiple styles. Seems quite an odd measure.

                      Story size two to three team days? Pair days? Programmer days?

                      And the topics that are absent ...

                      Definition of done;
                      Readiness to ship;
                      Defect levels;
                      Story improvement;
                      Use of cost estimates;
                      Use of value estimates;
                      ...

                      And the fundamental concerns ...

                      Assigning a numeric score makes attaining a numeric score the
                      objective, especially since the total score happens to be 100. A
                      radar diagram or some other more holistic presentation would be far
                      better IMO.

                      No part of Agile is more creative and human than story writing. This
                      list seems to squeeze all the humanity out and leave very little
                      room for the true art of story writing.

                      Writing good stories and testing them isn't even the most important
                      thing in Scrum. Selecting which stories to do and getting them done
                      is the most important thing. A team with well-written
                      poorly-selected stories will be crushed by a team with well-selected
                      stories less well parsed out.

                      Bottom line ...

                      I think the /ideas/ here are good, although they are mostly
                      surface-level ideas, not digging deeply into the real issues.

                      I think the presentation of numeric scores is likely harmful.

                      I think the notion of "maturity" is also harmful, as it communicates
                      something quite different from the cooperative focus of Scrum.

                      Story competence is only one dimension of a complex dance.
                      Addressing it in isolation may not be a good idea.

                      Ron Jeffries
                      www.XProgramming.com
                      Ron Jeffries, speaking for Boskone ... Out.



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

                      To Post a message, send it to:  scrumdevelopment@...
                      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

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

                      <*> Your email settings:
                          Individual Email | Traditional

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

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

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

                      <*> Your use of Yahoo! Groups is subject to:
                          http://docs.yahoo.com/info/terms/

                    • Charles Bradley - Scrum Coach CSM PSM I
                      There s always a risk that someone will misuse the tool, I agree. Maybe more disclaimers on my part are in order. ... Charles Bradley, CSM, PSM I Experienced
                      Message 10 of 11 , Apr 15, 2011
                      • 0 Attachment
                        There's always a risk that someone will misuse the tool, I agree.  Maybe more disclaimers on my part are in order.
                         
                        -------
                        Charles Bradley, CSM, PSM I
                        Experienced Scrum Coach
                        My blog: http://scrumcrazy.wordpress.com/



                        From: Maurice le Rutte <maurice.lerutte@...>
                        To: scrumdevelopment@yahoogroups.com
                        Sent: Fri, April 15, 2011 10:47:23 AM
                        Subject: Re: [scrumdevelopment] Re: User Story Maturity



                        User stories in itself may, but Thy Shalt Use User Stories In The Prescribed Way isn't. And that is the feeling I get when you describe 'scoring' user stories and talk about maturaty in applying them. People get to expert level because they are knowing what they are doing, why and how to apply it to their own situation, not by saying 'hey, if we do Story Practice X we'll be 27 points closer to maturity!".

                        Maybe I should check out your website first.

                        Maurice.

                        Op 15-4-2011 12:54, charles_bradley_scrum_coach schreef:
                         

                        Maurice,

                        > What my worries a bit are with such ratings of a practice is that people want to get the highest score, as in the more points we have the better we are doing.

                        Yes, I think you've got the idea! I don't know about "better we are doing" so much as "the more points we have, the more mature we are in the practice"

                        > Let's say they don't have a PO 100% allocated, but still are doing perfectly fine with the interaction with this person. Your test would tell them that that is 'wrong'.

                        I don't know that the model says they are "wrong", so much as it says they will never get to the expert level without having a PO be 100% allocated.

                        > I'm afraid your test, or any other test with scoring, will radiate the message that there is 'A Single Way To Do Things'. People over process.

                        If you're saying "people over process" to refer to this line in the Agile Manifesto:
                        "Individuals and interactions over processes and tools"

                        ...Then I believe the User Story practice values individuals and interactions over processes and tools. I think this model also reflects that.


                        --
                        http://www.scrummaster.nl / http://twitter.com/scrumnl


                      • Charles Bradley - Scrum Coach CSM PSM I
                        I ve posted a new draft revision to my User Story Maturity model here: http://scrumcrazy.wikispaces.com/scratch Major changes highlighted in yellow.
                        Message 11 of 11 , Apr 18, 2011
                        • 0 Attachment
                          I've posted a new draft revision to my User Story Maturity model here:
                          http://scrumcrazy.wikispaces.com/scratch

                          Major changes highlighted in yellow.

                          Specifically trying to address most of the concerns(1, 3, 4, 5, 6) below.

                          Any and all feedback encouraged!  (See that, Ron?  encouraged!  Fire away!)
                           
                          -------
                          Charles Bradley, CSM, PSM I
                          Experienced Scrum Coach
                          My blog: http://scrumcrazy.wordpress.com/



                          From: Charles Bradley - Scrum Coach CSM PSM I <chuck-lists2@...>
                          To: scrumdevelopment@yahoogroups.com
                          Sent: Fri, April 15, 2011 11:44:02 AM
                          Subject: Re: [scrumdevelopment] Re: User Story Maturity



                          Ron,

                          Thanks for the feedback, and I think you have some valid concerns and feedback.
                          (Same goes to Peter and Maurice.  I'm sorry I didn't start off my previous emails to you that way.  I should have.  My bad.)

                          1.  I'm totally open to changing the numbers.  I'll do that. 

                          2.  > Why are there two separate items on story size?
                          Well, I thought I halfway explained that in the practice descriptions at the bottom of the page. 
                          "This isn't really a best practice. It's a good practice that is a stepping stone to getting to the best practice(Stories 2-3 days in size). I include it here to demonstrate that this good practice is a good first goal in terms of keeping stories small."

                          Two other reasons for two separate items:
                          1.  In the book "Extreme Programming Installed" (Wrote in part by none other than Ron Jeffries), it says:
                            • "Each one[story] is simple enough that the programmers can understand it and can see how to implement it in a week or so."
                          2.  In my experiences coaching, teams usually come from a background where a feature(Use Case, etc) is something that takes about 20-60 developer days.  Thus, cutting down immediately to 2-3 day stories is very difficult.

                          Any suggestions for how to improve?

                          3.  > This measure doesn't address true PO effectiveness very well at all.
                          Good point.  I tried to cover this here
                          "Modeling is not an exact science. That's why it's called a "model." As such, the purpose of the model is to help teams assess and improve. In particular, any poor faith or poorly executed attempt at implementing a best practice could have bad consequences."
                          I added this statement as a result of feedback from Peter and Maurice.
                          Any suggestions for how to improve?

                          4.  > Story grooming is important. It is doubtful whether one or two hours is anywhere near enough. Again, full credit for going part way?
                          Hmmmm.  I don't have a good answer for this one yet.  I need to think on this one.  I want to make the point about dedicated story grooming, but I think I also need to stress the constant conversational interaction between the dev team and PO in the model somewhow.  Any suggestions?  Do you have any feedback on how much of a PO's day should be spent grooming stories for the next iteration?  Time spent working with developers on current stories being implemented?  I don't remember seeing much on this in your and Cohn's books.

                          5.  > I am aware of no evidence that a team needs to be able to put story tests in multiple styles. Seems quite an odd measure.
                          Good point, I need to think on this one.

                          6.  > Story size two to three team days? Pair days? Programmer days?
                          Oversight on my part, I'll fix.

                          7.  > And the topics that are absent ...
                          > Definition of done;
                          > Readiness to ship;
                          I don't remember seeing this as part of the User Story practice in your and Mike's literature.  These seem more like Scrum topics to me.

                          8. >Use of cost estimates;
                          >
                          Use of value estimates;
                          Are you talking about Story Points and Value Points here?

                          8.  > Defect levels;
                          Can you point me to some User Story literature that talks about this?  I don't remember seeing much.  I think Mike Cohn speaks of batching a bunch of bugs together as a User Story.

                          9.  >Story improvement;
                          Not sure what you mean here

                          I'll try and cover the "fundamental concerns" at a later time.

                          -------
                          Charles Bradley, CSM, PSM I
                          Experienced Scrum Coach
                          My blog: http://scrumcrazy.wordpress.com/



                        Your message has been successfully submitted and would be delivered to recipients shortly.