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

Re: [!! SPAM] Re: [scrumdevelopment] What is the credit for an unfinished user story?

Expand Messages
  • Adrian Howard
    ... I ve never really noticed a difference with experienced teams. With newbie teams I like points because it helps me talk about things like bringing the
    Message 1 of 26 , Aug 31, 2009
    • 0 Attachment
      On 31 Aug 2009, at 13:25, Dan Rawsthorne wrote:

      > It's stuff like this that causes teams to go to commitment-based
      > planning rather than velocity-based planning. Commit to the work, not
      > the points!

      I've never really noticed a difference with experienced teams.

      With newbie teams I like points because it helps me talk about things
      like bringing the stories down to the same size, and not magically
      thinking we'll do more next iteration than we did this time around :)

      Adrian

      --
      http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
    • George Dinwiddie
      Cool! Glad to help, Sten. Please report back on what happens. - George ... -- ... * George Dinwiddie * http://blog.gdinwiddie.com
      Message 2 of 26 , Sep 1, 2009
      • 0 Attachment
        Cool! Glad to help, Sten. Please report back on what happens.

        - George

        Sten Otto Johnsen wrote:
        >
        >
        >
        >
        > This made me realize that I’ve been helping the team and the PO make the
        > whole thing becoming a game. It’s obvious to me now that if a story is
        > finished or not the team has no ”reward” for this. As George mentioned
        > the stories or storypoints are merely a tool for estimating the capacity
        > of the team during the next sprint. For this to be a good tool I need to
        > focus on work actually done through the sprint, not add to it the work
        > partially done in other, previous sprints.
        >
        >
        >
        > Thank you guys, I’ll bring this to the team for discussion.
        >
        >
        >
        > /Sten
        >
        >
        >
        > ------------------------------------------------------------------------
        >
        > *From:* scrumdevelopment@yahoogroups.com
        > [mailto:scrumdevelopment@yahoogroups.com] *On Behalf Of *George Dinwiddie
        > *Sent:* 31. august 2009 15:38
        > *To:* scrumdevelopment@yahoogroups.com
        > *Subject:* Re: [scrumdevelopment] What is the credit for an unfinished
        > user story?
        >
        >
        > Sten, story points aren't "credit." They're just a planning tool. If
        > you were to inflate the velocity of the second sprint with work done in
        > the first, it would likely lead to yet another sprint with unfinished
        > work at the end.
        >
        >
        > -------------------------------------------------------------------
        > The information contained in this message may be CONFIDENTIAL and is
        > intended for the addressee only. Any unauthorised use, dissemination of the
        > information or copying of this message is prohibited. If you are not the
        > addressee, please notify the sender immediately by return e-mail and delete
        > this message.
        > Thank you.
        >
        >


        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      • Doug McQuilken
        Sten, When faced with this situation, due to unresolved impediments etc., we re-estimated points for the remaining stories. The difference was the credit for
        Message 3 of 26 , Sep 1, 2009
        • 0 Attachment
          Sten,

          When faced with this situation, due to unresolved impediments etc., we re-estimated points for the remaining stories. The difference was the credit for the previous sprint.

          While a "game", it does provide a sense of progress for the team.  In addition, it maintains some degree of rationality for calculating velocity.

          Regards,
          Doug

          --- On Tue, 9/1/09, Sten Otto Johnsen <steoj@...> wrote:

          From: Sten Otto Johnsen <steoj@...>
          Subject: RE: [scrumdevelopment] What is the credit for an unfinished user story?
          To: scrumdevelopment@yahoogroups.com
          Date: Tuesday, September 1, 2009, 2:34 AM

           

           

          This made me realize that I’ve been helping the team and the PO make the whole thing becoming a game. It’s obvious to me now that if a story is finished or not the team has no ”reward” for this. As George mentioned the stories or storypoints are merely a tool for estimating the capacity of the team during the next sprint. For this to be a good tool I need to focus on work actually done through the sprint, not add to it the work partially done in other, previous sprints.

           

          Thank you guys,  I’ll bring this to the team for discussion.

           

          /Sten

           


          From: scrumdevelopment@ yahoogroups. com [mailto:scrumdevelo pment@yahoogroup s.com] On Behalf Of George Dinwiddie
          Sent: 31. august 2009 15:38
          To: scrumdevelopment@ yahoogroups. com
          Subject: Re: [scrumdevelopment] What is the credit for an unfinished user story?


          Sten, story points aren't "credit." They're just a planning tool. If
          you were to inflate the velocity of the second sprint with work done in
          the first, it would likely lead to yet another sprint with unfinished
          work at the end.


          ------------ --------- --------- --------- --------- --------- --------- -
          The information contained in this message may be CONFIDENTIAL and is
          intended for the addressee only. Any unauthorised use, dissemination of the
          information or copying of this message is prohibited. If you are not the
          addressee, please notify the sender immediately by return e-mail and delete
          this message.
          Thank you.

        • Ron Jeffries
          Hello, Doug. On Tuesday, September 1, 2009, at 2:05:18 PM, you ... I prefer a sense of necessity to get things /done/ to a sense of progress. I prefer to
          Message 4 of 26 , Sep 1, 2009
          • 0 Attachment
            Hello, Doug. On Tuesday, September 1, 2009, at 2:05:18 PM, you
            wrote:


            > When faced with this situation, due to unresolved impediments
            > etc., we re-estimated points for the remaining stories. The
            > difference was the credit for the previous sprint.

            > While a "game", it does provide a sense of progress for the team.
            > In addition, it maintains some degree of rationality for calculating velocity.

            I prefer a sense of necessity to get things /done/ to a sense of
            progress. I prefer to calculate velocity based on things that are
            /done/, not on things that are not done.

            Ron Jeffries
            www.XProgramming.com
            www.xprogramming.com/blog
            Adapt, improvise, overcome.
            --Gunnery Sergeant Tom Highway (Heartbreak Ridge)
          • petriheiramo
            Hi, ... I think this is different from just not being able to get a story done. However, even in this one I d hesitate to change the estimate. That is, I
            Message 5 of 26 , Sep 1, 2009
            • 0 Attachment
              Hi,


              > > Don't re-estimate the story for the next iteration. You can of
              > > course talk how much of the work is left (which should also be quite
              > > apparent from the undone tasks), but don't change the total
              > > estimate. Thus "the team gets the credit" at the end of the
              > > iteration they actually complete the story, and this way your
              > > average velocity is not affected by these.
              >
              > I would have thought you should estimate the story again. It might
              > turn out that they didn't finish it because what they thought was a 1
              > point story was actually a 3 point story - or more likely three 1
              > point stories.

              I think this is different from just not being able to get a story done. However, even in this one I'd hesitate to change the estimate. That is, I usually don't like to change estimates for things done or ongoing, but if the understanding gained reflects on things not yet done, then I'd obviously re-estimate those.

              Velocity isn't so accurate anyways that a couple of stories isn't likely to change the average value in any significant way.

              > Shouldn't the team use what they learned about the story, and the
              > reasons for not completing it, and work with the product owner with
              > that information?

              Yes, and I don't mind the team bringing it up in retrospective. "This story proved to be larger than we thought. We need to increase the sizes of similar stories in the future by a bit."


              Yours Sincerely,


              Petri

              ---
              Petri Heiramo
              Process Development Manager, Agile Coach (CST)
              Digia Plc., Finland
            • Ron Jeffries
              Hello, petriheiramo. On Wednesday, September 2, 2009, at 1:21:15 ... Better: We need to break these stories down a bit more ... Ron Jeffries
              Message 6 of 26 , Sep 2, 2009
              • 0 Attachment
                Hello, petriheiramo. On Wednesday, September 2, 2009, at 1:21:15
                AM, you wrote:

                > Yes, and I don't mind the team bringing it up in retrospective.
                > "This story proved to be larger than we thought. We need to
                > increase the sizes of similar stories in the future by a bit."

                Better: We need to break these stories down a bit more ...

                Ron Jeffries
                www.XProgramming.com
                www.xprogramming.com/blog
                You do ill if you praise, but worse if you censure,
                what you do not understand. --Leonardo da Vinci
              • SUMIT KUMAR
                We follow pretty much same concept as Doug mentioned. As it is called generally Hangover of stories, in our next sprint planning we take that user stroy and
                Message 7 of 26 , Sep 3, 2009
                • 0 Attachment
                  We follow pretty much same concept as Doug mentioned.
                  As it is called generally Hangover of stories, in our next sprint planning we take that user stroy and reassess on how many worth of points we achieved and how much we are carrying to next sprint.
                  The one achieved in last sprint goes for counting under Sprint Velocity for that sprint.
                   
                  Thanks,
                  Sumit


                  Love Cricket? Check out live scores, photos, video highlights and more. Click here.
                • Cenk Çivici
                  I d see hangover stories as a problem and try to minimize such unfinished stories by fixing issues around it. Playing with numbers and counting story points of
                  Message 8 of 26 , Sep 3, 2009
                  • 0 Attachment
                    I d see hangover stories as a problem and try to minimize such
                    unfinished stories by fixing issues around it.
                    Playing with numbers and counting story points of hangover stories. We
                    do sprint estimation by real days so
                    if there are unfinished stories, we estimate the remaining work and
                    the story is counted in the velocity once it is "done done done"


                    On Thu, Sep 3, 2009 at 10:00 AM, SUMIT
                    KUMAR<sumit_kumar_jaiswal@...> wrote:
                    >
                    >
                    > We follow pretty much same concept as Doug mentioned.
                    > As it is called generally Hangover of stories, in our next sprint planning
                    > we take that user stroy and reassess on how many worth of points we achieved
                    > and how much we are carrying to next sprint.
                    > The one achieved in last sprint goes for counting under Sprint Velocity for
                    > that sprint.
                    >
                    > Thanks,
                    > Sumit
                    > ________________________________
                    > Love Cricket? Check out live scores, photos, video highlights and more.
                    > Click here.
                    >
                    >
                  • davenicolette
                    Interesting thread. Lots of different ideas. FWIW I m on board with Ron. If you can just count the stories, that s best. I think there is a prerequisite to
                    Message 9 of 26 , Sep 4, 2009
                    • 0 Attachment
                      Interesting thread. Lots of different ideas. FWIW I'm on board with Ron. If you can just count the stories, that's best.

                      I think there is a prerequisite to being able to just count the stories. The team has to learn to break stories down into a small size, such that differences between the size of stories aren't significant enough to affect short-term planning.

                      I've found that a good way to influence teams in that direction is to shorten the iteration length so that they don't have enough of a cushion to define large stories. One week seems to work well. But that's only a mechanism to help drive story size down. If you can define small stories and still work with a longer iteration, that's okay too.

                      Not all teams are "ready" for that. A large story can blow their iteration out of the water if they don't realize how large it is. Next best, I guess, is to size stories in terms of an abstraction like Story Points. IMHO the team should continue to improve its ability to break stories down and eventually outgrow the need for sizing. Sizing is lighter-weight than estimation, but it's still overhead.

                      When I read/hear people talking about ideal time, it strikes me as perhaps the least mature application of agile thinking of the three (commitment, points, ideal time). I'd suggest people be careful about fooling themselves with word-tricks. People who peg "points" to time (for instance, "one point is equal to 4 hours of ideal time") are still thinking about time and still "estimating" rather than "sizing". That's a smell. If you cover the smell with pretty words, you deny yourself the opportunity to improve.

                      I don't think any of these approaches is "wrong." I think they just represent different levels of maturity in agile practice. I think that any reference to time in the estimates is a process smell the team ought to discuss in their retrospectives, to see if they can move from estimation in terms of ideal time to sizing in terms of points. They should also do as Ron suggests and continue to improve their ability to break stories down.

                      I think it's okay for a team to push themselves a little too far, as a way to discover their (present) limits. So if you want to try commitment-based iteration planning for a couple of iterations, and you learn that things don't work so well, you can always drop back to story sizing or even task estimation, if that's what is workable in your situation at the moment. At least you won't have to guess at where your limits are, and you can set realistic goals for improvement.

                      Ultimately I think it's best if a team can keep work flowing smoothly and delivering value regularly, predictably, and sustainably. The lighter-weight the short-term planning process can be, the easier it is to achieve that level of effectiveness.

                      In order to get there, a team has to be aware that task decomposition, estimation in terms of time, and even sizing in terms of points aren't the "end game" in agile development. Otherwise, they might not realize there's anything to improve, and they'll settle into a comfort zone.

                      Dave

                      --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                      >
                      > Hello, petriheiramo. On Wednesday, September 2, 2009, at 1:21:15
                      > AM, you wrote:
                      >
                      > > Yes, and I don't mind the team bringing it up in retrospective.
                      > > "This story proved to be larger than we thought. We need to
                      > > increase the sizes of similar stories in the future by a bit."
                      >
                      > Better: We need to break these stories down a bit more ...
                      >
                      > Ron Jeffries
                      > www.XProgramming.com
                      > www.xprogramming.com/blog
                      > You do ill if you praise, but worse if you censure,
                      > what you do not understand. --Leonardo da Vinci
                      >
                    • sschuermann303
                      ... 1. The answer is 0 2. Credit is a meassuring business, remember the sentence: We re not in the meassuring business. We re in the delivering features
                      Message 10 of 26 , Sep 4, 2009
                      • 0 Attachment
                        --- In scrumdevelopment@yahoogroups.com, "sten.johnsen" <steoj@...> wrote:
                        >
                        > I've been serving a team of 8 as a scrum master for 6 months. I must admit it has happened that a user story or two was not completed by the sprint demo. Usually only a few tasks left, but nevertheless no storypoints awarded for those.
                        > Also equally usually the PO wanted the story completed during the next sprint and during sprint planning the size of the story is a lot smaller in story points now than in the previous sprint.
                        >
                        > How does people do this. Does the team get the credit for the origianl storypoints when they finish the user story during the next sprint or do they only get credit for what was planned for in the sprint they actually completed it?
                        >
                        > /Sten
                        >

                        1. The answer is 0

                        2. Credit is a meassuring business, remember the sentence:

                        "We're not in the meassuring business. We're in the delivering features business" Inglorious Programmers 2009

                        3. It happens, again and again in our team (like 0-10% in storypoints)
                        Work on it, it's the "game" of the really skilled teams that deliver 100% and on time. If you get worries about this, remember how all things have been before scrum. ;). I guess the delivering all on time mantra is the very basic reason why scrum teams have very high productivity values.

                        Sebastian
                      Your message has been successfully submitted and would be delivered to recipients shortly.