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

Dealing With Overcommitment

Expand Messages
  • Jeff Heinen
    As a scrum master, how do you deal with chronic overcommitment and the resulting sprint failures? For example, when a team is routinely committing to 60 story
    Message 1 of 28 , Dec 1, 2006
    • 0 Attachment
      As a scrum master, how do you deal with chronic overcommitment and the resulting sprint failures? For example, when a team is routinely committing to 60 story points worth of work, but has a demonstrated velocity of around 30 for several sprints, I've been coaching scrum masters that this is a signal to step in and not allow it to continue. The scrum master should limit the committed work based on established velocity, and coach the PO on how to effectively prioritize the backlog and adjust the scope in order to get their date. I've found that teams seem to become more productive when they first establish a pattern of success and really understand what it means to be done. Then they seem to steadily increase their productivity, building on previous success until they reach a steady state of high productivity that's significantly higher than when they started. I'd rather have a team undercommit and get done early, and then pull in more backlog, rather than always ending a sprint with stuff not done.
       
      Often this situation occurs when an important project has a hard deadline and the PO *thinks* the scope is fixed (although on closer examination the backlog in these situations often seems to have a lot of stuff in it that isn't really required for the finished product; lots of nice-to-haves but not necessarily adding a lot of business value). The team looks at all of the backlog and simply divides it up among the all the sprints and commits to that work, not because they realistically think they can get it done, but because the date is fixed, the PO is putting a lot of pressure on the team to meet the date, and that's they only way they can meet the deadline.
       
      Is this the correct approach? Other suggestions?
       
      Jeff Heinen
      Director, Quality and Support Engineering
      Qpass - Amdocs Digital Commerce Division

      2211 Elliott Avenue| Suite 400 |Seattle , WA 98121
      o: +1.206.695.9509 | m: +1.425.785.9813 |
      f: +1.206.447.0669 | jheinen@...
       
    • William Wake
      ... Jeff - sounds like the right focus to me. I also talk to teams about committed vs. expected , and say that it s great to do more than you commit to, but
      Message 2 of 28 , Dec 1, 2006
      • 0 Attachment
        On 12/1/06, Jeff Heinen <jheinen@...> wrote:
        > [when teams repeatedly fail to deliver on commitments] I've been
        > coaching scrum masters that this is a signal to step in and not allow
        > it to continue. The scrum master should limit the committed work
        > based on established velocity, and coach the PO on how to effectively
        > prioritize the backlog and adjust the scope in order to get their date.

        Jeff - sounds like the right focus to me. I also talk to teams about
        "committed vs. expected", and say that it's great to do more than you
        commit to, but you need to get your commitments done so people can
        learn to rely on you.

        On the PO side, you might also consider the release burndown. At some
        point, the contradictions become sort of too obvious to ignore. "We
        said 60 but got 30; it was just a one-time thing." "We said 60 but got
        30, we'll catch up by doing 90 next month. (And then we have to do 120
        to catch up the month after that.)"

        It's not clear if the team is making the estimates/commitments, or
        they're being dictated by the PO. I've definitely had to hold back a
        PO, and say "let the team promise what it really feels it can." ("No
        pouting":)

        > I've found that teams seem to become more productive when they first
        > establish a pattern of success and really understand what it means
        > to be done.
        Amen!

        --
        Bill Wake William.Wake@... www.xp123.com
      • ryanpcooper
        I would say this is decidedly NOT the right approach. We also essentially arrived at a velocity by dividing the required scope by the number of iterations
        Message 3 of 28 , Dec 1, 2006
        • 0 Attachment
          I would say this is decidedly NOT the right approach. We also
          essentially arrived at a velocity by dividing the 'required' scope by
          the number of iterations (except our unrealistic 'velocity' came from
          an outside influence, not the team itself). This is coupled with a
          "not enough time for pairing/testing" mindset (we use XP; for those
          not familiar with the terminology, think of it as "not enough time for
          disciplined engineering practices"), resulting in silos of knowledge,
          lots of bottlenecks, and low quality code resulting in a lot of bugs.

          As a result, each iteration ends with a lot of stuff half-done and
          very little actually done, as we optimistically try to cover all the
          bases. This destroys the product owner's ability to plan ahead and
          prioritize effectively, which results in frequent changes of direction
          (Interestingly, scope affects priorities: as our product owner
          realizes we aren't going to get everything done, priorities shift,
          resulting in a change of direction). The combination of frequent
          changes of direction and a lot of 'dead' code due to many
          partially-implemented features results in a decline in velocity over
          time. This, unfortunately, makes the problem even worse.

          My recommendation to the Scrum Master in such a situation is to
          strictly limit the amount of work accepted to the team's
          empirically-proven velocity. I think that once there is some stability
          in delivery, velocity will increase naturally over time.

          Cheers,
          Ryan
          http://www.onagile.com


          --- In scrumdevelopment@yahoogroups.com, "Jeff Heinen" <jheinen@...>
          wrote:
          >
          > As a scrum master, how do you deal with chronic overcommitment and the
          > resulting sprint failures? For example, when a team is routinely
          > committing to 60 story points worth of work, but has a demonstrated
          > velocity of around 30 for several sprints, I've been coaching scrum
          > masters that this is a signal to step in and not allow it to continue.
          > The scrum master should limit the committed work based on established
          > velocity, and coach the PO on how to effectively prioritize the backlog
          > and adjust the scope in order to get their date. I've found that teams
          > seem to become more productive when they first establish a pattern of
          > success and really understand what it means to be done. Then they seem
          > to steadily increase their productivity, building on previous success
          > until they reach a steady state of high productivity that's
          > significantly higher than when they started. I'd rather have a team
          > undercommit and get done early, and then pull in more backlog, rather
          > than always ending a sprint with stuff not done.
          >
          > Often this situation occurs when an important project has a hard
          > deadline and the PO *thinks* the scope is fixed (although on closer
          > examination the backlog in these situations often seems to have a lot of
          > stuff in it that isn't really required for the finished product; lots of
          > nice-to-haves but not necessarily adding a lot of business value). The
          > team looks at all of the backlog and simply divides it up among the all
          > the sprints and commits to that work, not because they realistically
          > think they can get it done, but because the date is fixed, the PO is
          > putting a lot of pressure on the team to meet the date, and that's they
          > only way they can meet the deadline.
          >
          > Is this the correct approach? Other suggestions?
          >
          > Jeff Heinen
          > Director, Quality and Support Engineering
          > Qpass - Amdocs Digital Commerce Division
          > 2211 Elliott Avenue| Suite 400 | Seattle, WA 98121
          > o: +1.206.695.9509 | m: +1.425.785.9813 |
          > f: +1.206.447.0669 | jheinen@...
          >
        • William Wake
          ... I should have explicitly said - I also think that doing this [generating expected velocity given features and date] is *not* the right way to set
          Message 4 of 28 , Dec 1, 2006
          • 0 Attachment
            On 12/1/06, ryanpcooper <ryan.p.cooper@...> wrote:
            > I would say this is decidedly NOT the right approach. We also
            > essentially arrived at a velocity by dividing the 'required' scope by
            > the number of iterations [...]

            I should have explicitly said - I also think that doing this
            [generating "expected velocity" given features and date] is *not* the
            right way to set commitments (or velocity).

            I do agree with the steps Jeff outlined to deal with this: focusing on
            actual velocity, improving the backlog, and making sure "done means
            done."

            --
            Bill Wake William.Wake@... www.xp123.com
          • Ron Jeffries
            Hello, Jeff. On Friday, December 1, 2006, at 11:16:26 AM, you ... I m sorry, this seems to me to be an advanced question and I am not allowed to enter into
            Message 5 of 28 , Dec 1, 2006
            • 0 Attachment
              Hello, Jeff. On Friday, December 1, 2006, at 11:16:26 AM, you
              wrote:

              > As a scrum master, how do you deal with chronic overcommitment and the
              > resulting sprint failures? For example, when a team is routinely
              > committing to 60 story points worth of work, but has a demonstrated
              > velocity of around 30 for several sprints, I've been coaching scrum
              > masters that this is a signal to step in and not allow it to continue.
              > The scrum master should limit the committed work based on established
              > velocity, and coach the PO on how to effectively prioritize the backlog
              > and adjust the scope in order to get their date. I've found that teams
              > seem to become more productive when they first establish a pattern of
              > success and really understand what it means to be done. Then they seem
              > to steadily increase their productivity, building on previous success
              > until they reach a steady state of high productivity that's
              > significantly higher than when they started. I'd rather have a team
              > undercommit and get done early, and then pull in more backlog, rather
              > than always ending a sprint with stuff not done.

              I'm sorry, this seems to me to be an advanced question and I am not
              allowed to enter into advanced discussions.

              Ron Jeffries
              www.XProgramming.com
              I have tried in my way to be free. -- Leonard Cohen
            • Ron Jeffries
              Hello, ryanpcooper. On Friday, December 1, 2006, at 12:39:36 PM, ... Unless I am mistaken, which is quite possible, the way Scrum works as described in Scrum
              Message 6 of 28 , Dec 1, 2006
              • 0 Attachment
                Hello, ryanpcooper. On Friday, December 1, 2006, at 12:39:36 PM,
                you wrote:

                > My recommendation to the Scrum Master in such a situation is to
                > strictly limit the amount of work accepted to the team's
                > empirically-proven velocity. I think that once there is some stability
                > in delivery, velocity will increase naturally over time.

                Unless I am mistaken, which is quite possible, the way Scrum works
                as described in Scrum 101 is that the TEAM decides how much of the
                backlog they can consume, and they commit to getting that much fully
                done. They adjust until they're good at it.

                That's not happening where you are ... what is happening instead?

                Ron Jeffries
                www.XProgramming.com
                Accroche toi a ton reve. --ELO
              • Ron Jeffries
                Hello, Jeff. On Friday, December 1, 2006, at 11:16:26 AM, you ... I m curious: How is the team getting its commitments now? What do you imagine to be causing
                Message 7 of 28 , Dec 1, 2006
                • 0 Attachment
                  Hello, Jeff. On Friday, December 1, 2006, at 11:16:26 AM, you
                  wrote:

                  > As a scrum master, how do you deal with chronic overcommitment and the
                  > resulting sprint failures?

                  I'm curious: How is the team getting its commitments now? What do
                  you imagine to be causing them to overcommit all the time?

                  Ron Jeffries
                  www.XProgramming.com
                  Learn from yesterday, live for today, hope for tomorrow.
                  The important thing is to not stop questioning. --Albert Einstein
                • Jeff Heinen
                  What s happening is that we have fixed deadline and the team is very motivated to try and meet it. This is leading them to keep trying to get more done than
                  Message 8 of 28 , Dec 1, 2006
                  • 0 Attachment
                    What's happening is that we have fixed deadline and the team is very
                    motivated to try and meet it. This is leading them to keep trying to get
                    more done than they are currently capable of, which has lead to an
                    atmosphere were failing a sprint is not seen as a bad thing. The result
                    is that they don't really understand what it means to be successful. In
                    my experience, teams achieve the highest level of productivity when they
                    build on a history of success. A team that enters a sprint, knowing that
                    there's no way they can achieve everything they've taken on, isn't
                    really committed. They aren't self-organizing to achieve goals, but
                    rather scrambling to pack as much in as they can.

                    > -----Original Message-----
                    > From: scrumdevelopment@yahoogroups.com
                    > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
                    > Sent: Friday, December 01, 2006 10:09 AM
                    > To: scrumdevelopment@yahoogroups.com
                    > Subject: Re: [scrumdevelopment] Re: Dealing With Overcommitment
                    >
                    > Hello, ryanpcooper. On Friday, December 1, 2006, at 12:39:36
                    > PM, you wrote:
                    >
                    > > My recommendation to the Scrum Master in such a situation is to
                    > > strictly limit the amount of work accepted to the team's
                    > > empirically-proven velocity. I think that once there is
                    > some stability
                    > > in delivery, velocity will increase naturally over time.
                    >
                    > Unless I am mistaken, which is quite possible, the way Scrum
                    > works as described in Scrum 101 is that the TEAM decides how
                    > much of the backlog they can consume, and they commit to
                    > getting that much fully done. They adjust until they're good at it.
                    >
                    > That's not happening where you are ... what is happening instead?
                    >
                    > Ron Jeffries
                    > www.XProgramming.com
                    > Accroche toi a ton reve. --ELO
                    >
                    >
                    >
                    > To Post a message, send it to: scrumdevelopment@...
                    > To Unsubscribe, send a blank message to:
                    > scrumdevelopment-unsubscribe@...
                    > Yahoo! Groups Links
                    >
                    >
                    >
                    >
                  • Jeff Heinen
                    Management pressure coupled with a strong motivation to help the company succeed. The intentions are all good. What s happening is that the team does not grasp
                    Message 9 of 28 , Dec 1, 2006
                    • 0 Attachment
                      Management pressure coupled with a strong motivation to help the company
                      succeed. The intentions are all good. What's happening is that the team
                      does not grasp that limiting their commitment to what they can actually
                      do will ultimately lead to greater productivity. They haven't learned
                      *how* to be successful or develop a rhythm of success, so the habits
                      they are developing lead to gauranteed failure.

                      > -----Original Message-----
                      > From: scrumdevelopment@yahoogroups.com
                      > [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Ron Jeffries
                      > Sent: Friday, December 01, 2006 10:23 AM
                      > To: scrumdevelopment@yahoogroups.com
                      > Subject: Re: [scrumdevelopment] Dealing With Overcommitment
                      >
                      > Hello, Jeff. On Friday, December 1, 2006, at 11:16:26 AM, you
                      > wrote:
                      >
                      > > As a scrum master, how do you deal with chronic
                      > overcommitment and the
                      > > resulting sprint failures?
                      >
                      > I'm curious: How is the team getting its commitments now?
                      > What do you imagine to be causing them to overcommit all the time?
                      >
                      > Ron Jeffries
                      > www.XProgramming.com
                      > Learn from yesterday, live for today, hope for tomorrow.
                      > The important thing is to not stop questioning. --Albert Einstein
                      >
                      >
                      >
                      > To Post a message, send it to: scrumdevelopment@...
                      > To Unsubscribe, send a blank message to:
                      > scrumdevelopment-unsubscribe@...
                      > Yahoo! Groups Links
                      >
                      >
                      >
                      >
                    • Clinton Keith
                      From: Ron Jeffries ... The problem we ve seen is with the practice adjust until they re good at it . If the lowest priority stories are going to be dropped to
                      Message 10 of 28 , Dec 1, 2006
                      • 0 Attachment
                        From: Ron Jeffries
                        > Unless I am mistaken, which is quite possible, the way Scrum
                        > works as described in Scrum 101 is that the TEAM decides how
                        > much of the backlog they can consume, and they commit to
                        > getting that much fully done. They adjust until they're good
                        > at it.

                        The problem we've seen is with the practice "adjust until they're good
                        at it".

                        If the lowest priority stories are going to be dropped to hit the zero
                        backlog anyways, then the only motivation is the team's own level of
                        commitment and ownership to the backlog. I'd like to hear stories about
                        how teams get there.
                      • Wolfgang Schulze Zachau
                        Don t they (and everybody else) realize that this is just window dressing? In the end of the day, you will have to deliver something when that deadline comes.
                        Message 11 of 28 , Dec 1, 2006
                        • 0 Attachment
                          Don't they (and everybody else) realize that this is just window dressing? In the end of the day, you will have to deliver something when that deadline comes. Read Ron's blog about deadlines as a management responsibility. BTW: very well written, Ron.
                          I have to point out regularly in retrospectives what DONE actually means, and that the team has failed to achieve it. This puts the damper on a bit, but it also spurns them on, because they know they can do it (and they know that because they have done it before).
                          As I said earlier today on a different thread: this is calling for a bit of honesty in my opinion.
                          That deadline won't move. Neither will your velocity (at least not in the short term). Somethings gotta give. I believe your team needs a wakeup call, it needs to be faced with the harsh realities of life. Maybe the PO needs to be included as well.
                          What does he say to this overcommitment?
                           

                          Regards,

                          Wolfgang

                        • Ron Jeffries
                          Hello, Clinton. On Friday, December 1, 2006, at 1:36:37 PM, you ... Dropping stories does not mean you met your commitment, it means you failed to meet your
                          Message 12 of 28 , Dec 1, 2006
                          • 0 Attachment
                            Hello, Clinton. On Friday, December 1, 2006, at 1:36:37 PM, you
                            wrote:

                            > From: Ron Jeffries
                            >> Unless I am mistaken, which is quite possible, the way Scrum
                            >> works as described in Scrum 101 is that the TEAM decides how
                            >> much of the backlog they can consume, and they commit to
                            >> getting that much fully done. They adjust until they're good
                            >> at it.

                            > The problem we've seen is with the practice "adjust until they're good
                            > at it".

                            > If the lowest priority stories are going to be dropped to hit the zero
                            > backlog anyways, then the only motivation is the team's own level of
                            > commitment and ownership to the backlog. I'd like to hear stories about
                            > how teams get there.

                            Dropping stories does not mean you met your commitment, it means you
                            failed to meet your commitment.

                            What is causing the team not to estimate in such a way as to have to
                            drop no stories? Why do they not value making their commitments?

                            Ron Jeffries
                            www.XProgramming.com
                            Hold on to your dream. --ELO
                          • Ron Jeffries
                            Hello, Jeff. On Friday, December 1, 2006, at 1:36:10 PM, you ... This is pretty advanced, so I probably shouldn t say anything, but in fact it doesn t matter
                            Message 13 of 28 , Dec 1, 2006
                            • 0 Attachment
                              Hello, Jeff. On Friday, December 1, 2006, at 1:36:10 PM, you
                              wrote:

                              > Management pressure coupled with a strong motivation to help the company
                              > succeed. The intentions are all good. What's happening is that the team
                              > does not grasp that limiting their commitment to what they can actually
                              > do will ultimately lead to greater productivity. They haven't learned
                              > *how* to be successful or develop a rhythm of success, so the habits
                              > they are developing lead to gauranteed failure.

                              This is pretty advanced, so I probably shouldn't say anything, but
                              in fact it doesn't matter whether they'll be more productive or not.
                              What matters is that the way management comes to trust a team is
                              when they say what they'll do, and then do what they say. So long as
                              a team over-commits, they are lying to management every time around.

                              I'd advise against lying to management. It's a well-known CLM.

                              Ron Jeffries
                              www.XProgramming.com
                              Without practice, no emergence. -- Dougen Zenji
                            • Ron Jeffries
                              Hello, Jeff. On Friday, December 1, 2006, at 1:28:25 PM, you ... Someone should help them see that failure is not as good as success. I would have thought
                              Message 14 of 28 , Dec 1, 2006
                              • 0 Attachment
                                Hello, Jeff. On Friday, December 1, 2006, at 1:28:25 PM, you
                                wrote:

                                > What's happening is that we have fixed deadline and the team is very
                                > motivated to try and meet it. This is leading them to keep trying to get
                                > more done than they are currently capable of, which has lead to an
                                > atmosphere were failing a sprint is not seen as a bad thing.

                                Someone should help them see that failure is not as good as success.
                                I would have thought that everyone knew that, so I'm not sure how to
                                help beyond that simple suggestion.

                                > The result
                                > is that they don't really understand what it means to be successful.

                                I would think it would be relatively simple, at the end of the
                                Sprint, to point out that we drew the line here, and only got done
                                to here.

                                Then in planning, when they draw the line (do they draw the line, or
                                does someone else tell them where the line is???), ask them if
                                they're really going to get that much really done.

                                Raise the line until they say yes. Rinse, repeat.

                                It's not about success or failure, really. It's about correctly
                                predicting what's going to happen.

                                This next is heresy and will surely get me burned at the stake: a
                                shorter Sprint will help with this.

                                > In
                                > my experience, teams achieve the highest level of productivity when they
                                > build on a history of success. A team that enters a sprint, knowing that
                                > there's no way they can achieve everything they've taken on, isn't
                                > really committed. They aren't self-organizing to achieve goals, but
                                > rather scrambling to pack as much in as they can.

                                Your problem isn't productivity, in my opinion. It is
                                predictability.

                                Ron Jeffries
                                www.XProgramming.com
                                That's my opinion and I agree with it. -- Julio Santos
                              • Nicholas Cancelliere
                                I agree with Ron. I think it s a pitfall many fall into - misidentifying productivity vs. predictability issues. In my past experience I have had a team who
                                Message 15 of 28 , Dec 1, 2006
                                • 0 Attachment
                                  I agree with Ron.  I think it's a pitfall many fall into - misidentifying productivity vs. predictability issues.

                                  In my past experience I have had a team who was deemed "unproductive," because they never met their sprint commitments and had as a result a very low velocity.  The upper management would take the number of folks on a project, calculate how many hours they should be working, look at the estimates, and then scratch their heads as to why it wasn't working out.  

                                  The team was clocking over 380 hours (although they only got 140 hrs of velocity).  Looking at the causes, interruptions and firedrills in the sprint, the upper management are then faced with the reality that a lot of effort is expended on non-sprint related work.  The reality presents itself -- the team could really be humming if left alone.  Was the team unproductive?  Not at all.

                                  Can we predict what stories get done - yes by using the velocity of 140, not 380.  The difference between 140 and 380 represents the "uncertain" element that you can't plan because if history repeats itself (and usually it does, without conscious change) that time will be eaten up again with non-sprint work.



                                  On Dec 1, 2006, at 1:11 PM, Ron Jeffries wrote:

                                  Your problem isn't productivity, in my opinion. It is
                                  predictability.

                                • Ken Schwaber
                                  Teams overcommitting after the third sprint is a smell that they are not managing themselves. I ll bet they don t have an accurate sprint backlog that they are
                                  Message 16 of 28 , Dec 1, 2006
                                  • 0 Attachment

                                    Teams overcommitting after the third sprint is a smell that they are not managing themselves. I’ll bet they don’t have an accurate sprint backlog that they are updating, and I’ll bet that you don’t hear a group of people figuring out how they are going to meet their sprint goal every daily scrum.

                                    Ken

                                     


                                    From: scrumdevelopment@yahoogroups.com [mailto: scrumdevelopment@yahoogroups.com ] On Behalf Of Ron Jeffries
                                    Sent: Friday, December 01, 2006 1:09 PM
                                    To: scrumdevelopment@yahoogroups.com
                                    Subject: Re: [scrumdevelopment] Re: Dealing With Overcommitment

                                     

                                    Hello, ryanpcooper. On Friday, December 1, 2006, at 12:39:36 PM,
                                    you wrote:

                                    > My recommendation to the Scrum Master in such a situation is to
                                    > strictly limit the amount of work accepted to the team's
                                    > empirically- proven velocity. I think that once there is some
                                    stability
                                    > in delivery, velocity will increase naturally over time.

                                    Unless I am mistaken, which is quite possible, the way Scrum works
                                    as described in Scrum 101 is that the TEAM decides how much of the
                                    backlog they can consume, and they commit to getting that much fully
                                    done. They adjust until they're good at it.

                                    That's not happening where you are ... what is happening instead?

                                    Ron Jeffries
                                    www.XProgramming. com
                                    Accroche toi a ton reve. --ELO

                                  • Ken Schwaber
                                    Teams overcommitting after the third sprint is a smell that they are not managing themselves. I ll bet they don t have an accurate sprint backlog that they are
                                    Message 17 of 28 , Dec 1, 2006
                                    • 0 Attachment
                                      Teams overcommitting after the third sprint is a smell that they are
                                      not managing themselves. I'll bet they don't have an accurate sprint
                                      backlog that they are updating, and I'll bet that you don't hear a
                                      group of people figuring out how they are going to meet their sprint
                                      goal every daily scrum.

                                      Ken


                                      --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                                      <ronjeffries@...> wrote:
                                      >
                                      > Hello, ryanpcooper. On Friday, December 1, 2006, at 12:39:36 PM,
                                      > you wrote:
                                      >
                                      > > My recommendation to the Scrum Master in such a situation is to
                                      > > strictly limit the amount of work accepted to the team's
                                      > > empirically-proven velocity. I think that once there is some stability
                                      > > in delivery, velocity will increase naturally over time.
                                      >
                                      > Unless I am mistaken, which is quite possible, the way Scrum works
                                      > as described in Scrum 101 is that the TEAM decides how much of the
                                      > backlog they can consume, and they commit to getting that much fully
                                      > done. They adjust until they're good at it.
                                      >
                                      > That's not happening where you are ... what is happening instead?
                                      >
                                      > Ron Jeffries
                                      > www.XProgramming.com
                                      > Accroche toi a ton reve. --ELO
                                      >
                                    • Clinton Keith
                                      From: Ron Jeffries ... We re seeing a great deal of turnover and addition to the tasks to fulfill stories during the sprint. Much of this is attributed to the
                                      Message 18 of 28 , Dec 1, 2006
                                      • 0 Attachment
                                        From: Ron Jeffries

                                        > Dropping stories does not mean you met your commitment,
                                        > it means you failed to meet your commitment.

                                        > What is causing the team not to estimate in such a way
                                        > as to have to drop no stories? Why do they not value
                                        > making their commitments?

                                        We're seeing a great deal of turnover and addition to the tasks to
                                        fulfill stories during the sprint. Much of this is attributed to the
                                        nature of our product which is video games. Value is "fun".

                                        We first attempted to create very narrowly focused stories that could be
                                        broken down and estimated, we often don't see fun. The team would see
                                        that it wasn't going to be fun during the Sprint, but their story
                                        commitment didn't allow change.

                                        We then shifted to creating less stringent stories that allow the team
                                        to vary the task in the Sprint to a great degree to achieve their goals.
                                        This does require someone on the team to be a product owner. This
                                        created more "fun" per Sprint. It also created more reasons to drop
                                        lower priority stories; sometimes too easily.

                                        So I don't think that saying the team has "failed" is reasonable. On
                                        the other hand, casually dropping stories can often work at odds with
                                        having the highest sustainable level of intensity throughout the entire
                                        project.

                                        Clint
                                      • mpkirby
                                        ... The interesting question is what do you do about it. Does one manage a team into managing itself? Mike
                                        Message 19 of 28 , Dec 1, 2006
                                        • 0 Attachment

                                          Teams overcommitting after the third sprint is a smell that they are not managing themselves. I’ll bet they don’t have an accurate sprint backlog that they are updating, and I’ll bet that you don’t hear a group of people figuring out how they are going to meet their sprint goal every daily scrum.

                                          Ken

                                          The interesting question is what do you do about it.  Does one "manage a team into managing itself?"

                                          Mike


                                        • Ron Jeffries
                                          Hello, mpkirby. On Friday, December 1, 2006, at 7:16:29 PM, you ... I would remind them of the need to meet their commitments, and when they sign up, remind
                                          Message 20 of 28 , Dec 1, 2006
                                          • 0 Attachment
                                            Hello, mpkirby. On Friday, December 1, 2006, at 7:16:29 PM, you
                                            wrote:

                                            > The interesting question is what do you do about it. Does one "manage a
                                            > team into managing itself?"

                                            I would remind them of the need to meet their commitments, and when
                                            they sign up, remind them again, and every day ask them to look at
                                            how they're doing, and about a million other little things.

                                            Ron Jeffries
                                            www.XProgramming.com
                                            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, Clinton. On Friday, December 1, 2006, at 7:00:51 PM, you ... Are these technical tasks that should have been foreseen at planning time, or new things
                                            Message 21 of 28 , Dec 1, 2006
                                            • 0 Attachment
                                              Hello, Clinton. On Friday, December 1, 2006, at 7:00:51 PM, you
                                              wrote:

                                              > We're seeing a great deal of turnover and addition to the tasks to
                                              > fulfill stories during the sprint. Much of this is attributed to the
                                              > nature of our product which is video games.

                                              Are these technical tasks that "should" have been foreseen at
                                              planning time, or new things that the PO or someone is adding to the
                                              mix.

                                              If the latter: that's a no-no.

                                              > Value is "fun".

                                              Do you mean business value, or some other kind of value?

                                              > We first attempted to create very narrowly focused stories that could be
                                              > broken down and estimated, we often don't see fun. The team would see
                                              > that it wasn't going to be fun during the Sprint, but their story
                                              > commitment didn't allow change.

                                              Why's that? Why is knowing what you're going to do "not fun"?

                                              > We then shifted to creating less stringent stories that allow the team
                                              > to vary the task in the Sprint to a great degree to achieve their goals.
                                              > This does require someone on the team to be a product owner. This
                                              > created more "fun" per Sprint. It also created more reasons to drop
                                              > lower priority stories; sometimes too easily.

                                              I don't understand this. Is it you and your team's view that you are
                                              doing Scrum?

                                              > So I don't think that saying the team has "failed" is reasonable. On
                                              > the other hand, casually dropping stories can often work at odds with
                                              > having the highest sustainable level of intensity throughout the entire
                                              > project.

                                              Intensity is not, as far as I know, a desirable element.
                                              Predictability and transparency, on the other hand, are.

                                              Ron Jeffries
                                              www.XProgramming.com
                                              The lyf so short, the craft so long to lerne. -- Geoffrey Chaucer
                                            • clintonnkeith
                                              ... Neither. These are art/design/technical tasks that arise from the aesthic and emotional reponse to the prior attempt. For example, the team won t know if
                                              Message 22 of 28 , Dec 1, 2006
                                              • 0 Attachment
                                                --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                                                <ronjeffries@...> wrote:
                                                >
                                                > Hello, Clinton. On Friday, December 1, 2006, at 7:00:51 PM, you
                                                > wrote:
                                                >
                                                > > We're seeing a great deal of turnover and addition to the tasks to
                                                > > fulfill stories during the sprint. Much of this is attributed to the
                                                > > nature of our product which is video games.
                                                >
                                                > Are these technical tasks that "should" have been foreseen at
                                                > planning time, or new things that the PO or someone is adding to the
                                                > mix.
                                                >
                                                > If the latter: that's a no-no.
                                                >

                                                Neither. These are art/design/technical tasks that arise from the
                                                aesthic and emotional reponse to the prior attempt. For example, the
                                                team won't know if a character jump with one or four animations will
                                                look right under all circumstance, nor can they at planning.

                                                > > Value is "fun".
                                                >
                                                > Do you mean business value, or some other kind of value?
                                                >
                                                Business. Fun games sell copies.

                                                > > We first attempted to create very narrowly focused stories that
                                                could be
                                                > > broken down and estimated, we often don't see fun. The team would see
                                                > > that it wasn't going to be fun during the Sprint, but their story
                                                > > commitment didn't allow change.
                                                >
                                                > Why's that? Why is knowing what you're going to do "not fun"?
                                                >

                                                You can know if a story is resulting in a fun mechanic or not half-way
                                                through the sprint. What the team does as a result of that knowledge
                                                is the question here.

                                                > > We then shifted to creating less stringent stories that allow the team
                                                > > to vary the task in the Sprint to a great degree to achieve their
                                                goals.
                                                > > This does require someone on the team to be a product owner. This
                                                > > created more "fun" per Sprint. It also created more reasons to drop
                                                > > lower priority stories; sometimes too easily.
                                                >
                                                > I don't understand this. Is it you and your team's view that you are
                                                > doing Scrum?
                                                >

                                                We are doing Scrum, unless Mike Cohn (our coach) says we're not. The
                                                "PO as pig" may be debatable but it has improved business value velocity.

                                                > > So I don't think that saying the team has "failed" is reasonable. On
                                                > > the other hand, casually dropping stories can often work at odds with
                                                > > having the highest sustainable level of intensity throughout the
                                                entire
                                                > > project.
                                                >
                                                > Intensity is not, as far as I know, a desirable element.
                                                > Predictability and transparency, on the other hand, are.
                                                >

                                                So what reason is there for the team to commit to half of what they
                                                are capable of doing every Sprint? It would be more predictable and
                                                transparent....
                                              • Ron Jeffries
                                                Hello, Keith. On Friday, December 1, 2006, at 8:11:57 PM, ... I don t understand the question. And I may have missed something ... are you happy with the way
                                                Message 23 of 28 , Dec 1, 2006
                                                • 0 Attachment
                                                  Hello, Keith. On Friday, December 1, 2006, at 8:11:57 PM,
                                                  you wrote:

                                                  > So what reason is there for the team to commit to half of what they
                                                  > are capable of doing every Sprint? It would be more predictable and
                                                  > transparent....

                                                  I don't understand the question.

                                                  And I may have missed something ... are you happy with the way
                                                  things are going now?

                                                  Ron Jeffries
                                                  www.XProgramming.com
                                                  Thousands of years ago, the first man discovered how to make fire.
                                                  He was probably burned at the stake he had taught his brothers to
                                                  light - Howard Roark (The Fountainhead, Ayn Rand)
                                                • mpkirby
                                                  ... The Jiminy Cricket approach to being a scrum master. Yes. I d arrived at the same conclusion. Isn t it sad that the way to move forward is to be really
                                                  Message 24 of 28 , Dec 1, 2006
                                                  • 0 Attachment
                                                    > > The interesting question is what do you do about it. Does one "manage a
                                                    > > team into managing itself?"
                                                    >
                                                    > I would remind them of the need to meet their commitments, and when
                                                    > they sign up, remind them again, and every day ask them to look at
                                                    > how they're doing, and about a million other little things.

                                                    The Jiminy Cricket approach to being a scrum master. Yes. I'd arrived
                                                    at the same conclusion. Isn't it sad that the way to move forward is to
                                                    be really irritating to those around you :-)

                                                    Mike
                                                  • Ron Jeffries
                                                    Hello, mpkirby. On Friday, December 1, 2006, at 10:18:24 PM, you ... Well ... and this will be hard to believe, yet it s true ... I try not to be irritating,
                                                    Message 25 of 28 , Dec 2, 2006
                                                    • 0 Attachment
                                                      Hello, mpkirby. On Friday, December 1, 2006, at 10:18:24 PM, you
                                                      wrote:

                                                      > The Jiminy Cricket approach to being a scrum master. Yes. I'd arrived
                                                      > at the same conclusion. Isn't it sad that the way to move forward is to
                                                      > be really irritating to those around you :-)

                                                      Well ... and this will be hard to believe, yet it's true ...

                                                      I try not to be irritating, though I do sometimes fall short of that
                                                      high aspiration.

                                                      Ron Jeffries
                                                      www.XProgramming.com
                                                      The greatest mistake we make is living in constant fear that we will make one.
                                                      -- John Maxwell
                                                    • dnicolet99
                                                      ... manage a ... is to ... What they re talking about here is called coaching , and it isn t a question of being irritating. It s a question of helping the
                                                      Message 26 of 28 , Dec 2, 2006
                                                      • 0 Attachment
                                                        --- In scrumdevelopment@yahoogroups.com, mpkirby <mpkirby@...> wrote:
                                                        >
                                                        > > > The interesting question is what do you do about it. Does one
                                                        "manage a
                                                        > > > team into managing itself?"
                                                        > >
                                                        > > I would remind them of the need to meet their commitments, and when
                                                        > > they sign up, remind them again, and every day ask them to look at
                                                        > > how they're doing, and about a million other little things.
                                                        >
                                                        > The Jiminy Cricket approach to being a scrum master. Yes. I'd arrived
                                                        > at the same conclusion. Isn't it sad that the way to move forward
                                                        is to
                                                        > be really irritating to those around you :-)
                                                        >
                                                        > Mike
                                                        >

                                                        What they're talking about here is called "coaching", and it isn't a
                                                        question of being irritating. It's a question of helping the team
                                                        discover how to manage itself effectively, as opposed to jumping in
                                                        and trying to do it for them.
                                                      • dnicolet99
                                                        A smell? Yeah, but in this case it s just one scent in a mixed bouquet. There are a lot of red flags lurking between the lines of Ryan s description of the
                                                        Message 27 of 28 , Dec 2, 2006
                                                        • 0 Attachment
                                                          A smell? Yeah, but in this case it's just one scent in a mixed
                                                          bouquet. There are a lot of red flags lurking between the lines of
                                                          Ryan's description of the situation. It sounds like a very challenging
                                                          situation for the ScrumMaster, with issues to address at multiple
                                                          levels - team, customer, management, organization. Could be fun!



                                                          --- In scrumdevelopment@yahoogroups.com, "Ken Schwaber"
                                                          <ken.schwaber@...> wrote:
                                                          >
                                                          > Teams overcommitting after the third sprint is a smell that they are
                                                          > not managing themselves. I'll bet they don't have an accurate sprint
                                                          > backlog that they are updating, and I'll bet that you don't hear a
                                                          > group of people figuring out how they are going to meet their sprint
                                                          > goal every daily scrum.
                                                          >
                                                          > Ken
                                                          >
                                                          >
                                                          > --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                                                          > <ronjeffries@> wrote:
                                                          > >
                                                          > > Hello, ryanpcooper. On Friday, December 1, 2006, at 12:39:36 PM,
                                                          > > you wrote:
                                                          > >
                                                          > > > My recommendation to the Scrum Master in such a situation is to
                                                          > > > strictly limit the amount of work accepted to the team's
                                                          > > > empirically-proven velocity. I think that once there is some
                                                          stability
                                                          > > > in delivery, velocity will increase naturally over time.
                                                          > >
                                                          > > Unless I am mistaken, which is quite possible, the way Scrum works
                                                          > > as described in Scrum 101 is that the TEAM decides how much of the
                                                          > > backlog they can consume, and they commit to getting that much fully
                                                          > > done. They adjust until they're good at it.
                                                          > >
                                                          > > That's not happening where you are ... what is happening instead?
                                                          > >
                                                          > > Ron Jeffries
                                                          > > www.XProgramming.com
                                                          > > Accroche toi a ton reve. --ELO
                                                          > >
                                                          >
                                                        • ryanpcooper
                                                          To dnicolet99: You re quite right. We have a rather dysfunctional implementation of Scrum currently. In fact, some would probably not be happy with us calling
                                                          Message 28 of 28 , Dec 3, 2006
                                                          • 0 Attachment
                                                            To dnicolet99: You're quite right. We have a rather dysfunctional
                                                            implementation of Scrum currently. In fact, some would probably not be
                                                            happy with us calling it Scrum at all. ;)

                                                            To Ron: You're not mistaken, that is how Scrum works. Unfortunately,
                                                            it's not what we've been doing, and as a result our "Scrum" hasn't
                                                            been working. Our "velocity" was mandated from outside the team. This
                                                            was caused by some political pressures and a lack of understanding and
                                                            acceptance of Scrum in the organization as a whole. This has been a
                                                            (huge) roadblock for the team, one our Scrum Master is working to remove.

                                                            Cheers,
                                                            Ryan

                                                            --- In scrumdevelopment@yahoogroups.com, "dnicolet99" <dnicolet@...>
                                                            wrote:
                                                            >
                                                            > A smell? Yeah, but in this case it's just one scent in a mixed
                                                            > bouquet. There are a lot of red flags lurking between the lines of
                                                            > Ryan's description of the situation. It sounds like a very challenging
                                                            > situation for the ScrumMaster, with issues to address at multiple
                                                            > levels - team, customer, management, organization. Could be fun!
                                                            >
                                                            >
                                                            >
                                                            > --- In scrumdevelopment@yahoogroups.com, "Ken Schwaber"
                                                            > <ken.schwaber@> wrote:
                                                            > >
                                                            > > Teams overcommitting after the third sprint is a smell that they are
                                                            > > not managing themselves. I'll bet they don't have an accurate sprint
                                                            > > backlog that they are updating, and I'll bet that you don't hear a
                                                            > > group of people figuring out how they are going to meet their sprint
                                                            > > goal every daily scrum.
                                                            > >
                                                            > > Ken
                                                            > >
                                                            > >
                                                            > > --- In scrumdevelopment@yahoogroups.com, Ron Jeffries
                                                            > > <ronjeffries@> wrote:
                                                            > > >
                                                            > > > Hello, ryanpcooper. On Friday, December 1, 2006, at 12:39:36 PM,
                                                            > > > you wrote:
                                                            > > >
                                                            > > > > My recommendation to the Scrum Master in such a situation is to
                                                            > > > > strictly limit the amount of work accepted to the team's
                                                            > > > > empirically-proven velocity. I think that once there is some
                                                            > stability
                                                            > > > > in delivery, velocity will increase naturally over time.
                                                            > > >
                                                            > > > Unless I am mistaken, which is quite possible, the way Scrum works
                                                            > > > as described in Scrum 101 is that the TEAM decides how much of the
                                                            > > > backlog they can consume, and they commit to getting that much fully
                                                            > > > done. They adjust until they're good at it.
                                                            > > >
                                                            > > > That's not happening where you are ... what is happening instead?
                                                            > > >
                                                            > > > Ron Jeffries
                                                            > > > www.XProgramming.com
                                                            > > > Accroche toi a ton reve. --ELO
                                                            > > >
                                                            > >
                                                            >
                                                          Your message has been successfully submitted and would be delivered to recipients shortly.