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

Customer relation

Expand Messages
  • xp_coder
    One thing I m wondering about xp is how does it handle relationships with the customer. I know about planning game practice but I can t see how it can avoid
    Message 1 of 14 , Feb 17, 2005
    View Source
    • 0 Attachment
      One thing I'm wondering about xp is how does it handle relationships
      with the customer.
      I know about planning game practice but I can't see how it can avoid
      problems like a customer telling you: "That's not what I asked for".
      As far as I know, XP doesn't encourage writting minutes of all has
      been said during meetings of discussion with the customer.
      XP prefer to promote communication and trust.
      But is that enough ?
      Have you even experienced such problems with your customers ?
    • Tony Byrne
      Hello xp_coder, x I know about planning game practice but I can t see how it can avoid x problems like a customer telling you: That s not what I asked for .
      Message 2 of 14 , Feb 17, 2005
      View Source
      • 0 Attachment
        Hello xp_coder,

        x> I know about planning game practice but I can't see how it can avoid
        x> problems like a customer telling you: "That's not what I asked for".

        That's the reason why XP expects the customer to develop a set of
        acceptance tests that unambiguously document their requirements.
        The customer is on-site and involved in the stages *after* the
        planning game, so they get rapid feedback on the team's work and have
        every opportunity to steer the development to ensure that they get what they
        asked for.

        x> As far as I know, XP doesn't encourage writting minutes of all has
        x> been said during meetings of discussion with the customer.
        x> XP prefer to promote communication and trust.
        x> But is that enough ?

        Trust can be hard to build, especially where the customer or other
        members of the team have been burned in the past. There's nothing
        wrong with keeping notes of a meeting as an aid to memory, but they
        shouldn't be used as weapons. The seems counter to the XP values.
        There is no substitute for early an honest feedback.

        Regards,

        Tony.

        --
        Tony Byrne
      • Michael Brunton-Spall
        How to avoid the customer saying that wasn t what I wanted ... Don t, encourage the customer to say that whenever your delivering the wrong thing. The
        Message 3 of 14 , Feb 17, 2005
        View Source
        • 0 Attachment
          How to avoid the customer saying "that wasn't what I wanted"...
          Don't, encourage the customer to say that whenever your delivering the
          wrong thing.
          The practice of onsite customer and small releases combines so that you
          will get the feedback early, before you've spent too much time and
          effort going in the wrong way.

          The solution when they say that?
          Offer the customer the two choices, accept the feature as is, or add
          what they really want as a new story for the next iteration, and have it
          planned as normal.

          Do we keep minutes of the meeting, the story cards that define the next
          iteration act as the minutes of the planning meeting.
          Just because XP doesn't say keep minutes of the meeting, doesn't mean
          that you can't do so. But XP does encourage that you only keep
          documentation that is relevant, so if the minutes of meeting don't
          actually provide any useful information, ask yourself why you are
          keeping them?
          If you are keeping minutes in order to protect yourself against the
          customer changing their mind, then you need to go back and Embrace
          Change so to speak, and ensure that you understand what XP is aiming
          for. The customer should be able to change their mind, the aim of XP is
          to equip the development team to keep up, and to ensure that the
          customer is provided with good reliable estimations and feedback showing
          what changing their mind will do to either the schedule or the feature
          list.

          Hope that helps


          Mib
          Software Engineer


          > -----Original Message-----
          > From: xp_coder [mailto:mohamed_talhaoui2000@...]
          > Sent: 17 February 2005 09:17
          > To: extremeprogramming@yahoogroups.com
          > Subject: [XP] Customer relation
          >
          >
          >
          >
          >
          > One thing I'm wondering about xp is how does it handle relationships
          > with the customer.
          > I know about planning game practice but I can't see how it can avoid
          > problems like a customer telling you: "That's not what I asked for".
          > As far as I know, XP doesn't encourage writting minutes of all has
          > been said during meetings of discussion with the customer.
          > XP prefer to promote communication and trust.
          > But is that enough ?
          > Have you even experienced such problems with your customers ?
          >
          >
        • Ron Jeffries
          ... I certainly have experienced such problems, and I believe that many, perhaps most teams, do, especially at the beginning. There are many things that happen
          Message 4 of 14 , Feb 17, 2005
          View Source
          • 0 Attachment
            On Thursday, February 17, 2005, at 4:17:29 AM, xp_coder wrote:

            > One thing I'm wondering about xp is how does it handle relationships
            > with the customer.
            > I know about planning game practice but I can't see how it can avoid
            > problems like a customer telling you: "That's not what I asked for".
            > As far as I know, XP doesn't encourage writting minutes of all has
            > been said during meetings of discussion with the customer.
            > XP prefer to promote communication and trust.
            > But is that enough ?
            > Have you even experienced such problems with your customers ?

            I certainly have experienced such problems, and I believe that many,
            perhaps most teams, do, especially at the beginning.

            There are many things that happen to make these issues less of a
            concern. Here are a few:

            *An XP team has a planning discussion with its Customer at the
            beginning of the week, and shows them what was done at the end of
            the week. This affords lots of chances for the "not what I asked
            for" problem to arise, and lots of practice making sure there's
            agreement before starting.

            *The meetings are held with the whole team, so if NWIAF happened a
            lot, team members would probably start saying "That's what I heard
            you ask for," and a rumble of agreement would flow over the crowd.
            This would help everyone remember to work harder on what is being
            said.

            *The team might develop the habit of drawing pictures on the
            whiteboard of the proposed (GUI) changes, to point back at later and
            see whether what was done agrees with the picture.

            *The team has fixed velocity, so that if the customer asks for a
            change, something must be removed from the table. This happens
            whether the customer changed her mind, or the programmers
            misunderstood. Thus the search for clarity is of more value than the
            search for the culprit.

            *The Customer is present all the time, so the team members can check
            in with them at any time to see if they are doing what is wanted.

            *Some teams document what is going to be done in Excel or a wiki or
            a planning tool that is available to everyone. I don't actually
            recommend this, as I fear that it reduces confirmation and increases
            conflict, but some teams like it.

            *Finally, there are the tests: Customer Acceptance Tests. If the
            Customer specifies, or ideally writes the acceptance tests, two
            valuable things happen:

            A bit more thought goes into the details of the story, in order to
            specify the test, and this extra thought helps keep mind-changing
            away.

            The test, once written, serves as a concrete executable way of
            determining whether the code does or does not do what was asked
            for.

            All of these starred items, and many more, are part of making it all
            work. The main thing, I believe, is to focus on the issue of
            understanding, not on the issue of documentation or a contract.

            Ron Jeffries
            www.XProgramming.com
            It is not the strongest of the species that survive, not the most
            intelligent, but the one most responsive to change. --Charles Darwin
          • yahoogroups@jhrothjr.com
            From: xp_coder To: extremeprogramming@yahoogroups.com
            Message 5 of 14 , Feb 17, 2005
            View Source
            • 0 Attachment
              From: "xp_coder"
              <mohamed_talhaoui2000.at.yahoo.fr@...>
              To: "extremeprogramming@yahoogroups.com"
              <extremeprogramming.at.yahoogroups.com@...>
              Sent: Thursday, February 17, 2005 3:17 AM
              Subject: [XP] Customer relation


              >
              >
              >
              > One thing I'm wondering about xp is how does it handle relationships
              > with the customer.

              The "customer" should be on-site. The reason I put
              "customer" in quotes is that, for your purposes, the
              customer is a collective: it's all stakeholders. At a
              minimum, the "expert user" should be onsite, and the
              Executive Sponsor (the stakehold paying the bills)
              should be very close.

              > I know about planning game practice but I can't see how it can avoid
              > problems like a customer telling you: "That's not what I asked for".

              Other posters have dealt with this.

              > As far as I know, XP doesn't encourage writting minutes of all has
              > been said during meetings of discussion with the customer.

              There are situations (regulatory environments) where you
              do need minutes, but I'd strongly suggest that you limit
              the practice to those kinds of environments.

              > XP prefer to promote communication and trust.
              > But is that enough ?

              Trust sometimes takes a while to develop.

              > Have you even experienced such problems with your customers ?

              Everyone experiances that sooner or later. Customers are
              people, and people are notorious for asking for something
              and then not liking it when they get it.

              The only way I know of to get around it is to deliver
              early so the "customer" can kick the tires, and keep
              your ears open for signs of unstated dissatisfaction.

              John Roth
            • Steven J. Owens
              ... An excellent set of recommendations, but for some reason this phrase really leapt out and grabbed me. Is this an Official XP Slogan(tm)? Maybe it should
              Message 6 of 14 , Feb 18, 2005
              View Source
              • 0 Attachment
                On Thu, Feb 17, 2005 at 06:15:56AM -0500, Ron Jeffries wrote:
                > [...] Thus the search for clarity is of more value than the search
                > for the culprit.

                An excellent set of recommendations, but for some reason this
                phrase really leapt out and grabbed me. Is this an Official XP
                Slogan(tm)? Maybe it should be :-).

                > All of these starred items, and many more, are part of making it all
                > work. The main thing, I believe, is to focus on the issue of
                > understanding, not on the issue of documentation or a contract.

                There's an interesting tension between trust and structure. You
                cannot fiat trust into existence, you have to cultivate it. You can
                impose structure, but even the imposition of structure - besides
                hampering development - can damage or limit the development of trust.

                I'm afraid I'm going to ramble here:

                Communication is a tricky thing. Everybody has their hot
                buttons, and everyone has ways of stumbling into other folks hot
                buttons. I think I've been developing some skill at spotting that
                moment of ignition in myself, and throttling it back long enough to
                look at what was said and how the speaker might have meant something
                else, and maybe ask some questions.

                Biz folks, in particular, are often imprecise in their language,
                especially in the area of things like "this doesn't do what I wanted."
                Maybe they are playing a blame game, maybe they are yanking your
                chain. But maybe they aren't. Maybe they're just focused on a
                different level of activity.

                I'm sure all of us have had the occasional conversation or
                mailing list exchange - sometimes with a colleague - where somebody
                gets stuck on some point of minutae that side-tracks the conversation
                into pointillistic nihilism (or was that nihillistic pointillism?). I
                can't think of a specific example offhand, so I'm going to make one
                up:

                "Would you hand me that marker?"
                "That's not a marker, it's a pen."
                "Whatever, would you hand it to me?"
                "We used to have markers, but they all dried up."
                "Just hand me the damn pen!"

                (For some reason I suspect there's a good Monty Python skit I
                could be quoting here...).

                I imagine that fairly often the bizfolk have the same feeling
                when they talk to tech folk. Sometimes they're right. Sometimes the
                focus needs to be on the fact that we still have a problem that we
                need to solve. And sometimes they're wrong.

                Sometimes they literally say "That's Not What I Asked For" in an
                accustory way. But more often I find it's something more like "that's
                not the feature reqeusted" or some other words that are merely the
                bizfolk struggling to articulate something like "that doesn't solve
                the problem," and sometimes it's even really "that doesn't solve the
                problem (in its current form)." A little probing and investigation is
                often enough to reveal that all it needs is a little tweaking (which
                the bizfolk either don't realize is trivial, or were not quite able to
                articulate).

                Sometimes, even when they are right, it may be necessary and good
                to make sure you draw their attention to some of the language issues,
                to develop better long-term habits of speech and cultivate trust - on
                both sides. If you let a comment like that pass, all they may
                remember in their own head is the comment, and in the long run that
                may be part of what erodes their trust. Certainly, letting it pass
                silently will not help them learn and develop the necessary skills
                they need to fully contribute to developing the right software.

                The trick is to find the right way to address it without
                disrupting the progress towards the goal, and without sounding
                defensive. Sometimes I just remind them "software development is a
                procoss of discovery." Sometimes I put it in the bigger picture, "we
                develop the software, see what we learn in the process, and put that
                knowledge back into the next iteration." Sometimes it's just enough
                to honestly ask them "how is it wrong? Let's understand the problem."

                Maybe it's because I tend to dig into how/why first, that I can
                usually come back (after attaining understanding) to the original
                question and post-mortem the initial misunderstanding, without that
                being perceived as defensive behavior.

                --
                Steven J. Owens
                puff@...

                "I'm going to make broad, sweeping generalizations and strong,
                declarative statements, because otherwise I'll be here all night and
                this document will be four times longer and much less fun to read.
                Take it all with a grain of salt." - http://darksleep.com/notablog
              • J. B. Rainsberger
                ... The most pressing problem I m dealing with, at present, has to do with the fact that the programmers broke close to 30 consecutive promises to their
                Message 7 of 14 , Feb 27, 2005
                View Source
                • 0 Attachment
                  xp_coder wrote:
                  >
                  >
                  > One thing I'm wondering about xp is how does it handle relationships
                  > with the customer.
                  > I know about planning game practice but I can't see how it can avoid
                  > problems like a customer telling you: "That's not what I asked for".
                  > As far as I know, XP doesn't encourage writting minutes of all has
                  > been said during meetings of discussion with the customer.
                  > XP prefer to promote communication and trust.
                  > But is that enough ?
                  > Have you even experienced such problems with your customers ?

                  The most pressing problem I'm dealing with, at present, has to do with
                  the fact that the programmers broke close to 30 consecutive promises to
                  their customers: they went 0-for-the-project in delivering an iteration
                  with all the features. They weren't late (no such thing), but they were
                  chronically "light".

                  I'm going to try asking the customers to split stories into smaller
                  chunks, so as to reduce the average estimation error per story. This
                  should help the programmers get a clue about how fast they can go. I
                  think it'll work quite well. Perhaps they'll even deliver one good
                  iteration this time around. I can't wait.
                  --
                  J. B. (Joe) Rainsberger
                  Diaspar Software Services
                  http://www.diasparsoftware.com
                  Author, JUnit Recipes: Practical Methods for Programmer Testing
                • Gary Brown
                  ... One of the teams I am currently coaching has chronically under-delivered. We are rewriting an existing system. The team members are well aware of the
                  Message 8 of 14 , Feb 27, 2005
                  View Source
                  • 0 Attachment
                    J. B. Rainsberger wrote:

                    >xp_coder wrote:
                    >
                    >
                    >>One thing I'm wondering about xp is how does it handle relationships
                    >>with the customer.
                    >>I know about planning game practice but I can't see how it can avoid
                    >>problems like a customer telling you: "That's not what I asked for".
                    >>As far as I know, XP doesn't encourage writting minutes of all has
                    >>been said during meetings of discussion with the customer.
                    >>XP prefer to promote communication and trust.
                    >>But is that enough ?
                    >>Have you even experienced such problems with your customers ?
                    >>
                    >>
                    >
                    >The most pressing problem I'm dealing with, at present, has to do with
                    >the fact that the programmers broke close to 30 consecutive promises to
                    >their customers: they went 0-for-the-project in delivering an iteration
                    >with all the features. They weren't late (no such thing), but they were
                    >chronically "light".
                    >
                    >I'm going to try asking the customers to split stories into smaller
                    >chunks, so as to reduce the average estimation error per story. This
                    >should help the programmers get a clue about how fast they can go. I
                    >think it'll work quite well. Perhaps they'll even deliver one good
                    >iteration this time around. I can't wait.
                    >
                    >
                    One of the teams I am currently coaching has chronically
                    under-delivered. We are rewriting an existing system. The team members
                    are well aware of the good things and bad about the current system. The
                    are motivated to keep the good and eliminate the bad. As I observe them
                    working through each story, I see that they are frequently willing to
                    add a little bit extra. While this might seem like a good thing, it
                    causes us to slow down. I have asked them to write a ToDo list on the
                    back of each story card when it is estimated, then draw a line under the
                    last item. When the story is implemented, add any additional tasks
                    below the line. I am hoping that we will begin to understand whether we
                    are missing required tasks, which causes us to under-estimate, or we are
                    adding tasks that could be deferred, which causes us to spend more time
                    than we had planned. Time will tell ...

                    GB.




                    [Non-text portions of this message have been removed]
                  • Michael Dubakov
                    ... I don t think this is a good idea to split user stories just because of the possible better estimates. You could split user story on tasks, estimate each
                    Message 9 of 14 , Feb 28, 2005
                    View Source
                    • 0 Attachment
                      > >I'm going to try asking the customers to split stories into smaller
                      > >chunks, so as to reduce the average estimation error per story.
                      >>This should help the programmers get a clue about how fast they can
                      >>go. I think it'll work quite well. Perhaps they'll even deliver one
                      >>good iteration this time around. I can't wait.

                      I don't think this is a good idea to split user stories just because
                      of the possible better estimates.
                      You could split user story on tasks, estimate each task and define
                      user story's effort as a sum of the tasks' effort. This may solve the
                      problem.


                      Michael
                      http://www.targetprocess.com
                      XP Planning & Bug Tracking Software




                      --- In extremeprogramming@yahoogroups.com, Gary Brown <glbrown@i...>
                      wrote:
                      > J. B. Rainsberger wrote:
                      >
                      > >xp_coder wrote:
                      > >
                      > >
                      > >>One thing I'm wondering about xp is how does it handle relationships
                      > >>with the customer.
                      > >>I know about planning game practice but I can't see how it can avoid
                      > >>problems like a customer telling you: "That's not what I asked for".
                      > >>As far as I know, XP doesn't encourage writting minutes of all has
                      > >>been said during meetings of discussion with the customer.
                      > >>XP prefer to promote communication and trust.
                      > >>But is that enough ?
                      > >>Have you even experienced such problems with your customers ?
                      > >>
                      > >>
                      > >
                      > >The most pressing problem I'm dealing with, at present, has to do with
                      > >the fact that the programmers broke close to 30 consecutive
                      promises to
                      > >their customers: they went 0-for-the-project in delivering an
                      iteration
                      > >with all the features. They weren't late (no such thing), but they
                      were
                      > >chronically "light".
                      > >
                      > >I'm going to try asking the customers to split stories into smaller
                      > >chunks, so as to reduce the average estimation error per story. This
                      > >should help the programmers get a clue about how fast they can go. I
                      > >think it'll work quite well. Perhaps they'll even deliver one good
                      > >iteration this time around. I can't wait.
                      > >
                      > >
                      > One of the teams I am currently coaching has chronically
                      > under-delivered. We are rewriting an existing system. The team
                      members
                      > are well aware of the good things and bad about the current system.
                      The
                      > are motivated to keep the good and eliminate the bad. As I observe
                      them
                      > working through each story, I see that they are frequently willing to
                      > add a little bit extra. While this might seem like a good thing, it
                      > causes us to slow down. I have asked them to write a ToDo list on the
                      > back of each story card when it is estimated, then draw a line under
                      the
                      > last item. When the story is implemented, add any additional tasks
                      > below the line. I am hoping that we will begin to understand
                      whether we
                      > are missing required tasks, which causes us to under-estimate, or we
                      are
                      > adding tasks that could be deferred, which causes us to spend more time
                      > than we had planned. Time will tell ...
                      >
                      > GB.
                      >
                      >
                      >
                      >
                      > [Non-text portions of this message have been removed]
                    • William Wake
                      ... I split big stories too. In one case, we looked back and realized, stories estimated at more than 2 points never come in on time so we started splitting
                      Message 10 of 14 , Feb 28, 2005
                      View Source
                      • 0 Attachment
                        On Mon, 28 Feb 2005 16:06:42 -0000, Michael Dubakov <firefalcon@...> wrote:
                        > I don't think this is a good idea to split user stories just because
                        > of the possible better estimates.

                        I split big stories too. In one case, we looked back and realized,
                        "stories estimated at more than 2 points never come in on time" so we
                        started splitting any stories that look bigger. It helped.

                        > You could split user story on tasks, estimate each task and define
                        > user story's effort as a sum of the tasks' effort. This may solve the
                        > problem.

                        If you're saying, "if you have trouble estimating a story, try
                        estimating its tasks," I'm good with that. But I wouldn't normally
                        split stories based on tasks - I want them to represent chunks of
                        functionality that users/customers can value.

                        --
                        Bill Wake William.Wake@... www.xp123.com
                      • Ron Jeffries
                        ... I d go with smaller stories in most cases. Ron Jeffries www.XProgramming.com It s easy to have a complicated idea. It s very very hard to have a simple
                        Message 11 of 14 , Feb 28, 2005
                        View Source
                        • 0 Attachment
                          On Monday, February 28, 2005, at 10:06:42 AM, Michael Dubakov wrote:

                          >> >I'm going to try asking the customers to split stories into smaller
                          >> >chunks, so as to reduce the average estimation error per story.
                          >>>This should help the programmers get a clue about how fast they can
                          >>>go. I think it'll work quite well. Perhaps they'll even deliver one
                          >>>good iteration this time around. I can't wait.

                          > I don't think this is a good idea to split user stories just because
                          > of the possible better estimates.
                          > You could split user story on tasks, estimate each task and define
                          > user story's effort as a sum of the tasks' effort. This may solve the
                          > problem.

                          I'd go with smaller stories in most cases.

                          Ron Jeffries
                          www.XProgramming.com
                          It's easy to have a complicated idea. It's very very hard to have a simple idea.
                          -- Carver Mead
                        • J. B. Rainsberger
                          ... I have passed this on to the team. I hope they ll remain aware of it, and I wish you best of luck. -- J. B. (Joe) Rainsberger Diaspar Software Services
                          Message 12 of 14 , Mar 1, 2005
                          View Source
                          • 0 Attachment
                            Gary Brown wrote:
                            > J. B. Rainsberger wrote:

                            > One of the teams I am currently coaching has chronically
                            > under-delivered. We are rewriting an existing system. The team members
                            > are well aware of the good things and bad about the current system. The
                            > are motivated to keep the good and eliminate the bad. As I observe them
                            > working through each story, I see that they are frequently willing to
                            > add a little bit extra. While this might seem like a good thing, it
                            > causes us to slow down. I have asked them to write a ToDo list on the
                            > back of each story card when it is estimated, then draw a line under the
                            > last item. When the story is implemented, add any additional tasks
                            > below the line. I am hoping that we will begin to understand whether we
                            > are missing required tasks, which causes us to under-estimate, or we are
                            > adding tasks that could be deferred, which causes us to spend more time
                            > than we had planned. Time will tell ...

                            I have passed this on to the team. I hope they'll remain aware of it,
                            and I wish you best of luck.
                            --
                            J. B. (Joe) Rainsberger
                            Diaspar Software Services
                            http://www.diasparsoftware.com
                            Author, JUnit Recipes: Practical Methods for Programmer Testing
                          • J. B. Rainsberger
                            ... Please tell me more about the risks you see with splitting stories this way that outweigh the risks of never delivering an iteration on time. ... I don t
                            Message 13 of 14 , Mar 1, 2005
                            View Source
                            • 0 Attachment
                              Michael Dubakov wrote:
                              >
                              >>>I'm going to try asking the customers to split stories into smaller
                              >>>chunks, so as to reduce the average estimation error per story.
                              >>>This should help the programmers get a clue about how fast they can
                              >>>go. I think it'll work quite well. Perhaps they'll even deliver one
                              >>>good iteration this time around. I can't wait.
                              >
                              > I don't think this is a good idea to split user stories just because
                              > of the possible better estimates.

                              Please tell me more about the risks you see with splitting stories this
                              way that outweigh the risks of never delivering an iteration on time.

                              > You could split user story on tasks, estimate each task and define
                              > user story's effort as a sum of the tasks' effort. This may solve the
                              > problem.

                              I don't think I understand the difference between this and splitting the
                              stories, except that with the tasks, I miss the opportunity to ask the
                              customer, "If we just did /this/ bit, would that be all right?" and get
                              the joyous answer, "Sure!"
                              --
                              J. B. (Joe) Rainsberger
                              Diaspar Software Services
                              http://www.diasparsoftware.com
                              Author, JUnit Recipes: Practical Methods for Programmer Testing
                            • Michael Dubakov
                              ... Yes, I mean exactly that. User Story should represent chunks of functionality for sure. ... we started splitting any stories that look bigger. It helped.
                              Message 14 of 14 , Mar 1, 2005
                              View Source
                              • 0 Attachment
                                >If you're saying, "if you have trouble estimating a story, try
                                > estimating its tasks,"

                                Yes, I mean exactly that. User Story should represent "chunks of
                                functionality" for sure.

                                > I split big stories too. In one case, we looked back and realized,
                                > "stories estimated at more than 2 points never come in on time" so
                                we started splitting any stories that look bigger. It helped.

                                If you could split story and both new stories will have business
                                value, that's ok.

                                Michael
                                http://www.targetprocess.com
                                XP Planning & Bug Tracking software


                                --- In extremeprogramming@yahoogroups.com, William Wake
                                <william.wake@g...> wrote:
                                > On Mon, 28 Feb 2005 16:06:42 -0000, Michael Dubakov
                                <firefalcon@t...> wrote:
                                > > I don't think this is a good idea to split user stories just because
                                > > of the possible better estimates.
                                >
                                > I split big stories too. In one case, we looked back and realized,
                                > "stories estimated at more than 2 points never come in on time" so we
                                > started splitting any stories that look bigger. It helped.
                                >
                                > > You could split user story on tasks, estimate each task and define
                                > > user story's effort as a sum of the tasks' effort. This may solve the
                                > > problem.
                                >
                                > If you're saying, "if you have trouble estimating a story, try
                                > estimating its tasks," I'm good with that. But I wouldn't normally
                                > split stories based on tasks - I want them to represent chunks of
                                > functionality that users/customers can value.
                                >
                                > --
                                > Bill Wake William.Wake@a... www.xp123.com
                              Your message has been successfully submitted and would be delivered to recipients shortly.