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

Re: [scrumdevelopment] Re: User Story Maturity

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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.