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

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

Expand Messages
  • 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 1 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 2 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 3 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.