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

Re: [scrumdevelopment] User stories feeling like CRUD tasks

Expand Messages
  • Keith Sader
    What s the goal or the desired result of these data manipulations? And have you used the template: As a I want to ? IMO
    Message 1 of 6 , May 1, 2007
    • 0 Attachment
      What's the goal or the desired result of these data manipulations?

      And have you used the template: As a <type of user> I want to <accomplish goal>?

      IMO fiddling with data isn't an end goal.

      thanks,


      On 5/1/07, Bil Simser <bsimser@...> wrote:

      I'm struggling a bit with a team that has come to me with a set of
      what they belive are user stories for their project. Here's a sampling:

      "As an administrator I can create a project so that it can be used as
      a starting point for other project components"
      "As an administrator I can modify a project so that project level
      information is changed to reflect requirements of a project in
      a 'design' state"
      "As an administrator I can delete a project so that I can
      remove 'design' or 'test' projects no longer needed in the system"

      I'm pulling my hair out reading these things as all of the user
      stories are very data centric (save, load, delete, bulk load, change
      this, change that...). The intended use of the application they're
      building is data centric as well (it's a maintainenance tool for a
      data-driven program that manages widgets).

      Am I being too critical here or are there some examples or techniques
      that you guys have used in the past to try to curb this type of user
      story construction?

      Thanks.




      --
      Keith Sader
      ksader@...
      http://www.sader-family.org/roller/page/ksader
    • Gregor Dodson
      These look like stories written by developers, not by users. They ve been reverse engineered from the development tasks, and had the value statement grafted
      Message 2 of 6 , May 1, 2007
      • 0 Attachment
        These look like stories written by developers, not by users. They've been reverse engineered from the development tasks, and had the 'value' statement grafted on to them.

        I'd go back to the 'administrator' and ask them to provide the stories. It might just be one story by the looks of it, 'Administrator can create, modify and delete projects so that projects can be rolled out and modified quickly in response to the customer's requests' - or something like that.

        The 'stories' that the team has given you is just a task list. Those are fine for planning, and estimating, but probably a little too implementation-focused to be truly effective user stories.

        Gregor

        On 5/1/07, Bil Simser <bsimser@...> wrote:

        I'm struggling a bit with a team that has come to me with a set of
        what they belive are user stories for their project. Here's a sampling:

        "As an administrator I can create a project so that it can be used as
        a starting point for other project components"
        "As an administrator I can modify a project so that project level
        information is changed to reflect requirements of a project in
        a 'design' state"
        "As an administrator I can delete a project so that I can
        remove 'design' or 'test' projects no longer needed in the system"

        I'm pulling my hair out reading these things as all of the user
        stories are very data centric (save, load, delete, bulk load, change
        this, change that...). The intended use of the application they're
        building is data centric as well (it's a maintainenance tool for a
        data-driven program that manages widgets).

        Am I being too critical here or are there some examples or techniques
        that you guys have used in the past to try to curb this type of user
        story construction?

        Thanks.




        --
        I rather like the idea of being thought of as a shit  - a common conceit among those who don't realize just how shitty they really are." - Clive James
      • Oldfield, Paul (ASPIRE)
        (responding to Bill) ... I agree with Keith, what you have seems more like a solution than a goal. In general, if you want to get more abstract, to uncover the
        Message 3 of 6 , May 1, 2007
        • 0 Attachment
          (responding to Bill)

          > Am I being too critical here or are there some examples
          > or techniques that you guys have used in the past to
          > try to curb this type of user story construction?

          I agree with Keith, what you have seems more like a
          solution than a goal.

          In general, if you want to get more abstract, to uncover
          the goal from the solution, ask questions that start "Why?".
          If you want to get more specific, less abstract; ask
          questions that start with the word "How?".

          The problem that can occur is that when the customer has
          a specific solution in mind, they will have made design
          decisions. They aren't always the best people to make
          these decisions. The customer may, of course, want a
          specific solution, and may have a good reason for wanting
          that solution. OTOH, they may have old technology in mind
          that blinds them to the opportunity to innovate.

          Paul Oldfield
        • Gregor Dodson
          ... the goal from the solution, ask questions that start Why? . If you want to get more specific, less abstract; ask questions that start with the word
          Message 4 of 6 , May 2, 2007
          • 0 Attachment
            >>In general, if you want to get more abstract, to uncover
            the goal from the solution, ask questions that start "Why?".
            If you want to get more specific, less abstract; ask
            questions that start with the word "How?".

            Great advice Paul, thanks! You captured it in such a succinct way.

            Gregor


            On 5/1/07, Oldfield, Paul (ASPIRE) <Paul.Oldfield@...> wrote:

            (responding to Bill)

            > Am I being too critical here or are there some examples
            > or techniques that you guys have used in the past to
            > try to curb this type of user story construction?

            I agree with Keith, what you have seems more like a
            solution than a goal.

            In general, if you want to get more abstract, to uncover
            the goal from the solution, ask questions that start "Why?".
            If you want to get more specific, less abstract; ask
            questions that start with the word "How?".

            The problem that can occur is that when the customer has
            a specific solution in mind, they will have made design
            decisions. They aren't always the best people to make
            these decisions. The customer may, of course, want a
            specific solution, and may have a good reason for wanting
            that solution. OTOH, they may have old technology in mind
            that blinds them to the opportunity to innovate.

            Paul Oldfield




            --
            I rather like the idea of being thought of as a shit  - a common conceit among those who don't realize just how shitty they really are." - Clive James
          • Nicholas Cancelliere
            These stories seem like they ve been created by the development team, or a very technical Product Owner (who was maybe a former developer)? For users stories I
            Message 5 of 6 , May 2, 2007
            • 0 Attachment
               
              These stories seem like they've been created by the development team, or a very technical Product Owner (who was maybe a former developer)?
               
              For users stories I like the forumla Mike Cohn suggests in his book:
               
                   {User} needs/can/wants to {some fn} so that/in order to {some business value}.
               
              Then to test you should be able to look at a story and say "Who's the user here," "What is it that want to do," "Why do they want to do that?"
               
              So lets look at the last one:
               
              Who is the user?   The administrator.
              What is it the want to do?  Delete projects.
              Why do they want do to that?  Because it's no longer needed in the system.
               
              So the story is okay, to be a little more clean I'd just maybe rewrite it to be:
               
                   Administrators can delete projects no longer needed in the system.
               
              Writing the story this way then opens it up for discussion.  Well how do you know it's no longer needed?  Do we let them delete projects that have tasks still open/active?  Requirements should be captured as acceptance tests.

              I hope this helps.  I would try to go to the users and have them generate the stories.  The development team shouldn't be doing this.  If you're the BA - then it might be your job (working under the Product Owner) to be helping with this, I don't know.  I just know the developers are not the right folks to write stories.
               
              Nicholas
               
               

               
              On 5/1/07, Bil Simser <bsimser@...> wrote:

              I'm struggling a bit with a team that has come to me with a set of
              what they belive are user stories for their project. Here's a sampling:

              "As an administrator I can create a project so that it can be used as
              a starting point for other project components"
              "As an administrator I can modify a project so that project level
              information is changed to reflect requirements of a project in
              a 'design' state"
              "As an administrator I can delete a project so that I can
              remove 'design' or 'test' projects no longer needed in the system"

              I'm pulling my hair out reading these things as all of the user
              stories are very data centric (save, load, delete, bulk load, change
              this, change that...). The intended use of the application they're
              building is data centric as well (it's a maintainenance tool for a
              data-driven program that manages widgets).

              Am I being too critical here or are there some examples or techniques
              that you guys have used in the past to try to curb this type of user
              story construction?

              Thanks.




              --
              Nicholas Cancelliere, Austin TX
              "The wide world is all about you: you can fence yourselves in, but you cannot for ever fence it out." -Gildor, Fellowship of the Ring (Lord of the Rings)
            Your message has been successfully submitted and would be delivered to recipients shortly.