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

estimating user stories or use cases?

Expand Messages
  • Watson, Robert C
    I ve just gotten back from Ken s seminar and am now attempting to introduce it to my team. There are several issues I d like to ask about:1) Our
    Message 1 of 5 , Feb 1, 2008
    • 0 Attachment

      I’ve just gotten back from Ken’s seminar and am now attempting to introduce it to my team.  There are several issues I’d like to ask about:

       

      1)       Our immediate task is estimation of user stories, but:

      a.       we have a limited team of 3 technology savvy individuals who won’t necessarily be the implementers of the user stories (vendors are coming on for that, but later)

      b.      the 3 team members don’t feel the user stories are “fleshed out” enough to estimate, even in spite of my training them on planning poker and the idea that estimating and prioritizing user stories is an incremental approach and not meant to be the final estimate. 

      c.       they still want to write full-blown use cases and estimate those using planning poker.  Is that going to cause any problems?

      2)       The team members are not used to the “self-managed teams” approach to development.  As a consequence, I feel that I need to take on too much of a command-and-control role when my intention is just to train them on the principles of self-managed teams and then observe and advise (as well as help the team with the mountain of work).  What transition techniques have any of you found successful in switching over from the top-down management to the self-managed team?  Is it appropriate for the Scrummaster to actually do some of the work? 

       

      (Sorry, I know, RTFM and RTFAQ, but I’m hoping for forgiveness just this once and to get real-world perspective vs. “running to the prescriptive process”).

       

      Thanks.

       

      Rob Watson  |  Manager, Midwest Technology Development Center  |  Curriculum Group  |  Pearson  |  Office - (847) 486-2621  |  Mobile - (847) 321-0289

       

      ***********************************************************************
      This email may contain confidential material. 
      If you were not an intended recipient, 
      please notify the sender and delete all copies. 
      We may monitor email to and from our network. 
      
      ***********************************************************************
    • Nicholas Cancelliere
      1) The people who will be doing the work should be estimating the stories ... not someone else. (So have your vendors estimate them.) 2) If your team isn t
      Message 2 of 5 , Feb 1, 2008
      • 0 Attachment

        1) The people who will be doing the work should be estimating the stories ... not someone else.  (So have your vendors estimate them.)

        2) If your team isn't doing the work (eg because the vendor is) I don't see how they can estimate it.

        I am a little worried about your approach, as it sounds like command and control.  I worry about the idea that you're having individuals (regardless how savvy they are) doing estimates for work being done by other individuals.  This doesn't feel like a good practice to me and not one that I encourage with my own Scrum implementations.

        You want to have the people doing the work be the ones estimating and committing to the work.  This means you will need to include the vendor's folks on your own team, as integrated team members.  Then do group estimation using planning poker on story items, get gross and detailed estimates on the backlog, let the team then commit to work they feel they can accomplish sprint by sprint, etc.

        You can't have a self-directing, self-organizing team unless they are the ones committed to the sprint goal, one of their own making.  Else you're taking some responsibility away from them, and the more you do that the more you're being C&C.

        Nicholas


        On Feb 1, 2008, at 9:22 AM, Watson, Robert C wrote:

        I’ve just gotten back from Ken’s seminar and am now attempting to introduce it to my team.  There are several issues I’d like to ask about:
         
        1)       Our immediate task is estimation of user stories, but:
        a.       we have a limited team of 3 technology savvy individuals who won’t necessarily be the implementers of the user stories (vendors are coming on for that, but later)
        b.      the 3 team members don’t feel the user stories are “fleshed out” enough to estimate, even in spite of my training them on planning poker and the idea that estimating and prioritizing user stories is an incremental approach and not meant to be the final estimate. 
        c.       they still want to write full-blown use cases and estimate those using planning poker.  Is that going to cause any problems?
        2)       The team members are not used to the “self-managed teams” approach to development.  As a consequence, I feel that I need to take on too much of a command-and-control role when my intention is just to train them on the principles of self-managed teams and then observe and advise (as well as help the team with the mountain of work).  What transition techniques have any of you found successful in switching over from the top-down management to the self-managed team?  Is it appropriate for the Scrummaster to actually do some of the work? 
         
        (Sorry, I know, RTFM and RTFAQ, but I’m hoping for forgiveness just this once and to get real-world perspective vs. “running to the prescriptive process”).
         
        Thanks.
         
        Rob Watson  |  Manager, Midwest Technology Development Center  |  Curriculum Group  |  Pearson  |  Office - (847) 486-2621  |  Mobile - (847) 321-0289
         
        ***********************************************************************
        This email may contain confidential material. 
        If you were not an intended recipient, 
        please notify the sender and delete all copies. 
        We may monitor email to and from our network. 
        
        ***********************************************************************
        
        


        --
        Nicholas Cancelliere, CSM/CSP
        Austin, TX 

        Certified Scrum Practitioner
        Certified Scrum Master

        Over 10 years of web application development experience and an Agile nut!

      • proud2b4family
        I agree that those not doing the work should not be estimating the work. Thanks for the clarification. This is one of those projects where estimates are
        Message 3 of 5 , Feb 1, 2008
        • 0 Attachment
          I agree that those not doing the work should not be estimating the
          work. Thanks for the clarification. This is one of those projects
          where estimates are being asked for in advance of the vendors coming
          on board because we have such short turnaround time and we need
          answers as to the schedule start and end dates. I'll have to find
          some other way to deal with that matter. Does Scrum say what to do
          when product owners have gone completely nuts? ;)

          --- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere
          <nickaustin74@...> wrote:
          >
          >
          > 1) The people who will be doing the work should be estimating the
          > stories ... not someone else. (So have your vendors estimate them.)
          >
          > 2) If your team isn't doing the work (eg because the vendor is) I
          > don't see how they can estimate it.
          >
          > I am a little worried about your approach, as it sounds like command
          > and control. I worry about the idea that you're having individuals
          > (regardless how savvy they are) doing estimates for work being done by
          > other individuals. This doesn't feel like a good practice to me and
          > not one that I encourage with my own Scrum implementations.
          >
          > You want to have the people doing the work be the ones estimating and
          > committing to the work. This means you will need to include the
          > vendor's folks on your own team, as integrated team members. Then do
          > group estimation using planning poker on story items, get gross and
          > detailed estimates on the backlog, let the team then commit to work
          > they feel they can accomplish sprint by sprint, etc.
          >
          > You can't have a self-directing, self-organizing team unless they are
          > the ones committed to the sprint goal, one of their own making. Else
          > you're taking some responsibility away from them, and the more you do
          > that the more you're being C&C.
          >
          > Nicholas
          >
          >
          > On Feb 1, 2008, at 9:22 AM, Watson, Robert C wrote:
          >
          > > I've just gotten back from Ken's seminar and am now attempting to
          > > introduce it to my team. There are several issues I'd like to ask
          > > about:
          > >
          > > 1) Our immediate task is estimation of user stories, but:
          > > a. we have a limited team of 3 technology savvy individuals
          > > who won't necessarily be the implementers of the user stories
          > > (vendors are coming on for that, but later)
          > > b. the 3 team members don't feel the user stories are "fleshed
          > > out" enough to estimate, even in spite of my training them on
          > > planning poker and the idea that estimating and prioritizing user
          > > stories is an incremental approach and not meant to be the final
          > > estimate.
          > > c. they still want to write full-blown use cases and estimate
          > > those using planning poker. Is that going to cause any problems?
          > > 2) The team members are not used to the "self-managed teams"
          > > approach to development. As a consequence, I feel that I need to
          > > take on too much of a command-and-control role when my intention is
          > > just to train them on the principles of self-managed teams and then
          > > observe and advise (as well as help the team with the mountain of
          > > work). What transition techniques have any of you found successful
          > > in switching over from the top-down management to the self-managed
          > > team? Is it appropriate for the Scrummaster to actually do some of
          > > the work?
          > >
          > > (Sorry, I know, RTFM and RTFAQ, but I'm hoping for forgiveness just
          > > this once and to get real-world perspective vs. "running to the
          > > prescriptive process").
          > >
          > > Thanks.
          > >
          > > Rob Watson | Manager, Midwest Technology Development Center |
          > > Curriculum Group | Pearson | Office - (847) 486-2621 | Mobile
          > > - (847) 321-0289
          > >
          > >
          > >
          ***********************************************************************
          > > This email may contain confidential material.
          > > If you were not an intended recipient,
          > > please notify the sender and delete all copies.
          > > We may monitor email to and from our network.
          > >
          > >
          ***********************************************************************
          > >
          > >
          >
          > --
          > Nicholas Cancelliere, CSM/CSP
          > Austin, TX
          >
          > Certified Scrum Practitioner
          > Certified Scrum Master
          >
          > Over 10 years of web application development experience and an Agile
          > nut!
          >
        • Nicholas Cancelliere
          It sounds like a standard plan for failure type of project. I hear the scenario all too often. So is it that you need to estimate the work and then decide
          Message 4 of 5 , Feb 1, 2008
          • 0 Attachment

            It sounds like a standard "plan for failure" type of project.  I hear the scenario all too often.  So is it that you need to estimate the work and then decide from the "vendor" how many resources you need to hire to get it out the door by X date?  Or is it that if the advanced estimates come out to be no-doable the entire project is going to be scrapped?  

            I guess I would need to understand why the dates are so critical.

            In any regards - having your team estimate work that the vendors will be doing, that seems like an issue.   Does your product owner understand his role in the project?  Is there a backlog developed in priority order?

            Nicholas


            On Feb 1, 2008, at 1:46 PM, proud2b4family wrote:

            I agree that those not doing the work should not be estimating the
            work.  Thanks for the clarification.  This is one of those projects
            where estimates are being asked for in advance of the vendors coming
            on board because we have such short turnaround time and we need
            answers as to the schedule start and end dates.  I'll have to find
            some other way to deal with that matter.  Does Scrum say what to do
            when product owners have gone completely nuts? ;)

            --- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere
            <nickaustin74@...> wrote:


            1) The people who will be doing the work should be estimating the  
            stories ... not someone else.  (So have your vendors estimate them.)

            2) If your team isn't doing the work (eg because the vendor is) I  
            don't see how they can estimate it.

            I am a little worried about your approach, as it sounds like command  
            and control.  I worry about the idea that you're having individuals  
            (regardless how savvy they are) doing estimates for work being done by  
            other individuals.  This doesn't feel like a good practice to me and  
            not one that I encourage with my own Scrum implementations.

            You want to have the people doing the work be the ones estimating and  
            committing to the work.  This means you will need to include the  
            vendor's folks on your own team, as integrated team members.  Then do  
            group estimation using planning poker on story items, get gross and  
            detailed estimates on the backlog, let the team then commit to work  
            they feel they can accomplish sprint by sprint, etc.

            You can't have a self-directing, self-organizing team unless they are  
            the ones committed to the sprint goal, one of their own making.  Else  
            you're taking some responsibility away from them, and the more you do  
            that the more you're being C&C.

            Nicholas


            On Feb 1, 2008, at 9:22 AM, Watson, Robert C wrote:

            I've just gotten back from Ken's seminar and am now attempting to  
            introduce it to my team.  There are several issues I'd like to ask  
            about:

            1)       Our immediate task is estimation of user stories, but:
            a.       we have a limited team of 3 technology savvy individuals  
            who won't necessarily be the implementers of the user stories  
            (vendors are coming on for that, but later)
            b.      the 3 team members don't feel the user stories are "fleshed  
            out" enough to estimate, even in spite of my training them on  
            planning poker and the idea that estimating and prioritizing user  
            stories is an incremental approach and not meant to be the final  
            estimate.
            c.       they still want to write full-blown use cases and estimate  
            those using planning poker.  Is that going to cause any problems?
            2)       The team members are not used to the "self-managed teams"  
            approach to development.  As a consequence, I feel that I need to  
            take on too much of a command-and-control role when my intention is  
            just to train them on the principles of self-managed teams and then  
            observe and advise (as well as help the team with the mountain of  
            work).  What transition techniques have any of you found successful  
            in switching over from the top-down management to the self-managed  
            team?  Is it appropriate for the Scrummaster to actually do some of  
            the work?

            (Sorry, I know, RTFM and RTFAQ, but I'm hoping for forgiveness just  
            this once and to get real-world perspective vs. "running to the  
            prescriptive process").

            Thanks.

            Rob Watson  |  Manager, Midwest Technology Development Center  |   
            Curriculum Group  |  Pearson  |  Office - (847) 486-2621  |  Mobile  
            - (847) 321-0289



            ***********************************************************************
            This email may contain confidential material.
            If you were not an intended recipient,
            please notify the sender and delete all copies.
            We may monitor email to and from our network.


            ***********************************************************************



            --
            Nicholas Cancelliere, CSM/CSP
            Austin, TX

            Certified Scrum Practitioner
            Certified Scrum Master

            Over 10 years of web application development experience and an Agile  
            nut!





            To Post a message, send it to:   scrumdevelopment@...
            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
            Yahoo! 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:
               mailto:scrumdevelopment-digest@yahoogroups.com
               mailto: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/


            --
            Nicholas Cancelliere
            Austin, TX




          • kawilawib
            To be fair, the product owner only heard of Agile/Scrum about the time I was taking the training. The other folks I m working with vary between not knowing
            Message 5 of 5 , Feb 1, 2008
            • 0 Attachment
              To be fair, the product owner only heard of Agile/Scrum about the time
              I was taking the training. The other folks I'm working with vary
              between not knowing anything about it to knowing about it from what
              they read on agilealliance and other sources. It's not really been
              implemented the way it should within our part of the organization.

              I'm really trying to shoehorn Scrum into something that was already
              well underway by the time I came along with my newly minted CSM
              certificate. Therefore, it's going to take a bit of churn to get
              everyone to understand Scrum and agree to use it in ways that will
              benefit the project.

              If you have tips for how to turn a non-Scrum project into a Scrum
              project, I'd be grateful.

              Thanks again for the advice and guidance.

              --- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere
              <nickaustin74@...> wrote:
              >
              >
              > It sounds like a standard "plan for failure" type of project. I hear
              > the scenario all too often. So is it that you need to estimate the
              > work and then decide from the "vendor" how many resources you need to
              > hire to get it out the door by X date? Or is it that if the advanced
              > estimates come out to be no-doable the entire project is going to be
              > scrapped?
              >
              > I guess I would need to understand why the dates are so critical.
              >
              > In any regards - having your team estimate work that the vendors will
              > be doing, that seems like an issue. Does your product owner
              > understand his role in the project? Is there a backlog developed in
              > priority order?
              >
              > Nicholas
              >
              >
              > On Feb 1, 2008, at 1:46 PM, proud2b4family wrote:
              >
              > > I agree that those not doing the work should not be estimating the
              > > work. Thanks for the clarification. This is one of those projects
              > > where estimates are being asked for in advance of the vendors coming
              > > on board because we have such short turnaround time and we need
              > > answers as to the schedule start and end dates. I'll have to find
              > > some other way to deal with that matter. Does Scrum say what to do
              > > when product owners have gone completely nuts? ;)
              > >
              > > --- In scrumdevelopment@yahoogroups.com, Nicholas Cancelliere
              > > <nickaustin74@> wrote:
              > >>
              > >>
              > >> 1) The people who will be doing the work should be estimating the
              > >> stories ... not someone else. (So have your vendors estimate them.)
              > >>
              > >> 2) If your team isn't doing the work (eg because the vendor is) I
              > >> don't see how they can estimate it.
              > >>
              > >> I am a little worried about your approach, as it sounds like command
              > >> and control. I worry about the idea that you're having individuals
              > >> (regardless how savvy they are) doing estimates for work being done
              > >> by
              > >> other individuals. This doesn't feel like a good practice to me and
              > >> not one that I encourage with my own Scrum implementations.
              > >>
              > >> You want to have the people doing the work be the ones estimating and
              > >> committing to the work. This means you will need to include the
              > >> vendor's folks on your own team, as integrated team members. Then do
              > >> group estimation using planning poker on story items, get gross and
              > >> detailed estimates on the backlog, let the team then commit to work
              > >> they feel they can accomplish sprint by sprint, etc.
              > >>
              > >> You can't have a self-directing, self-organizing team unless they are
              > >> the ones committed to the sprint goal, one of their own making. Else
              > >> you're taking some responsibility away from them, and the more you do
              > >> that the more you're being C&C.
              > >>
              > >> Nicholas
              > >>
              > >>
              > >> On Feb 1, 2008, at 9:22 AM, proud2b4family wrote:
              > >>
              > >>> I've just gotten back from Ken's seminar and am now attempting to
              > >>> introduce it to my team. There are several issues I'd like to ask
              > >>> about:
              > >>>
              > >>> 1) Our immediate task is estimation of user stories, but:
              > >>> a. we have a limited team of 3 technology savvy individuals
              > >>> who won't necessarily be the implementers of the user stories
              > >>> (vendors are coming on for that, but later)
              > >>> b. the 3 team members don't feel the user stories are "fleshed
              > >>> out" enough to estimate, even in spite of my training them on
              > >>> planning poker and the idea that estimating and prioritizing user
              > >>> stories is an incremental approach and not meant to be the final
              > >>> estimate.
              > >>> c. they still want to write full-blown use cases and estimate
              > >>> those using planning poker. Is that going to cause any problems?
              > >>> 2) The team members are not used to the "self-managed teams"
              > >>> approach to development. As a consequence, I feel that I need to
              > >>> take on too much of a command-and-control role when my intention is
              > >>> just to train them on the principles of self-managed teams and then
              > >>> observe and advise (as well as help the team with the mountain of
              > >>> work). What transition techniques have any of you found successful
              > >>> in switching over from the top-down management to the self-managed
              > >>> team? Is it appropriate for the Scrummaster to actually do some of
              > >>> the work?
              > >>>
              > >>> (Sorry, I know, RTFM and RTFAQ, but I'm hoping for forgiveness just
              > >>> this once and to get real-world perspective vs. "running to the
              > >>> prescriptive process").
              > >>>
              > >>> Thanks.
              > >>>
              > >>>
              > >>
              > >> --
              > >> Nicholas Cancelliere, CSM/CSP
              > >> Austin, TX
              > >>
              > >> Certified Scrum Practitioner
              > >> Certified Scrum Master
              > >>
              > >> Over 10 years of web application development experience and an Agile
              > >> nut!
              > >>
              > >
              > >
              > >
              > >
              > > To Post a message, send it to: scrumdevelopment@...
              > > To Unsubscribe, send a blank message to:
              scrumdevelopment-unsubscribe@...
              > > Yahoo! Groups Links
              > >
              > >
              > >
              >
              > --
              > Nicholas Cancelliere
              > Austin, TX
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.