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

Iterations and business value delivered

Expand Messages
  • mi97ki
    Hi, the organization I work for has decided to adopt Scrum on one project. We are just starting and we do not have a mentor so we are facing some challenges.
    Message 1 of 10 , Sep 2, 2006
    • 0 Attachment
      Hi,

      the organization I work for has decided to adopt Scrum on one
      project.
      We are just starting and we do not have a mentor so we are facing
      some
      challenges.


      One is the following. We went through the planning meeting for the
      first iteration. During the meeting the Product Owner indicated that
      a
      specific feature had the highest priority. Now it does not seem that
      we
      can break down this feature in many small user stories. After all
      the
      end user is required to do very little to log on to the system:
      provide
      username and password and click an OK button. That's it. On the
      other
      hand, the infrastructure required to log on to the system turns out
      to
      be quite complex (it's an enterprise application). So here's the
      problem we are facing as a Team: we know that at the end of each
      iteration we have to provide a production-quality increment.
      However,
      if we add the user story "Logging on to the System" to Iteration 1,
      we
      won't be able to finish it in time (according to the estimates) //if
      we
      implement the entire back-end to support real authentication//. On
      the
      other hand, if we decided to mock some part of the back-end in order
      to
      meet the deadline for the iteration, we feel that we will not
      generate
      any business value.


      What should we do in this case or, more in general, what should we
      do
      anytime we have to implement a feature that has a small number of
      user
      stories associated and a big backend?


      I am sure we are missing something. Any suggestions would be
      appreciated.

      P.S. This message was posted also on comp.object. Here's the thread:
      http://groups.google.com/group/comp.object/browse_thread/thread/d979b
      8d524a41efc/916a2e039566fac4#916a2e039566fac4
    • Vickydhiman
      Hi: Assuming that tasks required for a user story are indeed many and user story can not be broken down into smaller modules - the only option seems to be to
      Message 2 of 10 , Sep 2, 2006
      • 0 Attachment
        Hi:
         
        Assuming that tasks required for a user story are indeed many and user story can not be broken down into smaller modules - the only option seems to be to make the sprint longer. However, this means that something has gone wrong somewhere.
         
        One of the discipline involved in writing user stories is to make each as independent as possible from the other. I get a hunch this is not the case here.
         
        I am also trifle confused as to how a simple front end functionality can have a huge backend? What do the user do after they are logged in to the system - is that also part of the first sprint? What are the user stories in that case? Are there authentications at multiple modules/ features/ parts of system? Do these systems already exist?
         
        Thanks
         
        Vicky

        mi97ki <mi97ki@...> wrote:
        Hi,

        the organization I work for has decided to adopt Scrum on one
        project.
        We are just starting and we do not have a mentor so we are facing
        some
        challenges.

        One is the following. We went through the planning meeting for the
        first iteration. During the meeting the Product Owner indicated that
        a
        specific feature had the highest priority. Now it does not seem that
        we
        can break down this feature in many small user stories. After all
        the
        end user is required to do very little to log on to the system:
        provide
        username and password and click an OK button. That's it. On the
        other
        hand, the infrastructure required to log on to the system turns out
        to
        be quite complex (it's an enterprise application) . So here's the
        problem we are facing as a Team: we know that at the end of each
        iteration we have to provide a production-quality increment.
        However,
        if we add the user story "Logging on to the System" to Iteration 1,
        we
        won't be able to finish it in time (according to the estimates) //if
        we
        implement the entire back-end to support real authentication/ /. On
        the
        other hand, if we decided to mock some part of the back-end in order
        to
        meet the deadline for the iteration, we feel that we will not
        generate
        any business value.

        What should we do in this case or, more in general, what should we
        do
        anytime we have to implement a feature that has a small number of
        user
        stories associated and a big backend?

        I am sure we are missing something. Any suggestions would be
        appreciated.

        P.S. This message was posted also on comp.object. Here's the thread:
        http://groups. google.com/ group/comp. object/browse_ thread/thread/ d979b
        8d524a41efc/ 916a2e039566fac4 #916a2e039566fac 4



        All-new Yahoo! Mail - Fire up a more powerful email and get things done faster.

      • William Wake
        ... I don t know if it will help, but you might find some ideas in this article, Twenty Ways to Split Stories (http://xp123.com/xplor/xp0512/index.shtml) ...
        Message 3 of 10 , Sep 3, 2006
        • 0 Attachment
          On 9/2/06, mi97ki <mi97ki@...> wrote:
          > One is the following. We went through the planning meeting for the
          > first iteration. During the meeting the Product Owner indicated that
          > a specific feature had the highest priority.

          > Now it does not seem that we
          > can break down this feature in many small user stories.

          I don't know if it will help, but you might find some ideas in this
          article, "Twenty Ways to Split Stories"
          (http://xp123.com/xplor/xp0512/index.shtml)

          > After all
          > the end user is required to do very little to log on to the system:
          > provide username and password and click an OK button. That's it.
          > On the other hand, the infrastructure required to log on to the system
          > turns out to be quite complex (it's an enterprise application). So here's the
          > problem we are facing as a Team: we know that at the end of each
          > iteration we have to provide a production-quality increment.
          > However, if we add the user story "Logging on to the System" to
          > Iteration 1, we won't be able to finish it in time (according to the estimates)
          > //if we implement the entire back-end to support real authentication//.

          It's not clear if it's a from-scratch authentication service or
          connecting to an existing one. If it's creating a new one, you could
          do things like omit persistence or simplify failure handling. If it's
          connecting to an existing one, I guess it must be so hard because
          people don't know how to do it & think they can't figure it out in a
          month. I'd probably try a story that's "spike connecting to
          authentication."

          > On the other hand, if we decided to mock some part of the back-end in
          > order to meet the deadline for the iteration, we feel that we will not
          > generate any business value.

          In desperation:), I don't mind parts being mocked out, as long as
          everybody (esp including product owner) is clear on what's real and
          what's not. In this example, the product owner might be far more
          interested in seeing how some of his "real" stories play out, and
          willing to accept a jerry-rigged login service. It depends where the
          risk is.

          "[...] we feel that we will not generate any business value." Does the
          product owner feel this way, just developers, or who? By far the best
          business value is some ready-to-ship software (as you clearly
          understand). But there is also business value in a team that's able to
          say, "We can estimate this now" or "We understand the real issues
          now."

          There's also business value in a product owner understanding, "with
          this team and our current environment, an app like this must pay a
          6-week 'login tax'". As a PO, I'd need to understand that. It would
          certainly affect my future plans (negatively, unfortunately). (As a
          ScrumMaster, I'd be helping the team look pretty hard at what barriers
          there are that make this take so long.)

          > What should we do in this case or, more in general, what should we
          > do anytime we have to implement a feature that has a small number of
          > user stories associated and a big backend?

          One thing I try to do is "just enough infrastructure", making apps
          "pay as you go". Another thing is to use risk to drive which parts
          need to be fully elaborated now. I'd rather tackle the parts that I'm
          most worried about. "We know how to do it, it'll just take a while" is
          less risky than "We don't know how to do it" or "We know how to do it,
          but we don't know whether it will meet the users' needs."

          Regards,
          --
          Bill Wake William.Wake@... www.xp123.com
        • Marco Abis
          Hi, in addition to what the others said (and will say) I think you should work more with the PO. Usually a full login feature is far from being the highest
          Message 4 of 10 , Sep 3, 2006
          • 0 Attachment
            Hi,

            in addition to what the others said (and will say) I think
            you should work more with the PO. Usually a full login feature is far
            from being the highest priority/value one, or is you system supposed
            to deliver value letting people login and do nothing else? ;-)

            It's not the first time I see it (it's normal): the PO is still
            thinking in a linear way in which there cannot be an application
            without login first of all. If the goal of the application is to
            allow a user to do X start from X mocking out everything else and
            then build upon it

            Regards



            Marco Abis

            "let's not talk about Type A Scrum unless we also want to talk
            about Type W Scrum, which is more commonly called Waterfall" (Mike Cohn)

            http://www.agilemovement.it :: Italian Agile Movement
          • David H
            ... Sometimes that is indeed what you want. This could indicate that there are some sort of third party interests involved and as a prerequisit to further
            Message 5 of 10 , Sep 3, 2006
            • 0 Attachment
              | in addition to what the others said (and will say) I think
              |you should work more with the PO. Usually a full login feature is far
              |from being the highest priority/value one, or is you system supposed
              |to deliver value letting people login and do nothing else? ;-)

              Sometimes that is indeed what you want. This could indicate that there
              are some sort of third party interests involved and as a prerequisit to
              further funding the Login has to work by XY. Thus the login becomes the
              most important functionality.

              But as I said that might be rare :)

              -d
            • Steven Gordon
              As may have already been pointed out, the customer is probably confounding business dependency for business value. Just because in the final delivery, a user
              Message 6 of 10 , Sep 3, 2006
              • 0 Attachment
                As may have already been pointed out, the customer is probably confounding business dependency for business value.  Just because in the final delivery, a user has to log in before he can do anything else, that does not mean logging in the most valuable thing the system provides.  I sometimes first ask the customer for the most core functionality instead of the most valuable.

                I also suspect two possible explanations for a login implementation to be too complex for a team to do in the first sprint:
                1. All sorts of startup tasks (setting up machines, source control, databases, development environments, build scripts, etc.) are taking up much of the available time.
                2. Authorization is being confounded with authenication.

                If the first is the case, ask the customer to pick something smaller and more core to allow the team time to set up their infrastructure and still deliver something.

                If the second is the case, write and estimate separate stories about deciding what a user is permitted to do after logging in.  The implementation of those stories may later change some of the guts of what happens when a user logs in, but those changes should not be rewrites if proper OO principles are followed.

                Steven Gordon

                On 9/2/06, mi97ki <mi97ki@...> wrote:

                Hi,

                the organization I work for has decided to adopt Scrum on one
                project.
                We are just starting and we do not have a mentor so we are facing
                some
                challenges.

                One is the following. We went through the planning meeting for the
                first iteration. During the meeting the Product Owner indicated that
                a
                specific feature had the highest priority. Now it does not seem that
                we
                can break down this feature in many small user stories. After all
                the
                end user is required to do very little to log on to the system:
                provide
                username and password and click an OK button. That's it. On the
                other
                hand, the infrastructure required to log on to the system turns out
                to
                be quite complex (it's an enterprise application). So here's the
                problem we are facing as a Team: we know that at the end of each
                iteration we have to provide a production-quality increment.
                However,
                if we add the user story "Logging on to the System" to Iteration 1,
                we
                won't be able to finish it in time (according to the estimates) //if
                we
                implement the entire back-end to support real authentication//. On
                the
                other hand, if we decided to mock some part of the back-end in order
                to
                meet the deadline for the iteration, we feel that we will not
                generate
                any business value.

                What should we do in this case or, more in general, what should we
                do
                anytime we have to implement a feature that has a small number of
                user
                stories associated and a big backend?

                I am sure we are missing something. Any suggestions would be
                appreciated.

                P.S. This message was posted also on comp.object. Here's the thread:
                http://groups.google.com/group/comp.object/browse_thread/thread/d979b
                8d524a41efc/916a2e039566fac4#916a2e039566fac4


              • 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 7 of 10 , Sep 3, 2006
                • 0 Attachment
                  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 8 of 10 , Sep 3, 2006
                  • 0 Attachment
                    (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 9 of 10 , Sep 4, 2006
                    • 0 Attachment
                      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 10 of 10 , Sep 5, 2006
                      • 0 Attachment
                        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.