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

Complex requirements

Expand Messages
  • inanc
    Hello, First of all this is not a question. I just wanted to share with you the article appeared a few days ago in dr.doob s portal: Complex Requirements On
    Message 1 of 34 , Nov 2 2:53 AM
    • 0 Attachment

      First of all this is not a question. I just wanted to share with you
      the article appeared a few days ago in dr.doob's portal:

      " Complex Requirements On an Agile Project "
      by Scott Ambler

      One of my earlier posts as I have pointed out that scrum product
      backlog confuses me about how to effectively ( from many aspects ) put
      the non functional requirements into the product backlog. It has
      inherent difficulties.

      So the article talks about the shortcomings of a few agile processes
      like Scrum and XP:

      "Scrum's product backlog concept works well for simple functional
      requirements, but as I described in "Beyond Functional Requirements on
      Agile Projects" (www.ddj.com/architect/210601918), it comes up short
      for nonfunctional requirements and architectural constraints."

      I wonder what do you think about the article's viewpoints. You can
      follow the link to reach the article here:

    • Jeff
      thanks, and for all the other responses from others. To: scrumdevelopment@yahoogroups.comFrom: chuck-lists2@emailchuck.comDate: Thu, 6 Nov 2008 17:15:30
      Message 34 of 34 , Nov 6 10:06 AM
      • 0 Attachment
        thanks, and for all the other responses from  others.

        To: scrumdevelopment@yahoogroups.com
        From: chuck-lists2@...
        Date: Thu, 6 Nov 2008 17:15:30 +0000
        Subject: [scrumdevelopment] Re: user stories versus "system stories" as i call them.

        I concur, great strategy.

        Jeff, a couple of other things, based on the limited information you
        gave us, here are a couple more tips:

        1. If you're building an API, your "User" is any person/system who
        uses your API. As such, you can easily state your user stories from
        that perspective. "As an API user, I want to send a message and get a
        confirmation that the message was queued."

        2. You talked a lot about stuff happening on the back end. If you're
        doing an API, focus on the API interface, and less on what happens in
        the backend. If you find that you need to include something that
        happens on the backend for success criteria, try to state it in
        general terms. Instead of saying "Test that the message is marked as
        queued in the MSG_QUEUE table" -- say something like "Test that the
        system marks the message as having been queued.".... Better yet,
        consider the confirmation as the test of whether something has been


        --- In scrumdevelopment@ yahoogroups. com, "Alan Dayley" <alandd@...> wrote:
        > On Wed, Nov 5, 2008 at 6:39 PM, Ron Jeffries <ronjeffries@ ...> wrote:
        > >
        > > Who would be angry if you didn't do those things, and why? Reverse
        > > that answer and you have a story.
        > Wow. That is a great story-building tip! Thanks.
        > Alan

        Get 5 GB of storage with Windows Live Hotmail. Sign up today.
      Your message has been successfully submitted and would be delivered to recipients shortly.