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

Re: [scrumdevelopment] Spike stories - estimation and acceptance criteria ?

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