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

Backlog items - stories, splitting and definition of done...

Expand Messages
  • Tim Sharrock
    Hi folks, I don t think the project I am working on can even really be described as Scrumbut yet, but I am trying to learn and move in a more agile
    Message 1 of 10 , Aug 5, 2009
      Hi folks,

      I don't think the project I am working on can even really be described
      as "Scrumbut" yet, but I am trying to learn and move in a more agile direction.

      I am working on a relatively small program which works with some of
      our main products - translating files from one format to another that
      our main products can use. They are computer-aided-design files, and
      I am using third-party libraries to do much of the work.

      Looking at the backlog items I have (mainly written by me, but I have
      discussed them with the nearest thing I have to a Product Owner) I am
      finding it difficult work out what would count as done, and whether I
      should split the stories down more, or spin off sub-stories.

      an example:

      As an administrator at a customer site
      I want to be able to install and sanity test ProductX
      so that my users can use it.

      In some sense that is now "done" - I have an install package that does
      that - for some definition of sanity, but my notes include "relatively minor" issues like like

      Which sample data files should we use? It currently uses some old
      files from a previous release, and I am sure there are better ones I
      could use, but I don't have any to hand?

      Some of the installed shortcuts are not ideal, and could be tidied
      up, but it would not stop a release...

      What is the best way to handle this sort of thing? I am leaning
      towards ticking "done", but adding some extra backlog items, eg

      As a ProductX support engineer
      I want the supplied test data to be good examples
      so that I can show prospective users what results they might expect

      and this new split-off item can then prioritised separately, and left
      for later, while the main item is not clogging up "in progress".

      Does that seem a reasonable approach?

      Tim


      --
      Tim Sharrock mailto:tim@...
    • Jacob
      Hello, Firstly I would have split the story as soon as I saw an and in it, that would have given you a separate story about testing. Are you writing
      Message 2 of 10 , Aug 5, 2009
        Hello,

        Firstly I would have split the story as soon as I saw an 'and' in it, that would have given you a separate story about testing.

        Are you writing acceptance tests for your stories?

        If the work completde satisfies the acceptance tests then the story is done.

        If the PO forgot to put something in there, or if you need some additional work, then you will need another story.



        On Wed, Aug 5, 2009 at 5:58 PM, Tim Sharrock <tim@...> wrote:
        Hi folks,

        I don't think the project I am working on can even really be described
        as "Scrumbut" yet, but I am trying to learn and move in a more agile direction.

        I am working on a relatively small program which works with some of
        our main products - translating files from one format to another that
        our main products can use. They are computer-aided-design files, and
        I am using third-party libraries to do much of the work.

        Looking at the backlog items I have (mainly written by me, but I have
        discussed them with the nearest thing I have to a Product Owner) I am
        finding it difficult work out what would count as done, and whether I
        should split the stories down more, or spin off sub-stories.

        an example:

          As an administrator at a customer site
          I want to be able to install and sanity test ProductX
          so that my users can use it.

        In some sense that is now "done" - I have an install package that does
        that - for some definition of sanity, but my notes include "relatively minor" issues like like

          Which sample data files should we use? It currently uses some old
          files from a previous release, and I am sure there are better ones I
          could use, but I don't have any to hand?

          Some of the installed shortcuts are not ideal, and could be tidied
          up, but it would not stop a release...

        What is the best way to handle this sort of thing? I am leaning
        towards ticking "done", but adding some extra backlog items, eg

          As a ProductX support engineer
          I want the supplied test data to be good examples
          so that I can show prospective users what results they might expect

        and this new split-off item can then prioritised separately, and left
        for later, while the main item is not clogging up "in progress".

        Does that seem a reasonable approach?

        Tim


        --
        Tim Sharrock     mailto:tim@...



        ------------------------------------

        To Post a message, send it to:   scrumdevelopment@...
        To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...! Groups Links

        <*> To visit your group on the web, go to:
           http://groups.yahoo.com/group/scrumdevelopment/

        <*> Your email settings:
           Individual Email | Traditional

        <*> To change settings online go to:
           http://groups.yahoo.com/group/scrumdevelopment/join
           (Yahoo! ID required)

        <*> To change settings via email:
           mailto:scrumdevelopment-digest@yahoogroups.com
           mailto:scrumdevelopment-fullfeatured@yahoogroups.com

        <*> To unsubscribe from this group, send an email to:
           scrumdevelopment-unsubscribe@yahoogroups.com

        <*> Your use of Yahoo! Groups is subject to:
           http://docs.yahoo.com/info/terms/


      • Peter Stevens (cal)
        Hi Tim, First - congrats on using User Stories to define your requirements! They make it so much easier to understand what is needed and why. There are two
        Message 3 of 10 , Aug 5, 2009
          Hi Tim,

          First -> congrats on using User Stories to define your requirements! They make it so much easier to understand what is needed and why.

          There are two dimension to done - the product owner's perspective (acceptance) and the team's perspective (quality). The former is addressed the acceptance criteria and latter through the definition of done.

          Basically, the team may not submit a feature to the product owner for acceptance before it has internally assured the quality of said feature. So your definition of done might look like this:
          1. Code checked into source control
          2. Code reviewed or pair programmed
          3. Unit tests written and green
          4. Feature automatically deployed on acceptance testing system
          5. Customer acceptance tests verified (to the best of team's ability)
          How much your team includes in the definition of done is a statement of their level of engineering. The more they can include, the better their practices and the less undone work will be left over at the end of the sprint. (How do you know if you have undone work? Ask the team at the sprint review if they can release the software in its current state. If the answer is no, they have undone work).

          The other dimension is acceptance. Is it what the customer asked for? I have found it effective to ask the product owner how to demo the desired feature. This is a workflow, a series of steps to show that the feature is working. (There may be formal acceptance critiea, but they are not the same thing).

          How do you know if the story is too big for a sprint? Look at that how to demo workflow. If that workflow is long and complicated, or if there are multiple independent workflows needed, then that story is a candidate for being sliced into smaller, more bite sized morsels.

          Acutally, there is a third aspect to done: completeness or fitness for use. It may take multiple sprints to get a complete feature which can be released to the customer. E.g. you need a login function and you need a registration function and you need a recover lost password function. You might not get them all done in one sprint. A big hurdle in accepting agile is the recognition that a story can be done internally, or even accepted, but not yet be in a state where it can be given to the customer. It's the product owner's call when the feature is complete....

          Hope this clears things up...

          Cheers,

          Peter

          Tim Sharrock wrote:
          Hi folks,
          
          I don't think the project I am working on can even really be described
          as "Scrumbut" yet, but I am trying to learn and move in a more agile direction.
          
          I am working on a relatively small program which works with some of
          our main products - translating files from one format to another that
          our main products can use. They are computer-aided-design files, and
          I am using third-party libraries to do much of the work.
          
          Looking at the backlog items I have (mainly written by me, but I have
          discussed them with the nearest thing I have to a Product Owner) I am
          finding it difficult work out what would count as done, and whether I
          should split the stories down more, or spin off sub-stories.
          
          an example:
          
             As an administrator at a customer site
             I want to be able to install and sanity test ProductX
             so that my users can use it.
          
          In some sense that is now "done" - I have an install package that does
          that - for some definition of sanity, but my notes include "relatively minor" issues like like
          
             Which sample data files should we use? It currently uses some old
             files from a previous release, and I am sure there are better ones I
             could use, but I don't have any to hand?
          
             Some of the installed shortcuts are not ideal, and could be tidied
             up, but it would not stop a release...
          
          What is the best way to handle this sort of thing? I am leaning
          towards ticking "done", but adding some extra backlog items, eg
          
             As a ProductX support engineer
             I want the supplied test data to be good examples
             so that I can show prospective users what results they might expect
          
          and this new split-off item can then prioritised separately, and left
          for later, while the main item is not clogging up "in progress".
          
          Does that seem a reasonable approach?
          
          Tim
          
          
            

        • Ron Jeffries
          Hello, Tim. On Wednesday, August 5, 2009, at 10:58:41 AM, you ... Yes. I d favor many small stories with tight definitions of done to big vague extendible
          Message 4 of 10 , Aug 5, 2009
            Hello, Tim. On Wednesday, August 5, 2009, at 10:58:41 AM, you
            wrote:

            > Looking at the backlog items I have (mainly written by me, but I have
            > discussed them with the nearest thing I have to a Product Owner) I am
            > finding it difficult work out what would count as done, and whether I
            > should split the stories down more, or spin off sub-stories.

            > an example:

            > As an administrator at a customer site
            > I want to be able to install and sanity test ProductX
            > so that my users can use it.

            > In some sense that is now "done" - I have an install package that does
            > that - for some definition of sanity, but my notes include
            > "relatively minor" issues like like

            > Which sample data files should we use? It currently uses some old
            > files from a previous release, and I am sure there are better ones I
            > could use, but I don't have any to hand?

            > Some of the installed shortcuts are not ideal, and could be tidied
            > up, but it would not stop a release...

            > What is the best way to handle this sort of thing? I am leaning
            > towards ticking "done", but adding some extra backlog items, eg

            > As a ProductX support engineer
            > I want the supplied test data to be good examples
            > so that I can show prospective users what results they might expect

            > and this new split-off item can then prioritised separately, and left
            > for later, while the main item is not clogging up "in progress".

            > Does that seem a reasonable approach?

            Yes. I'd favor many small stories with tight definitions of done to
            big vague extendible ones.

            Ron Jeffries
            www.XProgramming.com
            www.xprogramming.com/blog
            But the attitude of faith is to let go, and become open to
            truth, whatever it might turn out to be. -- Alan Watts
          • Tim Sharrock
            ... ... ... interesting :). I do worry about drowning in stories - my first list had about sixty stories in, and I have had some difficulty in getting anyone
            Message 5 of 10 , Aug 5, 2009
              > On Wed, Aug 5, 2009 at 5:58 PM, I, Tim Sharrock <tim@...> wrote:
              >> ... I am
              >> finding it difficult work out what would count as done, and whether I
              >> should split the stories down more, or spin off sub-stories.
              >>
              >> an example:
              >> As an administrator at a customer site
              >> I want to be able to install and sanity test ProductX
              >> so that my users can use it.
              ...

              On Wednesday, August 5, 2009, 4:23:46 PM, Jacob wrote:
              > Firstly I would have split the story as soon as I saw an 'and' in it, that
              > would have given you a separate story about testing.

              interesting :). I do worry about drowning in stories - my first list
              had about sixty stories in, and I have had some difficulty in getting
              anyone else to pay significant attention to it - let alone do detailed
              prioritisation. My manager's manager, who is formally the Product
              owner for several large teams, and is heavily overloaded has I think
              one story in mind "handle X-format", with acceptance test "can import
              any X-format file and produce the right answers".

              The "deputy product owner" has the time to be more help, but still
              gets somewhat overwhelmed.

              > Are you writing acceptance tests for your stories?

              For many of the stories I can test with a framework I have eg
              Translate 5 elements from input file xxxx.yyy starting at element 235
              and check that the results match the reference (and check the
              reference manually when I add a new test or change the behaviour), but
              too many of the stories are hard to check that way :(

              As an occasional user of ProductX
              I want it to be easy to use
              So I can be productive without spending time reading

              > If the work completde satisfies the acceptance tests then the story is done.

              unfortunately I have never had an acceptance test written for me by
              someone else

              > If the PO forgot to put something in there, or if you need some additional
              > work, then you will need another story.

              I don't have enough of a real PO at the moment. I wish I did!

              thanks for the help

              Tim

              --
              Tim Sharrock mailto:tim@...
            • Ron Jeffries
              Hello, Tim. On Wednesday, August 5, 2009, at 1:25:00 PM, you ... What do you need to know, other than which one to do next? Ron Jeffries www.XProgramming.com
              Message 6 of 10 , Aug 5, 2009
                Hello, Tim. On Wednesday, August 5, 2009, at 1:25:00 PM, you
                wrote:

                > interesting :). I do worry about drowning in stories - my first list
                > had about sixty stories in, and I have had some difficulty in getting
                > anyone else to pay significant attention to it - let alone do detailed
                > prioritisation.

                What do you need to know, other than which one to do next?

                Ron Jeffries
                www.XProgramming.com
                www.xprogramming.com/blog
                Example isn't another way to teach, it is the only way to teach.
                --Albert Einstein
              • Tim Sharrock
                ... I suppose it depends which hat I am wearing at the time. The group I am in, and the company as a whole, are not I feel very far along an agile transition.
                Message 7 of 10 , Aug 5, 2009
                  On Wednesday, August 5, 2009, 6:34:52 PM, Ron Jeffries wrote:

                  > Hello, Tim. On Wednesday, August 5, 2009, at 1:25:00 PM, you
                  > wrote:

                  >> interesting :). I do worry about drowning in stories - my first list
                  >> had about sixty stories in, and I have had some difficulty in getting
                  >> anyone else to pay significant attention to it - let alone do detailed
                  >> prioritisation.

                  > What do you need to know, other than which one to do next?

                  I suppose it depends which hat I am wearing at the time. The group
                  I am in, and the company as a whole, are not I feel very far along an
                  agile transition. I do get asked, by several different groups of
                  people, about delivery dates, when I don't know what the scope required
                  is...

                  In the company world this whole product is just a little fish, and
                  forms part of one feature, without any real acceptance criteria, and
                  the overall dates are constrained by the time taken to get the big
                  fish from "code freeze" to "customer release", which is far too long
                  really, especially for the little fish. I find this frustrating, but
                  have not managed to do much about it.

                  Tim
                  --
                  Tim Sharrock mailto:tim@...
                • Elizabeth V Woodward
                  Hi, The Scrum Community within IBM has been working on a book to be published through Pearson Education that will help teams that are using Scrum in a
                  Message 8 of 10 , Aug 5, 2009

                    Hi,

                    The Scrum Community within IBM has been working on a book to be published through Pearson Education that will help teams that are using Scrum in a large-scale, distributed environment. We've been conducting discussion sessions on various aspects of distributed Scrum and have been developing chapters with tips, recommendations, do's and don'ts, and "how to" suggestions.

                    Having thorough reviews/feedback from members of the broader Scrum and Agile communities as we go along will help to make the content more robust and more practical for all distributed teams--Scrum or not. So, if you are working in a distributed environment and have time to provide feedback, we would be very grateful to get your thoughts.

                    You can find the early drafts of the first three chapters at http://www.distributedscrum.com.

                    Thanks!
                    -elizabeth
                  • Ron Jeffries
                    Hello, Tim. On Wednesday, August 5, 2009, at 2:21:59 PM, you ... You could pick a date they like and put in the most important stuff ... If yours was ready,
                    Message 9 of 10 , Aug 5, 2009
                      Hello, Tim. On Wednesday, August 5, 2009, at 2:21:59 PM, you
                      wrote:

                      >> What do you need to know, other than which one to do next?

                      > I suppose it depends which hat I am wearing at the time. The group
                      > I am in, and the company as a whole, are not I feel very far along an
                      > agile transition. I do get asked, by several different groups of
                      > people, about delivery dates, when I don't know what the scope required
                      > is...

                      You could pick a date they like and put in the most important stuff
                      ...

                      > In the company world this whole product is just a little fish, and
                      > forms part of one feature, without any real acceptance criteria, and
                      > the overall dates are constrained by the time taken to get the big
                      > fish from "code freeze" to "customer release", which is far too long
                      > really, especially for the little fish. I find this frustrating, but
                      > have not managed to do much about it.

                      If yours was ready, would they release it?

                      Ron Jeffries
                      www.XProgramming.com
                      www.xprogramming.com/blog
                      Master your instrument, master the music,
                      and then forget all that *!xy!@ and just play. -- Charlie Parker
                    • Tim Sharrock
                      ... yes, that is what I am trying to do :) ... I fear not, unfortunately. I would much rather have my little one out, in the hands of customers and with real
                      Message 10 of 10 , Aug 5, 2009
                        On Wednesday, August 5, 2009, 9:19:47 PM, Ron Jeffries wrote:

                        > Hello, Tim. On Wednesday, August 5, 2009, at 2:21:59 PM, you
                        > wrote:

                        >>> What do you need to know, other than which one to do next?

                        >> I suppose it depends which hat I am wearing at the time. The group
                        >> I am in, and the company as a whole, are not I feel very far along an
                        >> agile transition. I do get asked, by several different groups of
                        >> people, about delivery dates, when I don't know what the scope required
                        >> is...

                        > You could pick a date they like and put in the most important stuff
                        > ...

                        yes, that is what I am trying to do :)

                        >> In the company world this whole product is just a little fish, and
                        >> forms part of one feature, without any real acceptance criteria, and
                        >> the overall dates are constrained by the time taken to get the big
                        >> fish from "code freeze" to "customer release", which is far too long
                        >> really, especially for the little fish. I find this frustrating, but
                        >> have not managed to do much about it.

                        > If yours was ready, would they release it?

                        I fear not, unfortunately. I would much rather have my little one out,
                        in the hands of customers and with real feedback, and I have been
                        agitating for it (after all it is how we used to do it - I think three
                        days was my fastest cycle-time from change-release-in-the-post, but
                        now five months seems to be about as fast as we can manage :( )

                        Tim
                        --
                        Tim Sharrock mailto:tim@...
                      Your message has been successfully submitted and would be delivered to recipients shortly.