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

Spike stories - estimation and acceptance criteria ?

Expand Messages
  • Ram Srinivasan
    Hello Folks, My understanding is that there are 2 types of spikes - technical and functional. And that spike stories need not have an estimate (as they are
    Message 1 of 17 , Aug 23, 2013
    • 0 Attachment
      Hello Folks,

      My understanding is that there are 2 types of spikes - technical and functional.  And that spike stories need not have an estimate (as they are time boxed to 1-2 days), and cannot be estimated (in story points), because it is research work, if we know what to do, we would build the feature and not do a spike.  Is my understanding correct? 

      Does Ron's 3Cs (Card, Confirmation, Conversation) apply to spike stories as well? Common sense tells me yes, and there is no harm. The acceptance criteria  for a technical spike may be something like  "the DB should be able to support 500K transactions without locking tables". Sometimes it may not be possible to have acceptance criteria, its research work, you are investigating it. I was looking at c2.com and xp123.com, but I could not find relevant material which could confirm my understanding

      Thanks,
      Ram



    • Pierre Neis
      *Estimating Spikes without COAs is the solution that I use to apply!* COAs for Spike doesn t really makes sense, Spikes are mainly linked to research
      Message 2 of 17 , Aug 24, 2013
      • 0 Attachment
        Estimating Spikes without COAs is the solution that I use to apply!

        COAs for Spike doesn't really makes sense, Spikes are mainly linked to research activities.

        Regarding estimation it's a bit more tricky:
        - estimate a spike makes in an engineering POV no sense
        - what happens if you/your team consumes 50% of capacity/time on Spikes during a Sprint?

        I like to introduce Spike estimation as a team discussion. The outcome of this is mainly a better understanding at team level and in the meantime the scrum master can grab some additional Story points for burndown and (s)he document it as decreasing TechDebt (or TechDebt in depends how you use this term).

         Results: reduced debate with management at Review, increased knowledge sharing helps estimation


        Kind regards, cordialement, mit freundlichen Grüssen,

        Pierre E. Neis, psm, cspo, csp 
        Scrum/Lean Coach - Scrum Master @ Lumension Security



        19 place Bleech |L-7610 Larochette | Luxembourg
        M: +352 661 727 867

        email:  pierre.neis@...
        web:    http://wecompany.wordpress.com/ http://thescrumcoach.wordpress.com/
        Meet with mehttp://meetwith.me/pierreneis
         

        about.me LinkedIn
        Contact me: Skype pierre.neis


        On 24 August 2013 03:02, Ram Srinivasan <vasan.ram@...> wrote:
        Hello Folks,

        My understanding is that there are 2 types of spikes - technical and functional.  And that spike stories need not have an estimate (as they are time boxed to 1-2 days), and cannot be estimated (in story points), because it is research work, if we know what to do, we would build the feature and not do a spike.  Is my understanding correct? 

        Does Ron's 3Cs (Card, Confirmation, Conversation) apply to spike stories as well? Common sense tells me yes, and there is no harm. The acceptance criteria  for a technical spike may be something like  "the DB should be able to support 500K transactions without locking tables". Sometimes it may not be possible to have acceptance criteria, its research work, you are investigating it. I was looking at c2.com and xp123.com, but I could not find relevant material which could confirm my understanding

        Thanks,
        Ram



        --
        You received this message because you are subscribed to the Google Groups "Scrum Alliance - transforming the world of work." group.
        To unsubscribe from this group and stop receiving emails from it, send an email to scrumalliance+unsubscribe@....
        To post to this group, send email to scrumalliance@....
        Visit this group at http://groups.google.com/group/scrumalliance.
        For more options, visit https://groups.google.com/groups/opt_out.

      • srinivas chillara
        Your understanding is correct. A slightly different perspective: We needn t worry to make each and every PBI a story ; So a spike is all right, w/o
        Message 3 of 17 , Aug 27, 2013
        • 0 Attachment
          Your understanding is correct. A slightly different perspective:
          We needn't worry to make each and every PBI a "story";
          So a spike is all right, w/o gerrymandering the boundaries of "user stories".

          cheers
          Srinivas



          From: Ram Srinivasan <vasan.ram@...>
          To: "extremeprogramming@yahoogroups.com" <extremeprogramming@yahoogroups.com>; "scrumalliance@..." <scrumalliance@...>; "scrumdevelopment@yahoogroups.com" <scrumdevelopment@yahoogroups.com>; "leanagile@yahoogroups.com" <leanagile@yahoogroups.com>
          Sent: Saturday, 24 August 2013 6:32 AM
          Subject: [scrumdevelopment] Spike stories - estimation and acceptance criteria ?

           
          Hello Folks,

          My understanding is that there are 2 types of spikes - technical and functional.  And that spike stories need not have an estimate (as they are time boxed to 1-2 days), and cannot be estimated (in story points), because it is research work, if we know what to do, we would build the feature and not do a spike.  Is my understanding correct? 

          Does Ron's 3Cs (Card, Confirmation, Conversation) apply to spike stories as well? Common sense tells me yes, and there is no harm. The acceptance criteria  for a technical spike may be something like  "the DB should be able to support 500K transactions without locking tables". Sometimes it may not be possible to have acceptance criteria, its research work, you are investigating it. I was looking at c2.com and xp123.com, but I could not find relevant material which could confirm my understanding

          Thanks,
          Ram





        • Ron Jeffries
          Srinivas, ... On the contrary. The Product Owner represents the business. The product owner is responsible for the project s successfully maximizing ROI. The
          Message 4 of 17 , Aug 27, 2013
          • 0 Attachment
            Srinivas,

            On Aug 27, 2013, at 10:33 PM, srinivas chillara <ceezone@...> wrote:

            Your understanding is correct. A slightly different perspective:
            We needn't worry to make each and every PBI a "story";
            So a spike is all right, w/o gerrymandering the boundaries of "user stories".

            On the contrary. The Product Owner represents the business. The product owner is responsible for the project's successfully maximizing ROI. The Product Owner defines and chooses the work to be done. Therefore the Product Owner must understand the work to be done, in terms that enable him or her to choose for maximum ROI.

            Any Backlog Item that the PO does not understand is a weakness, because it takes away from the PO being able to perform responsibly. Therefore, every Backlog Item should be expressed in terms that make business sense to the PO. Therefore, every Backlog Item can be expressed as a user story, and should be.
            Don't ignore your dreams; don't work too much; say what you think; cultivate friendships; be happy. -- Paul Graham

          • srinivas chillara
            POs can (and should) understand items that are not written as user stories as well. cheers Srinivas ________________________________ From: Ron Jeffries
            Message 5 of 17 , Aug 27, 2013
            • 0 Attachment
              POs can (and should) understand items that are not written as user stories as well.
              cheers
              Srinivas




              From: Ron Jeffries <ronjeffries@...>
              To: scrumdevelopment@yahoogroups.com
              Sent: Wednesday, 28 August 2013 8:20 AM
              Subject: Re: [scrumdevelopment] Spike stories - estimation and acceptance criteria ?

               
              Srinivas,

              On Aug 27, 2013, at 10:33 PM, srinivas chillara <ceezone@...> wrote:

              Your understanding is correct. A slightly different perspective:
              We needn't worry to make each and every PBI a "story";
              So a spike is all right, w/o gerrymandering the boundaries of "user stories".

              On the contrary. The Product Owner represents the business. The product owner is responsible for the project's successfully maximizing ROI. The Product Owner defines and chooses the work to be done. Therefore the Product Owner must understand the work to be done, in terms that enable him or her to choose for maximum ROI.

              Any Backlog Item that the PO does not understand is a weakness, because it takes away from the PO being able to perform responsibly. Therefore, every Backlog Item should be expressed in terms that make business sense to the PO. Therefore, every Backlog Item can be expressed as a user story, and should be.
              Don't ignore your dreams; don't work too much; say what you think; cultivate friendships; be happy. -- Paul Graham



            • Ron Jeffries
              Srinivas, ... People can and should understand many things. However, Product Backlog items all need to bear business value that is understandable enough so
              Message 6 of 17 , Aug 28, 2013
              • 0 Attachment
                Srinivas,

                On Aug 28, 2013, at 2:07 AM, srinivas chillara <ceezone@...> wrote:

                POs can (and should) understand items that are not written as user stories as well.

                People can and should understand many things. However, Product Backlog items all need to bear business value that is understandable enough so that the Product Owner (and any observer) can compare them to decide which to do first.

                I don't care what format they are written in. The "As a" format, for example, is training wheels and probably an obstacle to progress after the first few weeks. 

                Scrum backlog items, in order to be ordered properly, need to be comparable in the mind of the Product Owner. If they are comparable it doesn't matter how they are written, they are OK. If they are not comparable, it doesn't matter how they are written: they are trouble.

                Ron Jeffries
                www.XProgramming.com
                Sometimes I give myself admirable advice, but I am incapable of taking it.
                -- Mary Wortley Montagu



              • srinivas chillara
                Hello Ron, Fair point. So spike items need not be (preferably should be) in the format of a user story, as long as they are comparable, especially to the PO. 
                Message 7 of 17 , Aug 28, 2013
                • 0 Attachment
                  Hello Ron,
                  Fair point. So spike items need not be (preferably should be) in the format of a user story, as long as they are comparable, especially to the PO. 

                  It's interesting you say "As a ..." format is just training wheels.
                  I have seen it to be very useful well into a project/product to keep the focus on the user's needs. I've seen the format of the user story so useful and the conversations it can generate (esp with a cross fucntional team) progress discussion on functionality much faster than otherwise; I think we can just continue to use it. 
                  Why do you say these are just training wheels, what is a better option you have in mind?  In what way could this format be a hindrance?

                  cheers
                  Srinivas

                  From: Ron Jeffries <ronjeffries@...>
                  To: scrumdevelopment@yahoogroups.com
                  Sent: Wednesday, 28 August 2013 2:35 PM
                  Subject: Re: [scrumdevelopment] Spike stories - estimation and acceptance criteria ?

                   
                  Srinivas,

                  On Aug 28, 2013, at 2:07 AM, srinivas chillara <ceezone@...> wrote:

                  POs can (and should) understand items that are not written as user stories as well.

                  People can and should understand many things. However, Product Backlog items all need to bear business value that is understandable enough so that the Product Owner (and any observer) can compare them to decide which to do first.

                  I don't care what format they are written in. The "As a" format, for example, is training wheels and probably an obstacle to progress after the first few weeks. 

                  Scrum backlog items, in order to be ordered properly, need to be comparable in the mind of the Product Owner. If they are comparable it doesn't matter how they are written, they are OK. If they are not comparable, it doesn't matter how they are written: they are trouble.

                  Ron Jeffries
                  www.XProgramming.com
                  Sometimes I give myself admirable advice, but I am incapable of taking it.
                  -- Mary Wortley Montagu





                • Ron Jeffries
                  ... They need to speak to business value. The format is BS. ... Yes. ... Sure. You can do whatever you wish. ... People ask questions about the format: that s
                  Message 8 of 17 , Aug 28, 2013
                  • 0 Attachment

                    On Aug 28, 2013, at 1:30 PM, srinivas chillara <ceezone@...> wrote:

                    Fair point. So spike items need not be (preferably should be) in the format of a user story, as long as they are comparable, especially to the PO. 

                    They need to speak to business value. The format is BS.

                    It's interesting you say "As a ..." format is just training wheels.

                    Yes. 

                    I have seen it to be very useful well into a project/product to keep the focus on the user's needs. I've seen the format of the user story so useful and the conversations it can generate (esp with a cross fucntional team) progress discussion on functionality much faster than otherwise; I think we can just continue to use it. 

                    Sure. You can do whatever you wish.

                    Why do you say these are just training wheels, what is a better option you have in mind?  In what way could this format be a hindrance?

                    People ask questions about the format: that's waste. The purpose of the written part of a user story is to serve as a ticket to the conversation. All that needs to be written should be enough to remember what the story is. 

                    Sticking to a rigid format in an Agile method strikes me as uniquely … um … odd.

                    Ron Jeffries
                    I'm really pissed off by what people are passing off as "agile" these days.
                    You may have a red car, but that does not make it a Ferrari.
                      -- Steve Hayes

                  • frede_swe
                    Sorry for being a bit off-topic here but I think this is an interesting discussion. The Scrum guide does not say exactly how a PBI should be expressed or that
                    Message 9 of 17 , Aug 28, 2013
                    • 0 Attachment
                      Sorry for being a bit off-topic here but I think this is an interesting discussion.
                      The Scrum guide does not say exactly how a PBI should be expressed or that all PBIs must be expressed in the same way. There seem to be some disagreement in the scrum community whether all PBIs must have direct business value or not. Some say yes, some say no.
                      The PO is responsible for ROI and to make any intelligent decision about how to prioritize the backlog the PO must understand the items and they must also make sense to stakeholders, which suggests that the product backlog should only contain user stories. However, the backlog should contain ALL the requirements for the product which I think assumes that work that do not have obvious business value should also be on the backlog, e.g. spikes, rewriting/refactoring etc. Some suggest that "technical tasks" should be included as tasks in user stories but I think that shoehorning this kind of work into stories reduce transparency.

                      /Fredrik

                      --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                      >
                      > Srinivas,
                      >
                      > On Aug 28, 2013, at 2:07 AM, srinivas chillara <ceezone@...> wrote:
                      >
                      > > POs can (and should) understand items that are not written as user stories as well.
                      >
                      >
                      > People can and should understand many things. However, Product Backlog items all need to bear business value that is understandable enough so that the Product Owner (and any observer) can compare them to decide which to do first.
                      >
                      > I don't care what format they are written in. The "As a" format, for example, is training wheels and probably an obstacle to progress after the first few weeks.
                      >
                      > Scrum backlog items, in order to be ordered properly, need to be comparable in the mind of the Product Owner. If they are comparable it doesn't matter how they are written, they are OK. If they are not comparable, it doesn't matter how they are written: they are trouble.
                      >
                      > Ron Jeffries
                      > www.XProgramming.com
                      > Sometimes I give myself admirable advice, but I am incapable of taking it.
                      > -- Mary Wortley Montagu
                      >
                    • srinivas chillara
                      Hallo Fredrik, I think you are on the topic.... otherwise I agree with you. spikes can have business value, but often difficult to know ahead of time.
                      Message 10 of 17 , Aug 28, 2013
                      • 0 Attachment
                        Hallo Fredrik,
                        I think you are on the topic....
                        otherwise I agree with you. spikes can have business value, but often difficult to know ahead of time.
                        Basically spikes help us make reasonably informed decisions later on. 
                        cheers
                        Srinivas


                        From: frede_swe <fredrik.vestin@...>
                        To: scrumdevelopment@yahoogroups.com
                        Sent: Thursday, 29 August 2013 1:06 AM
                        Subject: [scrumdevelopment] Re: Spike stories - estimation and acceptance criteria ?

                         
                        Sorry for being a bit off-topic here but I think this is an interesting discussion.
                        The Scrum guide does not say exactly how a PBI should be expressed or that all PBIs must be expressed in the same way. There seem to be some disagreement in the scrum community whether all PBIs must have direct business value or not. Some say yes, some say no.
                        The PO is responsible for ROI and to make any intelligent decision about how to prioritize the backlog the PO must understand the items and they must also make sense to stakeholders, which suggests that the product backlog should only contain user stories. However, the backlog should contain ALL the requirements for the product which I think assumes that work that do not have obvious business value should also be on the backlog, e.g. spikes, rewriting/refactoring etc. Some suggest that "technical tasks" should be included as tasks in user stories but I think that shoehorning this kind of work into stories reduce transparency.

                        /Fredrik

                        --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                        >
                        > Srinivas,
                        >
                        > On Aug 28, 2013, at 2:07 AM, srinivas chillara <ceezone@...> wrote:
                        >
                        > > POs can (and should) understand items that are not written as user stories as well.
                        >
                        >
                        > People can and should understand many things. However, Product Backlog items all need to bear business value that is understandable enough so that the Product Owner (and any observer) can compare them to decide which to do first.
                        >
                        > I don't care what format they are written in. The "As a" format, for example, is training wheels and probably an obstacle to progress after the first few weeks.
                        >
                        > Scrum backlog items, in order to be ordered properly, need to be comparable in the mind of the Product Owner. If they are comparable it doesn't matter how they are written, they are OK. If they are not comparable, it doesn't matter how they are written: they are trouble.
                        >
                        > Ron Jeffries
                        > www.XProgramming.com
                        > Sometimes I give myself admirable advice, but I am incapable of taking it.
                        > -- Mary Wortley Montagu
                        >



                      • Tim Wright
                        Hi all, We use spikes for risk reduction - most of the time to determine if something is technically feasible. Reducing project risks early is valuable to the
                        Message 11 of 17 , Aug 28, 2013
                        • 0 Attachment

                          Hi all,

                          We use spikes for risk reduction - most of the time to determine if something is technically feasible.

                          Reducing project risks early is valuable to the business.

                          Tim




                          On 29 August 2013 08:12, srinivas chillara <ceezone@...> wrote:
                           

                          Hallo Fredrik,
                          I think you are on the topic....
                          otherwise I agree with you. spikes can have business value, but often difficult to know ahead of time.
                          Basically spikes help us make reasonably informed decisions later on. 
                          cheers
                          Srinivas


                          From: frede_swe <fredrik.vestin@...>
                          To: scrumdevelopment@yahoogroups.com
                          Sent: Thursday, 29 August 2013 1:06 AM
                          Subject: [scrumdevelopment] Re: Spike stories - estimation and acceptance criteria ?

                           
                          Sorry for being a bit off-topic here but I think this is an interesting discussion.
                          The Scrum guide does not say exactly how a PBI should be expressed or that all PBIs must be expressed in the same way. There seem to be some disagreement in the scrum community whether all PBIs must have direct business value or not. Some say yes, some say no.
                          The PO is responsible for ROI and to make any intelligent decision about how to prioritize the backlog the PO must understand the items and they must also make sense to stakeholders, which suggests that the product backlog should only contain user stories. However, the backlog should contain ALL the requirements for the product which I think assumes that work that do not have obvious business value should also be on the backlog, e.g. spikes, rewriting/refactoring etc. Some suggest that "technical tasks" should be included as tasks in user stories but I think that shoehorning this kind of work into stories reduce transparency.

                          /Fredrik

                          --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                          >
                          > Srinivas,
                          >
                          > On Aug 28, 2013, at 2:07 AM, srinivas chillara <ceezone@...> wrote:
                          >
                          > > POs can (and should) understand items that are not written as user stories as well.
                          >
                          >
                          > People can and should understand many things. However, Product Backlog items all need to bear business value that is understandable enough so that the Product Owner (and any observer) can compare them to decide which to do first.
                          >
                          > I don't care what format they are written in. The "As a" format, for example, is training wheels and probably an obstacle to progress after the first few weeks.
                          >
                          > Scrum backlog items, in order to be ordered properly, need to be comparable in the mind of the Product Owner. If they are comparable it doesn't matter how they are written, they are OK. If they are not comparable, it doesn't matter how they are written: they are trouble.
                          >
                          > Ron Jeffries
                          > www.XProgramming.com
                          > Sometimes I give myself admirable advice, but I am incapable of taking it.
                          > -- Mary Wortley Montagu
                          >






                          --
                          Tim
                          021 251 5593
                        • Ron Jeffries
                          Hi Fredrik, ... There should be transparency of course. There should be no work done, none, not any, that does not have business value. The Product Owner is
                          Message 12 of 17 , Aug 29, 2013
                          • 0 Attachment
                            Hi Fredrik,

                            On Aug 28, 2013, at 3:36 PM, frede_swe <fredrik.vestin@...> wrote:

                            However, the backlog should contain ALL the requirements for the product which I think assumes that work that do not have obvious business value should also be on the backlog, e.g. spikes, rewriting/refactoring etc. Some suggest that "technical tasks" should be included as tasks in user stories but I think that shoehorning this kind of work into stories reduce transparency. 

                            There should be transparency of course.

                            There should be no work done, none, not any, that does not have business value. The Product Owner is the only role that can put work into the Sprint Backlog. Since no one else can choose an item, the PO needs to understand the item. 

                            Technical tasks are historically part of Scrum but many have found them to be weak in several regards. First, they tend to reduce transparency, as you mention above. Second, they tend to lock the team into a specific solution, at the time in the Sprint when they know the least. Third, they tend to support specialist development, and to work against people becoming more capable. Fourth, they tend to result in work queues, and queues are always bad. Fifth, they tend to result in one kind of work holding back many stories.

                            Despite all this, technical tasks are a valid way to work. It's just that they're not often the best way.

                            Ron Jeffries
                            www.XProgramming.com
                            Sometimes I give myself admirable advice, but I am incapable of taking it.
                            -- Mary Wortley Montagu



                          • Adrian Howard
                            ... Yup. Freakishly odd. I ve definately hit problems with some clients with the As aà format. Especially when the value to the user of the story and the
                            Message 13 of 17 , Aug 29, 2013
                            • 0 Attachment

                              On 28 August 2013 18:37, Ron Jeffries <ronjeffries@...> wrote:

                              Why do you say these are just training wheels, what is a better option you have in mind?  In what way could this format be a hindrance?

                              People ask questions about the format: that's waste. The purpose of the written part of a user story is to serve as a ticket to the conversation. All that needs to be written should be enough to remember what the story is. 

                              Sticking to a rigid format in an Agile method strikes me as uniquely … um … odd.

                              Yup. Freakishly odd. I've definately hit problems with some clients with the "As a…" format. Especially when the value to the "user" of the story and the value to the business are not the same.

                              Cheers,

                              Adrian
                              -- 
                              adrianh@... / +44 (0)7752 419080 / @adrianh / quietstars.com
                              Subscribe to the latest Agile & Lean UX news here > http://is.gd/KREt5S

                            • Michael James
                              ... Sprint tasks are/were created by the team during Sprint Planning to accomplish Product Backlog Items. We didn t refer to items in the Product Backlog as
                              Message 14 of 17 , Aug 29, 2013
                              • 0 Attachment
                                On Aug 29, 2013, at 4:18 AM, Ron Jeffries <ronjeffries@...> wrote:

                                > Technical tasks are historically part of Scrum

                                Sprint tasks are/were created by the team during Sprint Planning to accomplish Product Backlog Items. We didn't refer to items in the Product Backlog as tasks.

                                --mj
                                (Michael)
                              • Adam Sroka
                                The way we did it was to list tasks in pencil on the back of the card in order to size the story. We never estimated the tasks and we didn t expect the pair
                                Message 15 of 17 , Aug 29, 2013
                                • 0 Attachment

                                  The way we did it was to list tasks in pencil on the back of the card in order to size the story. We never estimated the tasks and we didn't expect the pair that implemented the story to necessarily do it that way.

                                  I never liked tasking in ideal time as recommended by Mike Cohn. I have seen a lot of teams do it, and I worry that they get bogged down in the numbers rather than discussing the actual work. That said, having tasks linked to stories is a much better idea than "technical stories".

                                  On Aug 29, 2013 9:11 AM, "Michael James" <mj4scrum@...> wrote:
                                   

                                  On Aug 29, 2013, at 4:18 AM, Ron Jeffries <ronjeffries@...> wrote:

                                  > Technical tasks are historically part of Scrum

                                  Sprint tasks are/were created by the team during Sprint Planning to accomplish Product Backlog Items. We didn't refer to items in the Product Backlog as tasks.

                                  --mj
                                  (Michael)

                                • Michael James
                                  Yes, agree with all this. We also found that about half the tasks to actually accomplish a PBI would be discovered during Sprint Execution itself (as Ken s
                                  Message 16 of 17 , Aug 29, 2013
                                  • 0 Attachment
                                    Yes, agree with all this.  We also found that about half the tasks to actually accomplish a PBI would be discovered during Sprint Execution itself (as Ken's book predicted).

                                    --mj
                                    (Michael)


                                    On Aug 29, 2013, at 6:18 AM, Adam Sroka <adam.sroka@...> wrote:

                                     

                                    The way we did it was to list tasks in pencil on the back of the card in order to size the story. We never estimated the tasks and we didn't expect the pair that implemented the story to necessarily do it that way.

                                    I never liked tasking in ideal time as recommended by Mike Cohn. I have seen a lot of teams do it, and I worry that they get bogged down in the numbers rather than discussing the actual work. That said, having tasks linked to stories is a much better idea than "technical stories".

                                    On Aug 29, 2013 9:11 AM, "Michael James" <mj4scrum@...> wrote:
                                     

                                    On Aug 29, 2013, at 4:18 AM, Ron Jeffries <ronjeffries@...> wrote:

                                    > Technical tasks are historically part of Scrum

                                    Sprint tasks are/were created by the team during Sprint Planning to accomplish Product Backlog Items. We didn't refer to items in the Product Backlog as tasks.

                                    --mj
                                    (Michael)



                                  • Doug
                                    Ron: Technical stories Should Be expressed as a User Story?? I think Not. I ve worked with many POs who understand the technical components and need to do
                                    Message 17 of 17 , Aug 30, 2013
                                    • 0 Attachment
                                      Ron:

                                      Technical stories "Should Be" expressed as a User Story?? I think Not. I've worked with many POs who understand the technical components and need to do them without the need to express the technical requirement as a "user story" per se. I don't see the logical rationale to impose artifical restrictions on requirements as long as they are understood - and in fact You, as the promoter of Card, Conversation, and Confirmation, I'd think would be the first to agree since the conversation can take any form.

                                      --- In scrumdevelopment@yahoogroups.com, srinivas chillara <ceezone@...> wrote:
                                      >
                                      > POs can (and should) understand items that are not written as user stories as well.
                                      > cheers
                                      > Srinivas
                                      >
                                      >
                                      >
                                      >
                                      > ________________________________
                                      > From: Ron Jeffries <ronjeffries@...>
                                      > To: scrumdevelopment@yahoogroups.com
                                      > Sent: Wednesday, 28 August 2013 8:20 AM
                                      > Subject: Re: [scrumdevelopment] Spike stories - estimation and acceptance criteria ?
                                      >
                                      >
                                      >
                                      >  
                                      > Srinivas,
                                      >
                                      >
                                      > On Aug 27, 2013, at 10:33 PM, srinivas chillara <ceezone@...> wrote:
                                      >
                                      > Your understanding is correct. A slightly different perspective:
                                      > >We needn't worry to make each and every PBI a "story";
                                      > >So a spike is all right, w/o gerrymandering the boundaries of "user stories".
                                      > On the contrary. The Product Owner represents the business. The product owner is responsible for the project's successfully maximizing ROI. The Product Owner defines and chooses the work to be done. Therefore the Product Owner must understand the work to be done, in terms that enable him or her to choose for maximum ROI.
                                      >
                                      > Any Backlog Item that the PO does not understand is a weakness, because it takes away from the PO being able to perform responsibly. Therefore, every Backlog Item should be expressed in terms that make business sense to the PO. Therefore, every Backlog Item can be expressed as a user story, and should be.
                                      >
                                      >
                                      > Ron Jeffrieswww.XProgramming.comDon't ignore your dreams; don't work too much; say what you think; cultivate friendships; be happy. -- Paul Graham
                                      >
                                    Your message has been successfully submitted and would be delivered to recipients shortly.