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

Re: Scrum newbie: User story for technical tasks

Expand Messages
  • contact_nauman
    What you mentioned is correct, in the meetings we were just spending lots of time on the technical details while we should be focusing around business needs.
    Message 1 of 26 , Nov 23, 2010
    • 0 Attachment
      What you mentioned is correct, in the meetings we were just spending lots of time on the technical details while we should be focusing around business needs.

      Thank you for taking the time and responding to my questions. I would be eagerly waiting for your blog on how to write the Uuser stories. Kindly let me know where I can read it.

      Best regards
      Nauman

      --- In scrumdevelopment@yahoogroups.com, "banshee858" <cnett858@...> wrote:
      >
      >
      > > Technical User Story (there can be one or more tech US):
      > > As a developer, I need to integrate with the internal system XYZ using webservice and
      > > external vendor using Payment webservice so that the credit card/guest point payment
      > > options can be displayed to the customer.
      > >
      > [Sound of nails on a chalk board & teeth grinding] ughh!! If I see another "As a developer..." story, I think I am going to scream.
      >
      > IMHO, if you are writing stories like this, you have are focusing too much on the template and not enough on the critical thinking aspects of user stories. Almost nothing the developers want the system to do provides value to the customer or any other stakeholder. This story looks like a technical person wrote it. [This inspired me to write a blog entry on how to write stories, so thank you].
      >
      > I might re-write your story like this to provide greater focus on providing value to the customers and stakeholders. "Customer: I want to pay via credit card and guest points to reserve my X".
      >
      > All the other stuff that you wrote in the story is implementation detail. Useful stuff to talk about and understand, but not part of the user story. User stories need to describe the role, the feature, why it is valuable and include an acceptance test. That's it.
      >
      > > Question 2) For all the infrastructure setup tasks like servers, databases, my
      > > development team has to spend good amount of time. So should we write technical US
      > > for such tasks?
      > >
      > Not everything needs a user story. Sometimes there is just "stuff" to do. My suggestion, make a list of the stuff to do, write them on post-it notes and then marry up the stuff with the user stories that make sense.
      >
      > > Question 3) We have a strict governance process for design reviews and SOX compliance
      > > etc which requires extensive upfront documentation and approvals which goes against
      > > the spirit of Scrum. What is the recommendation to handle such compliance
      > > requirements?
      > >
      > Other people covered this in more detail.
      >
      > Carlton
      >
    • contact_nauman
      Hi Doug, You gave me a very good idea about aligning the process first with the internal auditor as to what the would expect from the development team in order
      Message 2 of 26 , Nov 23, 2010
      • 0 Attachment
        Hi Doug,

        You gave me a very good idea about aligning the process first with the internal auditor as to what the would expect from the development team in order to be compliant.

        While I am researching and learning at this forum, I have advised my senior leadership to align and get support from the internal governance teams. I think this up-front alignment with all these governance team and auditors is a must in order to avoid any surprises lateron.

        Thanks you and I really appreciate your opinion.

        Kind regards
        Nauman




        --- In scrumdevelopment@yahoogroups.com, "daswartz@..." <daswartz@...> wrote:
        >
        > Hello contact_nauman,
        >
        > Tuesday, November 23, 2010, 5:03:18 AM, you wrote:
        >
        > > Question 3) We have a strict governance process for design reviews
        > > and SOX compliance etc which requires extensive upfront
        > > documentation and approvals which goes against the spirit of Scrum.
        > > What is the recommendation to handle such compliance requirements?
        >
        > When SOX became a requirement, I worked closely with the auditors to
        > understand what the law added to our software development requirements
        > and enhance our processes to keep them compliant.
        >
        > The law does NOT require that all analysis, big design documents, etc.
        > be done up front. It does require that software development processes
        > be documented, all changes are made with proper authorization and are
        > appropriately reviewed and tested. To me, these seem very congruent
        > with agile development. Thus, I don't believe SOX itself goes against
        > the spirit of agile development. Unfortunately, your existing
        > corporate governance process certainly may cause you difficulties.
        >
        > In our case, after consultation with the internal auditing team, we
        > found the practices we were already doing (automated developer/unit
        > tests, automated customer specified acceptance tests, pair
        > programming, sprint planning and reviews, existing production
        > implementation controls, etc.), took us a long way toward SOX
        > compliance.
        >
        > This was a few years ago, but if I remember correctly, here is what we
        > added to meet a few control points we didn't have well covered:
        >
        > 1. The project manager sent a memo recapping results and attendees of
        > the sprint planning meeting, and the memo was permanently logged
        > (ensure changes are authorized).
        >
        > 2. Before production implementation, which we did at least monthly,
        > we added formal product owner approval to the existing paperwork.
        > Previously product owner approval for production implementation was
        > verbal. (ensure changes are authorized and reviewed)
        >
        > 3. Added a story number to each card and tagged each software change
        > in the SCM with the story number.
        >
        >
        > Doug Swartz
        >
      • contact_nauman
        Thank you Ron. I have been reading your replies to other users and you are doing a great job in helping other peoples to learn this new world of agile. Just
        Message 3 of 26 , Nov 23, 2010
        • 0 Attachment
          Thank you Ron. I have been reading your replies to other users and you are doing a great job in helping other peoples to learn this new world of agile.

          Just few queries where I need little more clarification:
          1) As Carlton mentioned earlier to my second question regarding infrastructure that not everything has to a story. Some stuff can be tracked outside the stories. In our organization, we are dependent on other teams for infrastructure setup and developers spend a quite good amount of time in working with the infrastructure team to get server, databases etc. So do you also recommend not to include this task in any sprint as a user story, even if it takes big effort?

          2) Quality requirements or Non-functional requirements (NFR): For e.g. avalability should be 99.9%, page should load in less than X seconds, website should support X,Y,Z browsers?

          Can we write NFR as User Stories? If yes then do we need to include these users stories in every Sprint to make sure these quality requirements are met? If no, where these should be documented and how to convey these to the testers that they have to test for all these quality requirements in every sprint?

          3)This is similar to NFR but a little different in my thinking. Every external vendor who integrate with us has to follow certain standards laid by our governance team. For e.g. there application has to be follow 3-tier architecture, customer information has to be encrypted, implement all the applicable web development best practices etc. Can we treat this as NFR and follow the same approach for this type of standard which the external vendor has to follow?

          Really appriaciate your response.

          Kind regards
          Nauman



          --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
          >
          > Hello, contact_nauman. On Tuesday, November 23, 2010, at 6:03:18
          > AM, you wrote:
          >
          > > Technical User Story (there can be one or more tech US):
          > > As a developer, I need to integrate with the internal system XYZ
          > > using webservice and external vendor using Payment webservice so
          > > that the credit card/guest point payment options can be displayed to the customer.
          >
          > The essential point of Agile and Scrum is the direction of the
          > project by the Product Owner, who is a business-side person, not a
          > technical person.
          >
          > Therefore every story needs to be expressed in business terms.
          > Technical stories are, from this viewpoint, a very bad process
          > smell, and are to be avoided.
          >
          > Ron Jeffries
          > www.XProgramming.com
          > You have to either laugh or cry. -- Bill Rogers
          >
        • Ron Jeffries
          Hello, contact_nauman. On Tuesday, November 23, 2010, at 10:48:17 ... I believe that everything has a business-value story. If it does not, we should not do
          Message 4 of 26 , Nov 24, 2010
          • 0 Attachment
            Hello, contact_nauman. On Tuesday, November 23, 2010, at 10:48:17
            PM, you wrote:

            > Just few queries where I need little more clarification: 1) As
            > Carlton mentioned earlier to my second question regarding
            > infrastructure that not everything has to a story. Some stuff can
            > be tracked outside the stories. In our organization, we are
            > dependent on other teams for infrastructure setup and developers
            > spend a quite good amount of time in working with the
            > infrastructure team to get server, databases etc. So do you also
            > recommend not to include this task in any sprint as a user story,
            > even if it takes big effort?

            I believe that everything has a business-value story. If it does
            not, we should not do it.

            Scrum demands a "cross-functional team fully capable of delivering
            an increment of the product". Therefore Scrum asks us not to have a
            separate infrastructure team, but to have infrastructure capability
            on OUR team. (This Scrum rule is quite often broken. That's
            unfortunate.)

            I think that what works best is to slice stories into thin little
            slices of business value, not into technical tasks. See the little
            article http://xprogramming.com/beyond/the-trouble-with-tasks/ for
            example.

            > 2) Quality requirements or Non-functional requirements (NFR): For
            > e.g. avalability should be 99.9%, page should load in less than X
            > seconds, website should support X,Y,Z browsers?

            These both have business value, if the PO wants them, so they are OK
            as they stand.

            > Can we write NFR as User Stories? If yes then do we need to
            > include these users stories in every Sprint to make sure these
            > quality requirements are met? If no, where these should be
            > documented and how to convey these to the testers that they have
            > to test for all these quality requirements in every sprint?

            If you are using automated acceptance tests, the tests will test
            this.

            > 3)This is similar to NFR but a little different in my thinking.
            > Every external vendor who integrate with us has to follow certain
            > standards laid by our governance team. For e.g. there application
            > has to be follow 3-tier architecture, customer information has to
            > be encrypted, implement all the applicable web development best
            > practices etc. Can we treat this as NFR and follow the same
            > approach for this type of standard which the external vendor has to follow?

            This is an outside requirement. How the vendor manages it is up to
            him, isn't it? I don't see how this would impact your team's
            stories. I must be missing your point.

            > Really appriaciate your response.

            I must be doing something wrong .. :)

            Ron Jeffries
            www.XProgramming.com
            Some things are impossible. And some things people say are
            impossible -- because they don't know how to do them. -- Ron Loyd
          • contact_nauman
            Hi Ron, Yes how the vendor manages their development is upto them but from our governance perspective we need to get an email confrmation from vendor that they
            Message 5 of 26 , Nov 24, 2010
            • 0 Attachment
              Hi Ron,

              Yes how the vendor manages their development is upto them but from our governance perspective we need to get an email confrmation from vendor that they are following our standards for e.g. they are encrypting the customer data. I was just trying to figure out that for such activity should it be a User Story or just a checklist of items for tracking. Based on the response from everyone, I think it should not be a story, it should be just a checklist item.

              Best regards
              Nauman

              > > 3)This is similar to NFR but a little different in my thinking.
              > > Every external vendor who integrate with us has to follow certain
              > > standards laid by our governance team. For e.g. there application
              > > has to be follow 3-tier architecture, customer information has to
              > > be encrypted, implement all the applicable web development best
              > > practices etc. Can we treat this as NFR and follow the same
              > > approach for this type of standard which the external vendor has to follow?
              >
              > This is an outside requirement. How the vendor manages it is up to
              > him, isn't it? I don't see how this would impact your team's
              > stories. I must be missing your point.
            • banshee858
              ... IMHO, encryption to your standard is part of the acceptance criteria. If it is not there, the story has no value. Carlton
              Message 6 of 26 , Nov 24, 2010
              • 0 Attachment
                >
                > Yes how the vendor manages their development is upto them but from our governance
                > perspective we need to get an email confrmation from vendor that they are following our
                > standards for e.g. they are encrypting the customer data. I was just trying to figure out that
                > for such activity should it be a User Story or just a checklist of items for tracking. Based on
                > the response from everyone, I think it should not be a story, it should be just a checklist
                > item.
                >
                IMHO, encryption to your standard is part of the acceptance criteria. If it is not there, the story has no value.

                Carlton
              Your message has been successfully submitted and would be delivered to recipients shortly.