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

Re: [scrumdevelopment] User stories feeling like CRUD tasks

Expand Messages
  • 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 1 of 6 , May 1 1:01 PM
    • 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 2 of 6 , May 1 11:53 PM
      • 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 3 of 6 , May 2 9:51 AM
        • 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 4 of 6 , May 2 2:17 PM
          • 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.