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

Re: Iterations and business value delivered

Expand Messages
  • leknudsen_2000
    This is actually one of the examples I use when I teach teams how to break down features into stories that can be iterated. This method works if you are not
    Message 1 of 10 , Sep 3, 2006
      This is actually one of the examples I use when I teach teams how to
      break down features into stories that can be iterated. This method
      works if you are not releasing to the customers after each iteration.

      An example of this would be that in your first iteration you would
      have the focus on creating a screen with the login fields that fits
      your standard "look and feel" User Experience criteria. The fields
      can accept characters, but there is no backend.

      The second iteration could include the ability for there to be a
      file that can accept the user names and passwords with
      authentication to that file.

      The third iteration could include a story to extend the validation
      to be able to use LDAP or other commonly used variations.

      The fourth iteration could include roles or user types so that only
      the appropriate menu items are displayed when a user of that role
      logs in.

      And so on.

      This way you can meet the acceptance criteria for each iteration and
      close the iterations with accepted stories. You can still have
      regulated iterations of standard lengths and keep the customer's
      needs the focus of each iteration.
    • PaulOldfield1@aol.com
      (responding to leknudsen, all) ... Of course, there are ways to release to the customer nevertheless. We get good feedback and some business value if we
      Message 2 of 10 , Sep 3, 2006
        (responding to leknudsen, all)
         
        > This is actually one of the examples I use when I
        > teach teams how to break down features into stories
        > that can be iterated. This method works if you are
        > not releasing to the customers after each iteration.
        Of course, there are ways to release to the customer
        nevertheless.  We get good feedback and some
        business value if we release to the customers for
        test and familiarisation, pointing at a test database.
        We get real business value if the product is released
        to a restricted set of customer users who are trusted
        to work unauthenticated and fully authorised.  It may
        be the case that we can give 2 releases and do both
        of the above at the same time.
         
        At the risk of pointing out the obvious, because of these
        sorts of possibilities, we should be clear about exactly
        what we are delivering at the end of an iteration so the
        customer can prepare to use it effectively.  And to tie
        in with other recent threads, this latter topic is a good
        reason to make great effort to meet our commitments
        and not to add extra user stories during an iteration.
         
        Paul Oldfield
      • Ron Jeffries
        Hello leknudsen_2000, thank you for the thoughts quoted here. I ll be offering a different angle. On Monday, September 4, 2006, at ... [descriptions below
        Message 3 of 10 , Sep 4, 2006
          Hello leknudsen_2000, thank you for the thoughts quoted here. I'll
          be offering a different angle. On Monday, September 4, 2006, at
          1:55:20 AM, you wrote:

          > This is actually one of the examples I use when I teach teams how to
          > break down features into stories that can be iterated. This method
          > works if you are not releasing to the customers after each iteration.

          [descriptions below trimmed by me]

          > first iteration ... a screen with login fields, no backend.

          > second iteration ... a file, user names, passwords,
          > authentication.

          > third iteration ... extend the validation, LDAP or other
          > variations.

          > fourth iteration ... roles, user types, only appropriate items
          > displayed when a user-role logs in.

          > And so on.

          > This way you can meet the acceptance criteria for each iteration and
          > close the iterations with accepted stories. You can still have
          > regulated iterations of standard lengths and keep the customer's
          > needs the focus of each iteration.

          If the entire project was just to implement the ability to log in,
          this would be a good example of how to do it in iterations that
          would make sense to the customer.

          As others have pointed out, if the point of the project is really
          that when someone finally gets logged in, they press a button and
          something big happens, I would start with breaking down the
          something big and making it happen. If I had a screen at all, it
          would just have a button on it. More likely, no screens at all.

          Presumably the business value comes from the something big, and
          therefore it should be done first.

          Ron Jeffries
          www.XProgramming.com
          Knowledge must come through action;
          you can have no test which is not fanciful, save by trial. -- Sophocles
        • Knudsen Laureen
          You are presuming something that the original writer did not state. He stated the the Product Owner listed the login screen as highest priority. He didn t
          Message 4 of 10 , Sep 5, 2006
            You are presuming something that the original writer did not state. He stated the the Product Owner listed the login screen as highest priority. He didn't state the risk assigned to the entire backlog, but did indicate that this was primary on the product owners' list.
             
            Of course the product would need more in it than simply to log on. I was not implying that the login would be the only feature of the product. I would hope there would be enough people assigned to this project that the next highest priority item could also be started during these same iterations. Do you only work on one feature at a time? One story?  What sort of project allows this and yet still delivers value at each iteration?  
             
            My example was simply to show how you can break down larger requirements into manageable chunks. Which I thought was the question being asked.  
          Your message has been successfully submitted and would be delivered to recipients shortly.