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

Re: [XP] How much planning do we need to do?

Expand Messages
  • Jason McIntosh
    Acceptance Criteria like others have mentioned. That seems key. I m guessing it s pretty common for a customer to say oh it doesn t matter and then when
    Message 1 of 10 , Jun 2, 2008
    • 0 Attachment
      Acceptance Criteria like others have mentioned. That seems key. I'm
      guessing it's pretty common for a customer to say "oh it doesn't matter" and
      then when they get something turn around and say "oh gosh, that's not
      right!". Have that conversation up front. Even if they say "it doesn't
      matter". See if the team can give a quick idea as to what it will
      look/behave like. Just take it the next step, rather than having things
      unsaid, just ask "if the team does that. Will that satisfy this story?".

      It seems like you're missing the final piece of a story conversation : what
      does this story look like when it's completed. What makes this story "done"
      in the customer's mind.

      On Mon, Jun 2, 2008 at 7:05 AM, Ron Jeffries <ronjeffries@...>
      wrote:

      > Hello, Pat. On Monday, June 2, 2008, at 7:33:04 AM, you wrote:
      >
      > > How much planning is too much/too little? I understand that there are
      > > a lot of variables that go into answering this. I'll give details of
      > > my team's particular situation and hopefully spur good discussion.
      >
      > > We're experiencing problems that I believe are due to our planning
      > > process. At the beginning of the iteration we sit down with my boss
      > > (who plays the customer role) to come up with new stories and to
      > > review the prioritization of existing stories.
      >
      > > The key problem we have is that we get a lot of stories rejected. I'd
      > > say about a third of the stories we do get rejected and need
      > > additional work. I believe that it's because we don't develop a deep
      > > enough shared understanding with the customer's needs. We're finding
      > > it pretty difficult to do though. A very common convo/situation goes
      > > like the following:
      >
      > > Customer: "I want to show a list of locations where events were
      > > previously scheduled."
      > > Dev: "Okay. Maybe a grid with the location name and address?"
      > > C: "Yeah, that sounds good. And let's embed the Google Map view also"
      > > D: "Great. Let's do a quick sketch to see what it might look like."
      > > C: "I don't really care what it looks like. Anything will be fine"
      > > *we go to work, mark the story delivered. at the end of the
      > > iteration, customer rejects it saying it doesn't look right*
      >
      > What if instead of rejecting it, the boss said, "OK, that's good,
      > now what I'd like is ... X", resulting in a new story?
      >
      > After all, s/he said "I don't really care what it looks like," so it
      > is clearly passing that test.
      >
      > So I'd take the boss aside and ask to have a story that meets the
      > criteria accepted and a new story created. That's probably the best
      > way to go with regard to look and feel anyway.
      >
      > Or ...
      >
      > What if when a new thing like this comes along, you do a first story
      > called "make the initial version" and a second story called "clean
      > up the initial version"?
      >
      > Or ...
      >
      > What if you drew the GUI on paper or mocked it up before doing the
      > work, and showed it to the boss?
      >
      > Or ...
      >
      > What if you said "OK, let's be sure we understand what you want,"
      > went to the whiteboard, and drew up a really stupid example of the
      > screen requested, and said "Like that?" If the boss says Yes, then
      > leave the picture up and point to it when they go to reject. If the
      > boss says No, improve the sketch.
      >
      > BTW, this is not planning, it's designing, as this example should
      > make clear.
      >
      > Of these, my favorite is the first because the boss did say it
      > didn't matter. So they should say "OK, and what I'd like next is
      > ... X." Then it wouldn't be rejection.
      >
      > > This is really frustrating from a developer standpoint. One issue is
      > > that it just doesn't feel good to have our work constantly rejected.
      > > How much that counts or should count, I don't know. More importantly,
      > > it screws with our planning. If we've completed a story, but then
      > > have to allocate time in the next iteration to fix problems with it,
      > > then we push back things that were planned for that iteration. I
      > > think that's okay in small amounts, but it makes our planning less
      > > useful because we can't accurately estimate what we'll be able to get
      > > to.
      >
      > Things planned for the next iteration? There is nothing planned for
      > the next iteration except what the customer asks for. If the
      > customer asks for more work on last week's story, so be it.
      >
      > Managing the work into iterations is the boss's job. Your paragraph
      > above makes it sound to me as if somehow the plan belongs to you
      > (the developers?) rather than the boss.
      >
      > > The first obvious thing to do is to explain to the customer the
      > > problems this causes. We've said in the past that we'd like to do
      > > some deeper planning because we don't like having the stories
      > > rejected. The customer said it wasn't a really big deal to him that
      > > we'd deliver a story and that he'd reject it, with specific items to
      > > find.
      >
      > Customer is probably right. If it doesn't bother them, so be it. But
      > ask for another word.
      >
      > It comes to me that both sides may be thinking that you are supposed
      > to take a story and complete everything about that story in one
      > iteration. That's not the case. A story is what you commit to do in
      > one iteration. If you do it, that story is done. If you don't like
      > how it looks or want to add a subtotal to it, then that is a new
      > story.
      >
      > > I've pointed out that it hurts our productivity because it
      > > requires us to switch contexts a couple days after the fact. I
      > > haven't said that it messes up our planning, because I hadn't really
      > > thought of it until I wrote this message. I'm not sure what impact
      > > that will have, as my boss doesn't seem to find XP-style planning
      > > particularly valuable. He appears to feel that everything needs to
      > > get done, and it doesn't really matter in what order.
      >
      > IMO, that may be due to not understanding the impact of change. On
      > the other hand, XP planning is not about getting things right the
      > first time, it is about getting them right finally.
      >
      > Are you estimating stories and laying them down roughly on the
      > calendar (Release Plan)? Does the boss really have no deadline in
      > mind?
      >
      > > I believe all of this is hurting the team's productivity. I'm having
      > > a tough time getting into the customer's head and framing my concerns
      > > in a way that really matters to him.
      >
      > I don't understand either.
      >
      > Maybe it's not really affecting anything. Maybe it takes X time to
      > get the first version and Y time to clean it up. Maybe the
      >
      > > Finally, I think there's a stigma against doing too much planning.
      > > We're doing about 3 hours of planning a week, which I don't consider
      > > to be very much. So I realize this would vary a great deal from
      > > project to project, but what is an "average" time to spend planning in
      > > a week?
      >
      > You didn't say how big your team was. I would think 3 hours a week
      > would be OK but not impressively low for most teams.
      >
      > But again, I don't think you're asking for planning. I think you may
      > be worried about design.
      >
      > Ron Jeffries
      > www.XProgramming.com
      > Fear is the mindkiller. --Bene Gesserit Litany Against Fear
      >
      >
      >


      [Non-text portions of this message have been removed]
    • Steven Gordon
      Pat, It seems to me that this customer does not really know what they want until the see something concrete. The good news is that the customer knows this and
      Message 2 of 10 , Jun 2, 2008
      • 0 Attachment
        Pat,

        It seems to me that this customer does not really know what they want
        until the see something concrete. The good news is that the customer
        knows this and is not upset with the waste and slowness that results
        from their inability to know what they really want.

        Since the customer needs something concrete delivered in order to
        figure out what they want, more detailed planning will only waste more
        work before getting the customer something concrete to react to.

        My suggestion is to do less instead of doing more. If your iterations
        were half as long and your stories were sliced half as thick, you
        would waste about half as much work before discovering what the
        customer really wants. In your example, perhaps just do the grid with
        text and links in order to get something to the customer as quickly as
        possible for feedback. Then harness the feedback the next iteration
        to do what the customer has discovered that they really want.

        Steven Gordon

        On Mon, Jun 2, 2008 at 4:33 AM, Pat Maddox <pergesu@...> wrote:
        > How much planning is too much/too little? I understand that there are
        > a lot of variables that go into answering this. I'll give details of
        > my team's particular situation and hopefully spur good discussion.
        >
        > We're experiencing problems that I believe are due to our planning
        > process. At the beginning of the iteration we sit down with my boss
        > (who plays the customer role) to come up with new stories and to
        > review the prioritization of existing stories.
        >
        > The key problem we have is that we get a lot of stories rejected. I'd
        > say about a third of the stories we do get rejected and need
        > additional work. I believe that it's because we don't develop a deep
        > enough shared understanding with the customer's needs. We're finding
        > it pretty difficult to do though. A very common convo/situation goes
        > like the following:
        >
        > Customer: "I want to show a list of locations where events were
        > previously scheduled."
        > Dev: "Okay. Maybe a grid with the location name and address?"
        > C: "Yeah, that sounds good. And let's embed the Google Map view also"
        > D: "Great. Let's do a quick sketch to see what it might look like."
        > C: "I don't really care what it looks like. Anything will be fine"
        > *we go to work, mark the story delivered. at the end of the
        > iteration, customer rejects it saying it doesn't look right*
        >
        > This is really frustrating from a developer standpoint. One issue is
        > that it just doesn't feel good to have our work constantly rejected.
        > How much that counts or should count, I don't know. More importantly,
        > it screws with our planning. If we've completed a story, but then
        > have to allocate time in the next iteration to fix problems with it,
        > then we push back things that were planned for that iteration. I
        > think that's okay in small amounts, but it makes our planning less
        > useful because we can't accurately estimate what we'll be able to get
        > to.
        >
        > The first obvious thing to do is to explain to the customer the
        > problems this causes. We've said in the past that we'd like to do
        > some deeper planning because we don't like having the stories
        > rejected. The customer said it wasn't a really big deal to him that
        > we'd deliver a story and that he'd reject it, with specific items to
        > find. I've pointed out that it hurts our productivity because it
        > requires us to switch contexts a couple days after the fact. I
        > haven't said that it messes up our planning, because I hadn't really
        > thought of it until I wrote this message. I'm not sure what impact
        > that will have, as my boss doesn't seem to find XP-style planning
        > particularly valuable. He appears to feel that everything needs to
        > get done, and it doesn't really matter in what order.
        >
        > I believe all of this is hurting the team's productivity. I'm having
        > a tough time getting into the customer's head and framing my concerns
        > in a way that really matters to him.
        >
        > Finally, I think there's a stigma against doing too much planning.
        > We're doing about 3 hours of planning a week, which I don't consider
        > to be very much. So I realize this would vary a great deal from
        > project to project, but what is an "average" time to spend planning in
        > a week?
        >
        > Pat
      • J. B. Rainsberger
        ... A true story. The last time this happened to a team I worked with, they had being demoing their work every two weeks on Friday afternoon. They told me they
        Message 3 of 10 , Jun 2, 2008
        • 0 Attachment
          On Jun 2, 2008, at 06:33 , Pat Maddox wrote:
          > Customer: "I want to show a list of locations where events were
          > previously scheduled."
          > Dev: "Okay. Maybe a grid with the location name and address?"
          > C: "Yeah, that sounds good. And let's embed the Google Map view also"
          > D: "Great. Let's do a quick sketch to see what it might look like."
          > C: "I don't really care what it looks like. Anything will be fine"
          > *we go to work, mark the story delivered. at the end of the
          > iteration, customer rejects it saying it doesn't look right*
          >
          A true story.

          The last time this happened to a team I worked with, they had being
          demoing their work every two weeks on Friday afternoon. They told me
          they had this same problem: too much rework when the customer saw it.
          I asked them if they could get feedback every week instead, and they
          tried that for a few months and it helped. Then I suggested they try
          Wednesday morning and Friday afternoon. That worked, too. Within four
          or five months they increased feedback fourfold. I don't know about
          their final results, but I imagine the fact that they increased the
          frequency of the demos twice (possibly more) tells me that they found
          it useful.

          Take care.
          ----
          J. B. (Joe) Rainsberger :: http://www.jbrains.ca
          Your guide to software craftsmanship
          JUnit Recipes: Practical Methods for Programmer Testing
          2005 Gordon Pask Award for contributions to Agile Software Practice
        • Pat Maddox
          On Mon, Jun 2, 2008 at 5:05 AM, Ron Jeffries ... This is true, but he doesn t accept the story because he doesn t feel that it s complete. Perhaps the
          Message 4 of 10 , Jun 5, 2008
          • 0 Attachment
            On Mon, Jun 2, 2008 at 5:05 AM, Ron Jeffries
            <ronjeffries@...> wrote:
            > Hello, Pat. On Monday, June 2, 2008, at 7:33:04 AM, you wrote:
            >
            >> How much planning is too much/too little? I understand that there are
            >> a lot of variables that go into answering this. I'll give details of
            >> my team's particular situation and hopefully spur good discussion.
            >
            >> We're experiencing problems that I believe are due to our planning
            >> process. At the beginning of the iteration we sit down with my boss
            >> (who plays the customer role) to come up with new stories and to
            >> review the prioritization of existing stories.
            >
            >> The key problem we have is that we get a lot of stories rejected. I'd
            >> say about a third of the stories we do get rejected and need
            >> additional work. I believe that it's because we don't develop a deep
            >> enough shared understanding with the customer's needs. We're finding
            >> it pretty difficult to do though. A very common convo/situation goes
            >> like the following:
            >
            >> Customer: "I want to show a list of locations where events were
            >> previously scheduled."
            >> Dev: "Okay. Maybe a grid with the location name and address?"
            >> C: "Yeah, that sounds good. And let's embed the Google Map view also"
            >> D: "Great. Let's do a quick sketch to see what it might look like."
            >> C: "I don't really care what it looks like. Anything will be fine"
            >> *we go to work, mark the story delivered. at the end of the
            >> iteration, customer rejects it saying it doesn't look right*
            >
            > What if instead of rejecting it, the boss said, "OK, that's good,
            > now what I'd like is ... X", resulting in a new story?
            >
            > After all, s/he said "I don't really care what it looks like," so it
            > is clearly passing that test.

            This is true, but he doesn't accept the story because he doesn't feel
            that it's complete. Perhaps the ultimate source of our frustration is
            that this causes a bit of conflict - he rejects stories on the basis
            that they're incomplete, but the developers feel like there's an
            unfair game being played. We can't seem to elicit acceptance
            criteria, so how do we have a chance at fulfilling them?


            > So I'd take the boss aside and ask to have a story that meets the
            > criteria accepted and a new story created. That's probably the best
            > way to go with regard to look and feel anyway.

            This sounds good to me, though I think it conflicts with our process.
            We're doing two-week release cycles (we're a web app in alpha stage),
            so I think a lot of the rejections come up because we've passed the
            expressed acceptance criteria, but the feature perhaps isn't
            releasable.


            > Or ...
            >
            > What if when a new thing like this comes along, you do a first story
            > called "make the initial version" and a second story called "clean
            > up the initial version"?
            >
            > Or ...
            >
            > What if you drew the GUI on paper or mocked it up before doing the
            > work, and showed it to the boss?
            >
            > Or ...
            >
            > What if you said "OK, let's be sure we understand what you want,"
            > went to the whiteboard, and drew up a really stupid example of the
            > screen requested, and said "Like that?" If the boss says Yes, then
            > leave the picture up and point to it when they go to reject. If the
            > boss says No, improve the sketch.

            We've asked to do this, he doesn't seem interested in participating.
            What if we did it asynchronously? After the planning meeting, the
            devs would do sketches of the UI and workflow, then send them off to
            him. This would relieve some of the pressure of making decisions on
            the spot.


            > BTW, this is not planning, it's designing, as this example should
            > make clear.

            When should these little customer-developer design sessions take place?


            > Of these, my favorite is the first because the boss did say it
            > didn't matter. So they should say "OK, and what I'd like next is
            > ... X." Then it wouldn't be rejection.
            >
            >> This is really frustrating from a developer standpoint. One issue is
            >> that it just doesn't feel good to have our work constantly rejected.
            >> How much that counts or should count, I don't know. More importantly,
            >> it screws with our planning. If we've completed a story, but then
            >> have to allocate time in the next iteration to fix problems with it,
            >> then we push back things that were planned for that iteration. I
            >> think that's okay in small amounts, but it makes our planning less
            >> useful because we can't accurately estimate what we'll be able to get
            >> to.
            >
            > Things planned for the next iteration? There is nothing planned for
            > the next iteration except what the customer asks for. If the
            > customer asks for more work on last week's story, so be it.

            We've got a backlog of several iterations. We try to keep the current
            iteration as stable as possible, and allow for change in the backlog.

            Anyway, at this point we tend to know quite a bit about what the next
            iteration will look like. The problem is that sometimes my boss will
            be frustrated that a couple stories might be pushed back from it. We
            get frustrated because we feel like we've been unfairly committed to
            that plan, and it got pushed back because current stories were pushed
            back due to failing unknown acceptance criteria.


            > Managing the work into iterations is the boss's job. Your paragraph
            > above makes it sound to me as if somehow the plan belongs to you
            > (the developers?) rather than the boss.
            >
            >> The first obvious thing to do is to explain to the customer the
            >> problems this causes. We've said in the past that we'd like to do
            >> some deeper planning because we don't like having the stories
            >> rejected. The customer said it wasn't a really big deal to him that
            >> we'd deliver a story and that he'd reject it, with specific items to
            >> find.
            >
            > Customer is probably right. If it doesn't bother them, so be it. But
            > ask for another word.
            >
            > It comes to me that both sides may be thinking that you are supposed
            > to take a story and complete everything about that story in one
            > iteration. That's not the case. A story is what you commit to do in
            > one iteration. If you do it, that story is done. If you don't like
            > how it looks or want to add a subtotal to it, then that is a new
            > story.
            >
            >> I've pointed out that it hurts our productivity because it
            >> requires us to switch contexts a couple days after the fact. I
            >> haven't said that it messes up our planning, because I hadn't really
            >> thought of it until I wrote this message. I'm not sure what impact
            >> that will have, as my boss doesn't seem to find XP-style planning
            >> particularly valuable. He appears to feel that everything needs to
            >> get done, and it doesn't really matter in what order.
            >
            > IMO, that may be due to not understanding the impact of change. On
            > the other hand, XP planning is not about getting things right the
            > first time, it is about getting them right finally.
            >
            > Are you estimating stories and laying them down roughly on the
            > calendar (Release Plan)? Does the boss really have no deadline in
            > mind?

            We just got a deadline earlier this week. For the past 6 months
            though, there have been no deadlines. I'm hoping that this deadline
            will lead to more thought regarding prioritization.


            >> I believe all of this is hurting the team's productivity. I'm having
            >> a tough time getting into the customer's head and framing my concerns
            >> in a way that really matters to him.
            >
            > I don't understand either.
            >
            > Maybe it's not really affecting anything. Maybe it takes X time to
            > get the first version and Y time to clean it up. Maybe the
            >
            >> Finally, I think there's a stigma against doing too much planning.
            >> We're doing about 3 hours of planning a week, which I don't consider
            >> to be very much. So I realize this would vary a great deal from
            >> project to project, but what is an "average" time to spend planning in
            >> a week?
            >
            > You didn't say how big your team was. I would think 3 hours a week
            > would be OK but not impressively low for most teams.
            >
            > But again, I don't think you're asking for planning. I think you may
            > be worried about design.

            I asked this inline above, but I'd like to mention it again here to
            ensure we discuss it. What time relative to planning should we be
            doing these design sessions? Particularly the ones that are used to
            develop a shared understanding between customer and developers.

            Pat
          • George Dinwiddie
            ... Hi, Pat. Bring me a rock. -- ... * George Dinwiddie * http://blog.gdinwiddie.com Software Development
            Message 5 of 10 , Jun 5, 2008
            • 0 Attachment
              Pat Maddox wrote:
              > This is true, but he doesn't accept the story because he doesn't feel
              > that it's complete. Perhaps the ultimate source of our frustration is
              > that this causes a bit of conflict - he rejects stories on the basis
              > that they're incomplete, but the developers feel like there's an
              > unfair game being played. We can't seem to elicit acceptance
              > criteria, so how do we have a chance at fulfilling them?

              Hi, Pat. Bring me a rock.

              --
              ----------------------------------------------------------------------
              * George Dinwiddie * http://blog.gdinwiddie.com
              Software Development http://www.idiacomputing.com
              Consultant and Coach http://www.agilemaryland.org
              ----------------------------------------------------------------------
            • Ron Jeffries
              ... Yes. I m suggesting agreeing with the boss that while he may want changes, those will be treated as a new story for tracking purposes. We could talk
              Message 6 of 10 , Jun 9, 2008
              • 0 Attachment
                Hello, Pat. On Thursday, June 5, 2008, at 7:56:52 PM, you wrote:

                >> After all, s/he said "I don't really care what it looks like," so it
                >> is clearly passing that test.

                > This is true, but he doesn't accept the story because he doesn't feel
                > that it's complete. Perhaps the ultimate source of our frustration is
                > that this causes a bit of conflict - he rejects stories on the basis
                > that they're incomplete, but the developers feel like there's an
                > unfair game being played. We can't seem to elicit acceptance
                > criteria, so how do we have a chance at fulfilling them?

                Yes. I'm suggesting agreeing with the boss that while he may want
                changes, those will be treated as a "new story" for tracking
                purposes. We could talk about why that's a good idea but one might
                get the convention followed by just asking.

                >> So I'd take the boss aside and ask to have a story that meets the
                >> criteria accepted and a new story created. That's probably the best
                >> way to go with regard to look and feel anyway.

                > This sounds good to me, though I think it conflicts with our process.
                > We're doing two-week release cycles (we're a web app in alpha stage),
                > so I think a lot of the rejections come up because we've passed the
                > expressed acceptance criteria, but the feature perhaps isn't
                > releasable.

                I'm not clear on how that conflicts with your process. Perhaps you
                are using a different definition of "releasable" than I would, which
                is, roughly, "This is complete enough so that it does what the
                customer originally asked for, and it is solid enough and robust
                enough to shipped harmlessly." If the customer has changed their
                mind, they might decide not to release it and to ask for something
                else or in addition. That's fine: at the end of the next iteration
                we'll have that, also "releasable".

                >> What if you said "OK, let's be sure we understand what you want,"
                >> went to the whiteboard, and drew up a really stupid example of the
                >> screen requested, and said "Like that?" If the boss says Yes, then
                >> leave the picture up and point to it when they go to reject. If the
                >> boss says No, improve the sketch.

                > We've asked to do this, he doesn't seem interested in participating.
                > What if we did it asynchronously? After the planning meeting, the
                > devs would do sketches of the UI and workflow, then send them off to
                > him. This would relieve some of the pressure of making decisions on
                > the spot.

                Might work. Do you think he is troubled by making decisions on the
                spot? Why then is he willing to make them later, when the work is
                done?

                I might take a serious look at how much actual rework there is to a
                story. If there wasn't much rework -- and I'd think we could
                minimize that by working from sketch to good art -- maybe we just
                should get over it. However, showing how long stories hang in the
                air, not being worked on, waiting for better specs, might be
                interesting ...

                >> BTW, this is not planning, it's designing, as this example should
                >> make clear.

                > When should these little customer-developer design sessions take place?

                Perhaps prior to the real planning meeting. Is anyone working with
                the boss ahead of time to help him prepare? Might be worth doing ...

                >> Things planned for the next iteration? There is nothing planned for
                >> the next iteration except what the customer asks for. If the
                >> customer asks for more work on last week's story, so be it.

                > We've got a backlog of several iterations. We try to keep the current
                > iteration as stable as possible, and allow for change in the backlog.

                Who is "we"? I would think that the backlog belongs to the boss. If
                so, then when the boss sees that he is affecting his own backlog,
                I'd expect him to learn.

                Are the team, perhaps, working to the original backlog expectation,
                not "requiring" the boss to remove things from it when there is more
                to do than was originally seen? If so, I'd suggest not doing that.

                The development team's job is to say how much work can be done in
                any given iteration. The boss's job, as customer, is to decide which
                work, within that limit.

                > Anyway, at this point we tend to know quite a bit about what the next
                > iteration will look like. The problem is that sometimes my boss will
                > be frustrated that a couple stories might be pushed back from it. We
                > get frustrated because we feel like we've been unfairly committed to
                > that plan, and it got pushed back because current stories were pushed
                > back due to failing unknown acceptance criteria.

                Yes. Stop doing that. It is impossible, as well as frustrating, to
                commit to work when we don't know how long it will take. That is
                not the "XP way" as I understand it. It is certainly not the way
                that I recommend be it XP or not.

                >>> I've pointed out that it hurts our productivity because it
                >>> requires us to switch contexts a couple days after the fact. I
                >>> haven't said that it messes up our planning, because I hadn't really
                >>> thought of it until I wrote this message. I'm not sure what impact
                >>> that will have, as my boss doesn't seem to find XP-style planning
                >>> particularly valuable. He appears to feel that everything needs to
                >>> get done, and it doesn't really matter in what order.

                Well, then he's right. But if he thinks things have to get done by a
                particular date, then he has to recognize his part of the job, which
                is to choose what to have done by that date, and what to have after
                the date. The team's job is to make the impact of his choices as
                clear as it can be.

                > We just got a deadline earlier this week. For the past 6 months
                > though, there have been no deadlines. I'm hoping that this deadline
                > will lead to more thought regarding prioritization.

                If by "deadline" we mean "delivery date", excellent. If we mean
                "date by which an unknown amount of work has to be done or
                development will have screwed up," there is work to do. As you
                correctly perceive, that work is prioritization.

                > I asked this inline above, but I'd like to mention it again here to
                > ensure we discuss it. What time relative to planning should we be
                > doing these design sessions? Particularly the ones that are used to
                > develop a shared understanding between customer and developers.

                As a rule, those conversations take long enough, and may need think
                time in between enough, to suggest that they should be held during
                the iteration prior to the story coming in as scheduled. I prefer to
                have as many people involved in those chats as possible, and accept
                that it may not be efficient or comfortable to have the entire team
                appear to be ganging up on the boss.

                Ron Jeffries
                www.XProgramming.com
                We cannot solve our problems with the same thinking we used when we created them.
                -- Albert Einstein
              Your message has been successfully submitted and would be delivered to recipients shortly.