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

Re: [scrumdevelopment] breaking up large stories

Expand Messages
  • Michael Wollin
    As was pointed out to me on this board not long ago, you can slice the story and implement a portion of it such that the portion you ve implemented is
    Message 1 of 21 , May 3 10:18 AM
      As was pointed out to me on this board not long ago, you can slice the story and implement a portion of it such that the portion you've implemented is production-ready. That does not mean that you would actually release it to production. In our case, we had an epic that said, "Port the entire javascript user interface to the latest version of the UI library." Since the new version of this library is incompatible with the old version, we can't release this is pieces. It's all or nothing. So we broke it into subtasks (smaller stories) that can be completed within a two-week sprint. Although not releasable to production, the level of testing we are doing is the same and we can still demo our progress at the end of the sprint to the stakeholders. 

      Michael

      On May 3, 2008, at 10:00 AM, Jason McIntosh wrote:

      I've often found that people naturally assume things can't be broken down.  We see that alot on our team.. but almost always if the team is willing to take the time and talk it through they can be broken down in such a way that you're still delivering testable value to the users.  Things like don't do any validations on the data entered, don't allow for anything off the happy path, if it's a story where the user wants to enter value in 50 different fields, ask what the system should do if only 10 of those are entered (and then work the story from that angle), etc.

    • Jane Sherman
      Thanks for the suggestions everyone. I appreciate it. The user story we implemented was allowing guest checkout on our ecommerce site. There s certainly a
      Message 2 of 21 , May 3 8:24 PM

        Thanks for the suggestions everyone.  I appreciate it.

         

        The user story we implemented was allowing guest checkout on our ecommerce site.    There’s certainly a happy path, lots of edge cases,  changes to email which allow folks to view order status without having an account, etc.    I can envision how to break the functionality in to small stories and code/test those small stories.   But we can’t release it into production until most of its complete.   In the mean time, we’ve got other changes going on in the same code base.    It’s all checked into cvs and we produce one big EAR file that gets pushed to production.    We can’t hold off pushing other changes waiting for the guest checkout story to be complete.    So this would lead us to having multiple development branches.   And those branches would need to maintained as we continue to push changes into production while we’re working on Guest Checkout. 

         

        I’m getting lots of push back from the developers that maintaining these multiple branches isn’t going to work well.     So I’m looking for some examples where folks maintain multiple branches of code when stories cross over Sprints.  

         

        Thanks again.

         

        From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Michael Wollin
        Sent: Saturday, May 03, 2008 10:18 AM
        To: scrumdevelopment@yahoogroups.com
        Subject: Re: [scrumdevelopment] breaking up large stories

         

        As was pointed out to me on this board not long ago, you can slice the story and implement a portion of it such that the portion you've implemented is production-ready. That does not mean that you would actually release it to production. In our case, we had an epic that said, "Port the entire javascript user interface to the latest version of the UI library." Since the new version of this library is incompatible with the old version, we can't release this is pieces. It's all or nothing. So we broke it into subtasks (smaller stories) that can be completed within a two-week sprint. Although not releasable to production, the level of testing we are doing is the same and we can still demo our progress at the end of the sprint to the stakeholders. 

         

        Michael

         

        On May 3, 2008, at 10:00 AM, Jason McIntosh wrote:


        I've often found that people naturally assume things can't be broken down.  We see that alot on our team.. but almost always if the team is willing to take the time and talk it through they can be broken down in such a way that you're still delivering testable value to the users.  Things like don't do any validations on the data entered, don't allow for anything off the happy path, if it's a story where the user wants to enter value in 50 different fields, ask what the system should do if only 10 of those are entered (and then work the story from that angle), etc.

         

      • Dmitry Beransky
        Jane, Another way to solve the problem is to switch from cvs to a SCM that makes branch management easier, like Subversion, or if your developer are not too
        Message 3 of 21 , May 3 11:36 PM
          Jane,

          Another way to solve the problem is to switch from cvs to a SCM that
          makes branch management easier, like Subversion, or if your developer
          are not too comfortable with advanced SCM features like
          branches/merges and you can afford a commercial tool, than I'd
          recommend looking at Perforce or AccuRev.


          Dmitry

          On Sat, May 3, 2008 at 8:24 PM, Jane Sherman <janes@...> wrote:
          >
          >
          >
          >
          >
          >
          > Thanks for the suggestions everyone. I appreciate it.
          >
          >
          >
          > The user story we implemented was allowing guest checkout on our ecommerce
          > site. There's certainly a happy path, lots of edge cases, changes to
          > email which allow folks to view order status without having an account, etc.
          > I can envision how to break the functionality in to small stories and
          > code/test those small stories. But we can't release it into production
          > until most of its complete. In the mean time, we've got other changes
          > going on in the same code base. It's all checked into cvs and we produce
          > one big EAR file that gets pushed to production. We can't hold off
          > pushing other changes waiting for the guest checkout story to be complete.
          > So this would lead us to having multiple development branches. And those
          > branches would need to maintained as we continue to push changes into
          > production while we're working on Guest Checkout.
          >
          >
          >
          > I'm getting lots of push back from the developers that maintaining these
          > multiple branches isn't going to work well. So I'm looking for some
          > examples where folks maintain multiple branches of code when stories cross
          > over Sprints.
          >
          >
          >
          > Thanks again.
          >
          >
          >
          >
          > From: scrumdevelopment@yahoogroups.com
          > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Michael Wollin
          > Sent: Saturday, May 03, 2008 10:18 AM
          > To: scrumdevelopment@yahoogroups.com
          > Subject: Re: [scrumdevelopment] breaking up large stories
          >
          >
          >
          >
          >
          > As was pointed out to me on this board not long ago, you can slice the story
          > and implement a portion of it such that the portion you've implemented is
          > production-ready. That does not mean that you would actually release it to
          > production. In our case, we had an epic that said, "Port the entire
          > javascript user interface to the latest version of the UI library." Since
          > the new version of this library is incompatible with the old version, we
          > can't release this is pieces. It's all or nothing. So we broke it into
          > subtasks (smaller stories) that can be completed within a two-week sprint.
          > Although not releasable to production, the level of testing we are doing is
          > the same and we can still demo our progress at the end of the sprint to the
          > stakeholders.
          >
          >
          >
          >
          >
          > Michael
          >
          >
          >
          >
          >
          > On May 3, 2008, at 10:00 AM, Jason McIntosh wrote:
          >
          >
          > I've often found that people naturally assume things can't be broken down.
          > We see that alot on our team.. but almost always if the team is willing to
          > take the time and talk it through they can be broken down in such a way that
          > you're still delivering testable value to the users. Things like don't do
          > any validations on the data entered, don't allow for anything off the happy
          > path, if it's a story where the user wants to enter value in 50 different
          > fields, ask what the system should do if only 10 of those are entered (and
          > then work the story from that angle), etc.
          >
          >
          >
          >
          >
          >
          >
          >
        • Ilja Preuss
          ... I m with your developers here. Using branches for this is far from optimal, in my experience. If nothing else, it makes development more unpredictable,
          Message 4 of 21 , May 3 11:47 PM
            Jane Sherman wrote:

            > I’m getting lots of push back from the developers that maintaining these
            > multiple branches isn’t going to work well. So I’m looking for some
            > examples where folks maintain multiple branches of code when stories
            > cross over Sprints.

            I'm with your developers here. Using branches for this is far from
            optimal, in my experience. If nothing else, it makes development more
            unpredictable, because it is hard to predict how much effort merging
            will take.

            There are alternatives: what we often do in these situations is
            implementing the new feature that it easily can be "switched off". In
            simpler cases, that just boils down to a simple if statement that checks
            whether a "development" property is set. In more complex situations, we
            will implement the new feature as a plugin. A nice side effect of the
            latter solution is that it forces you to develop a more modular
            architecture.

            Does that help?

            Cheers, Ilja
          • Ilja Preuss
            ... I agree that there are better SCMs than CVS for branching. I can t imagine that there is one that can solve all the problems that come with heavy
            Message 5 of 21 , May 3 11:49 PM
              Dmitry Beransky wrote:
              > Jane,
              >
              > Another way to solve the problem is to switch from cvs to a SCM that
              > makes branch management easier, like Subversion, or if your developer
              > are not too comfortable with advanced SCM features like
              > branches/merges and you can afford a commercial tool, than I'd
              > recommend looking at Perforce or AccuRev.

              I agree that there are better SCMs than CVS for branching. I can't
              imagine that there is one that can solve all the problems that come with
              heavy refactoring. So branching always inhibits refactoring to me.

              Cheers, Ilja
            • Peter Stevens (cal)
              Hi Jane, This is a difficult problem and IMHO the aspect of Scrum which challenges developers more than any other. You do not have to push code into production
              Message 6 of 21 , Oct 5, 2009
                Hi Jane,

                This is a difficult problem and IMHO the aspect of Scrum which challenges developers more than any other.

                You do not have to push code into production after every sprint. Push code into production when you product owner finds that fitness for use has been achieved. It may take more than one sprint to get there.

                I have found it useful to insist that Product Backlog Items (aka "Stories") should be formulated as a complete sentence. "As a user, I can log on to the system". Even if it's not in the strict from user story, you want to have an understanding of what capability should be present to satisfy the story.

                The second piece of information which the team needs is "how to demo". This is a work flow, i.e. a series of steps to show that the desired functionality has been implemented. By looking at the steps in the workflow, you can identify logical points to split stories.

                This combination of Title + Workflow define the limits of the story. If the goal of the title has been achieved or the code the developer is working does not produce results visible in the workflow, then the functionality he is working on is out of scope of the story (even though it may be in spec for the entire product!). He should report this to the scrum master or product owner for to be placed (and prioritized) in the Product Backlog as a new story.

                Hope this helps!

                Kind regards,

                Peter Stevens


                Jane Sherman wrote:

                We’re really struggling with breaking up large user stories into two weeks Sprints.   We have one story that’s really frustrating to the team in particular.    It’s a story where most of the parts need to roll into production at the same time.   (The website flow changes dramatically, emails have to match the new flow, etc.)     But we can’t complete all of the parts in two weeks.    We also completely underestimated the amount of development it would take.      Our first Sprint was for creative design to get their parts done.   The second Sprint was for development.   But we weren’t done at the end of the second Sprint so we rolled it into the third Sprint and didn’t push code for the second Sprint.    This means that the other stories in the second Sprint that were ready didn’t go either.  

                We’re finishing up the code this Sprint, but it’s still kind of tight.    The developers are wondering how others handle the code management aspect of this.   They’re very resistant to multiple code branches that have to be maintained, but believe that checking in code when it is completed is safer than just not checking it in.    We use cvs.   Do folks really maintain multiple branches and just merge the code as needed?   

                 

                What does QA do?   If we have some stories that will truly be done in the Sprint and some that cross Sprints, then they’ve got a branch that’s going to production and a branch that’s not going into production.  In the ideal world the QA team would QA the completed work even if it’s not going into production, so they’d need to test both branches?

                 

                For a larger story, if we had valid estimates, we could break up the work into reasonable chunks across Sprint – that’s certainly do-able.   But then no code would get pushed to production until this larger story was complete?   All of the tiny stuff would wait?  

                 

                I feel like the Agile purist might tell us to only work on this Story, but that just doesn’t seem realistic.   Our Sprints usually consist of one or two larger stories and a handful of important tiny things.   And actually, not all of the team members can work on the one large story.   They’d need something to do.

                 

                 

                Jane Sherman

                Project Manager

                Alibris, Inc.

                 

                 


              • JackM
                Hi Jane, All great questions. I will try to answer each of your specific issues. First out let me say that all agile ists agree that the smaller you can make
                Message 7 of 21 , Oct 6, 2009
                  Hi Jane,

                  All great questions. I will try to answer each of your specific issues.

                  First out let me say that all agile'ists agree that the smaller you can make the stories the better. Breaking stories down is no easy feat. So don't feel like you're alone on this. But it can be done and you will get push-back on this for sure.

                  At a minimum though you should ensure that they're small enough to be able to complete the story in one sprint. I realize that problems may persist that force you to continue a story into the next sprint but you should try to avoid planning it that way.

                  If you are mixing very small stories (that you know you will 100% definitely finish in the sprint) with larger stories which you know there is risk in finishing it, then I would branch the code. Especially if you intend going live on production with the smaller stories at the end of the sprint.

                  What's interesting is why the team failed to come even remotely close on estimating the original size - lot's to learn in the retrospective.

                  In regards to you comment "not all the team members can work on the one large story. They'd need something to do. When I hear a comment like this I always ask, are the developers writing unit tests, automated functional tests, integration tests. Can you do pair programming? etc. I find there is always something to do to keep developers busy to produce well crafted code that isn't buggy.

                  I must point out that you don't need to go live on production servers every sprint (that's not a requirement although I like to do it that way). So it's possible to go a couple sprints before you go live. So please don't worry about that. But if there is stuff that MUST go live, don't mix it with high risk stuff that most likely wont get finished.

                  It sounds to me like the team is taking on too much. You have to set the bar high here ... i.e. whatever you start in the sprint must be completed in the sprint and must be documented, unit tested, functionally tested and acceptance tested i.e. DONE

                  I hope this helps you. Feel free to shoot back any questions

                  jack
                  blog.agilebuddy.com
                  twitter.com/agilebuddy
                  www.agilebuddy.com
                • Adrian Howard
                  Hi Jack, On 6 Oct 2009, at 16:22, JackM wrote: [snip] ... [snip] Just to be hyper-niggly I think you can make stories too small. I ve was once on a team where
                  Message 8 of 21 , Oct 6, 2009
                    Hi Jack,

                    On 6 Oct 2009, at 16:22, JackM wrote:

                    [snip]
                    > First out let me say that all agile'ists agree that the smaller you
                    > can make the stories the better. Breaking stories down is no easy
                    > feat. So don't feel like you're alone on this. But it can be done
                    > and you will get push-back on this for sure.
                    [snip]

                    Just to be hyper-niggly I think you can make stories too small. I've
                    was once on a team where things got broken down past the level where
                    they made real sense to the Customer and that caused nothing but
                    problems. They became technical stories / tasks in everything but name
                    and made building a unit of real useful functionality at the end of
                    the sprint very hard.

                    This does sound rather like the opposite end from the problem the OP
                    is having though :-)

                    Cheers,

                    Adrian
                    --
                    http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
                  • JackM
                    Thanks for your comments Adrian. I can t disagree really with what you say because you are right ... the smaller you make the stories the closer they get to
                    Message 9 of 21 , Oct 6, 2009
                      Thanks for your comments Adrian. I can't disagree really with what you say because you are right ... the smaller you make the stories the closer they get to tasks. But I guess it's a balancing act.

                      There's been quite a lot of discussion about this over on the xp forum. The XP folks definitely agree on very small stories and of equal size mind you. That's hard to do. In fact they don't even suggest that you track tasks. they recommend tracking at the story level only.

                      My opinion on this is that you definitely want stories to be small - not that small that it can't be deciphered by a customer, but definitely small enough that it can be completed in a sprint of either 1 or 2 weeks long.

                      Jack
                      twitter.com/agilebuddy
                      blog.agilebuddy.com
                      www.agilebuddy.com

                      --- In scrumdevelopment@yahoogroups.com, Adrian Howard <adrianh@...> wrote:
                      >
                      > Hi Jack,
                      >
                      > On 6 Oct 2009, at 16:22, JackM wrote:
                      >
                      > [snip]
                      > > First out let me say that all agile'ists agree that the smaller you
                      > > can make the stories the better. Breaking stories down is no easy
                      > > feat. So don't feel like you're alone on this. But it can be done
                      > > and you will get push-back on this for sure.
                      > [snip]
                      >
                      > Just to be hyper-niggly I think you can make stories too small. I've
                      > was once on a team where things got broken down past the level where
                      > they made real sense to the Customer and that caused nothing but
                      > problems. They became technical stories / tasks in everything but name
                      > and made building a unit of real useful functionality at the end of
                      > the sprint very hard.
                      >
                      > This does sound rather like the opposite end from the problem the OP
                      > is having though :-)
                      >
                      > Cheers,
                      >
                      > Adrian
                      > --
                      > http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
                      >
                    • Adrian Howard
                      ... I have to admit I m of that persuasion myself :-) ... Yup... and stories that only just fit into an sprint sound like they re _way_ too long to me. The
                      Message 10 of 21 , Oct 6, 2009
                        On 6 Oct 2009, at 17:20, JackM wrote:

                        > Thanks for your comments Adrian. I can't disagree really with what
                        > you say because you are right ... the smaller you make the stories
                        > the closer they get to tasks. But I guess it's a balancing act.
                        >
                        > There's been quite a lot of discussion about this over on the xp
                        > forum. The XP folks definitely agree on very small stories and of
                        > equal size mind you. That's hard to do. In fact they don't even
                        > suggest that you track tasks. they recommend tracking at the story
                        > level only.

                        I have to admit I'm of that persuasion myself :-)

                        > My opinion on this is that you definitely want stories to be small -
                        > not that small that it can't be deciphered by a customer, but
                        > definitely small enough that it can be completed in a sprint of
                        > either 1 or 2 weeks long.


                        Yup... and stories that only just fit into an sprint sound like
                        they're _way_ too long to me. The risk of failure is just too high.

                        Adrian
                        --
                        http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
                      • Michael James
                        ... I ve also seen them broken small *prematurely*, without team involvement, by people who are accustomed to a plan-driven approach. --mj . . An example
                        Message 11 of 21 , Oct 6, 2009
                          On Oct 6, 2009, at 12:04 PM, Adrian Howard wrote:

                          > Just to be hyper-niggly I think you can make stories too small. I've

                          I've also seen them broken small *prematurely*, without team
                          involvement, by people who are accustomed to a plan-driven approach.


                          --mj
                          .
                          . An example checklist for serious ScrumMasters: http://tinyurl.com/cvdwor
                          . 5-page illustrated summary of Scrum: http://refcardz.dzone.com/refcardz/scrum
                          .
                        • Ron Jeffries
                          Hello, Adrian. On Tuesday, October 6, 2009, at 12:04:13 PM, you ... Stories, by definition, make sense to the customer. Making stories into smaller stories
                          Message 12 of 21 , Oct 6, 2009
                            Hello, Adrian. On Tuesday, October 6, 2009, at 12:04:13 PM, you
                            wrote:

                            > Just to be hyper-niggly I think you can make stories too small. I've
                            > was once on a team where things got broken down past the level where
                            > they made real sense to the Customer and that caused nothing but
                            > problems. They became technical stories / tasks in everything but name
                            > and made building a unit of real useful functionality at the end of
                            > the sprint very hard.

                            Stories, by definition, make sense to the customer. Making stories
                            into smaller stories can never make them not make sense to the
                            customer. Making stories into tasks usually makes them make no sense
                            to the customer, and that's part of why tasks are ... not as good as
                            they might be.

                            Ron Jeffries
                            www.XProgramming.com
                            www.xprogramming.com/blog
                            Some things are impossible. And some things people say are
                            impossible -- because they don't know how to do them. -- Ron Loyd
                          • Ron Jeffries
                            Hello, JackM. On Tuesday, October 6, 2009, at 12:20:15 PM, you ... Well, or a mistake in making them smaller. I see no reason why smaller means like task .
                            Message 13 of 21 , Oct 6, 2009
                              Hello, JackM. On Tuesday, October 6, 2009, at 12:20:15 PM, you
                              wrote:

                              > Thanks for your comments Adrian. I can't disagree really with
                              > what you say because you are right ... the smaller you make the
                              > stories the closer they get to tasks. But I guess it's a balancing act.

                              Well, or a mistake in making them smaller. I see no reason why
                              smaller means "like task".

                              Ron Jeffries
                              www.XProgramming.com
                              www.xprogramming.com/blog
                              Speak the affirmative; emphasize your choice
                              by utterly ignoring all that you reject. -- Ralph Waldo Emerson
                            • JackM
                              They don t need to be but I have seen companies oftern run into that problem as they break stories down. And then the story starts to sound like an
                              Message 14 of 21 , Oct 6, 2009
                                They don't need to be but I have seen companies oftern run into that problem as they break stories down. And then the story starts to sound like an implementation task. I am suggesting that we try to avoid doing that.

                                Jack

                                --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                                >
                                > Hello, JackM. On Tuesday, October 6, 2009, at 12:20:15 PM, you
                                > wrote:
                                >
                                > > Thanks for your comments Adrian. I can't disagree really with
                                > > what you say because you are right ... the smaller you make the
                                > > stories the closer they get to tasks. But I guess it's a balancing act.
                                >
                                > Well, or a mistake in making them smaller. I see no reason why
                                > smaller means "like task".
                                >
                                > Ron Jeffries
                                > www.XProgramming.com
                                > www.xprogramming.com/blog
                                > Speak the affirmative; emphasize your choice
                                > by utterly ignoring all that you reject. -- Ralph Waldo Emerson
                                >
                              • Adrian Howard
                                ... No argument from me there :-) I was slightly disingenuous when I said the stories got broken down past the level where the Customer understood them. The
                                Message 15 of 21 , Oct 7, 2009
                                  On 6 Oct 2009, at 23:21, Ron Jeffries wrote:

                                  > Hello, Adrian. On Tuesday, October 6, 2009, at 12:04:13 PM, you
                                  > wrote:
                                  >
                                  >> Just to be hyper-niggly I think you can make stories too small. I've
                                  >> was once on a team where things got broken down past the level where
                                  >> they made real sense to the Customer and that caused nothing but
                                  >> problems. They became technical stories / tasks in everything but
                                  >> name
                                  >> and made building a unit of real useful functionality at the end of
                                  >> the sprint very hard.
                                  >
                                  > Stories, by definition, make sense to the customer. Making stories
                                  > into smaller stories can never make them not make sense to the
                                  > customer. Making stories into tasks usually makes them make no sense
                                  > to the customer, and that's part of why tasks are ... not as good as
                                  > they might be.


                                  No argument from me there :-)

                                  I was slightly disingenuous when I said the stories got broken down
                                  past the level where the Customer understood them. The Customer (as a
                                  person) did. He was technical and drove the technical breakdown. The
                                  problem was that they no longer made sense as things that would give
                                  value by themselves - so when some were complete and others were not
                                  you ended up with something approaching completely useless.

                                  My own fault. I saw the problem and didn't push hard enough. Need to
                                  be more feisty.

                                  Adrian

                                  --
                                  http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
                                • Mark Levison
                                  Not feisty, better to illuminate the problem show the pain it causes and then wait for a few retrospectives. Eventually people will see the problem for
                                  Message 16 of 21 , Oct 7, 2009
                                    Not feisty, better to illuminate the problem show the pain it causes
                                    and then wait for a few retrospectives. Eventually people will see the
                                    problem for themselves.

                                    Cheers
                                    Mark

                                    On Wednesday, October 7, 2009, Adrian Howard <adrianh@...> wrote:
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    > On 6 Oct 2009, at 23:21, Ron Jeffries wrote:
                                    >
                                    >> Hello, Adrian. On Tuesday, October 6, 2009, at 12:04:13 PM, you
                                    >> wrote:
                                    >>
                                    >>> Just to be hyper-niggly I think you can make stories too small. I've
                                    >>> was once on a team where things got broken down past the level where
                                    >>> they made real sense to the Customer and that caused nothing but
                                    >>> problems. They became technical stories / tasks in everything but
                                    >>> name
                                    >>> and made building a unit of real useful functionality at the end of
                                    >>> the sprint very hard.
                                    >>
                                    >> Stories, by definition, make sense to the customer. Making stories
                                    >> into smaller stories can never make them not make sense to the
                                    >> customer. Making stories into tasks usually makes them make no sense
                                    >> to the customer, and that's part of why tasks are ... not as good as
                                    >> they might be.
                                    >
                                    > No argument from me there :-)
                                    >
                                    > I was slightly disingenuous when I said the stories got broken down
                                    > past the level where the Customer understood them. The Customer (as a
                                    > person) did. He was technical and drove the technical breakdown. The
                                    > problem was that they no longer made sense as things that would give
                                    > value by themselves - so when some were complete and others were not
                                    > you ended up with something approaching completely useless.
                                    >
                                    > My own fault. I saw the problem and didn't push hard enough. Need to
                                    > be more feisty.
                                    >
                                    > Adrian
                                    >
                                    > --
                                    > http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                  Your message has been successfully submitted and would be delivered to recipients shortly.