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

What is the credit for an unfinished user story?

Expand Messages
  • sten.johnsen
    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.
    Message 1 of 26 , Aug 31, 2009
    • 0 Attachment
      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
    • Adrian Howard
      ... Just estimate the work left to do. Can t see that doing it any other way would get you any benefit. Adrian -- http://quietstars.com - twitter.com/adrianh
      Message 2 of 26 , Aug 31, 2009
      • 0 Attachment
        On 31 Aug 2009, at 13:08, sten.johnsen wrote:

        > 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?


        Just estimate the work left to do. Can't see that doing it any other
        way would get you any benefit.

        Adrian
        --
        http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
      • Dan Rawsthorne
        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! Dan
        Message 3 of 26 , Aug 31, 2009
        • 0 Attachment
          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!

          Dan Rawsthorne, PhD, CST
          Senior Coach, Danube Technologies
          dan@..., 425-269-8628



          Adrian Howard wrote:
          >
          >
          >
          > On 31 Aug 2009, at 13:08, sten.johnsen wrote:
          >
          > > 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?
          >
          > Just estimate the work left to do. Can't see that doing it any other
          > way would get you any benefit.
          >
          > Adrian
          > --
          > http://quietstars.com <http://quietstars.com> - twitter.com/adrianh -
          > delicious.com/adrianh
          >
          >
        • 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 4 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
            ... 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,
            Message 5 of 26 , Aug 31, 2009
            • 0 Attachment
              sten.johnsen 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, 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.

              Count the newly estimated points for the remaining work toward the
              velocity measurement. Use velocity to estimate the amount of work that
              will fit in a sprint, but back that up with commitment--the team should
              step back and ask themselves, "Is this the amount of work we can
              accomplish this sprint?"

              Also, consider splitting stories into smaller, but still functional,
              stories. This will give you finer-grained progress tracking and less
              uncertainty than task-based splitting.

              - George

              --
              ----------------------------------------------------------------------
              * George Dinwiddie * http://blog.gdinwiddie.com
              Software Development http://www.idiacomputing.com
              Consultant and Coach http://www.agilemaryland.org
              ----------------------------------------------------------------------
            • Ron Jeffries
              Hello, sten.johnsen. On Monday, August 31, 2009, at 8:08:32 AM, ... I no longer recommend story points. I d just count stories. If this seems to be a problem
              Message 6 of 26 , Aug 31, 2009
              • 0 Attachment
                Hello, sten.johnsen. On Monday, August 31, 2009, at 8:08:32 AM,
                you wrote:

                > 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?

                I no longer recommend story points. I'd just count stories. If this
                seems to be a problem because stories vary in size, it tells us that
                stories vary too much in size, not that we need a way of sizing
                stories.

                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
              • juan_banda
                Ron, Do you measure user stories size using hours, complexity or a mix of both? Regards, Juan
                Message 7 of 26 , Aug 31, 2009
                • 0 Attachment
                  Ron,

                  Do you measure user stories size using hours, complexity or a mix of both?

                  Regards,

                  Juan

                  --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                  >
                  > Hello, sten.johnsen. On Monday, August 31, 2009, at 8:08:32 AM,
                  > you wrote:
                  >
                  > > 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?
                  >
                  > I no longer recommend story points. I'd just count stories. If this
                  > seems to be a problem because stories vary in size, it tells us that
                  > stories vary too much in size, not that we need a way of sizing
                  > stories.
                  >
                  > 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
                  >
                • Ron Jeffries
                  Hello, juan_banda. On Monday, August 31, 2009, at 10:18:53 AM, ... Count them. Ron Jeffries www.XProgramming.com www.xprogramming.com/blog Debugging is twice
                  Message 8 of 26 , Aug 31, 2009
                  • 0 Attachment
                    Hello, juan_banda. On Monday, August 31, 2009, at 10:18:53 AM,
                    you wrote:

                    > Do you measure user stories size using hours, complexity or a mix of both?

                    Count them.

                    Ron Jeffries
                    www.XProgramming.com
                    www.xprogramming.com/blog
                    Debugging is twice as hard as writing the code in the first place.
                    Therefore, if you write the code as cleverly as possible, you are,
                    by definition, not smart enough to debug it. -- Brian Kernighan
                  • juan_banda
                    But how do you do work balancing? I mean, what criteria you use for splitting user stories? Regards, Juan
                    Message 9 of 26 , Aug 31, 2009
                    • 0 Attachment
                      But how do you do work balancing? I mean, what criteria you use for splitting user stories?

                      Regards,

                      Juan

                      --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                      >
                      > Hello, juan_banda. On Monday, August 31, 2009, at 10:18:53 AM,
                      > you wrote:
                      >
                      > > Do you measure user stories size using hours, complexity or a mix of both?
                      >
                      > Count them.
                      >
                      > Ron Jeffries
                      > www.XProgramming.com
                      > www.xprogramming.com/blog
                      > Debugging is twice as hard as writing the code in the first place.
                      > Therefore, if you write the code as cleverly as possible, you are,
                      > by definition, not smart enough to debug it. -- Brian Kernighan
                      >
                    • Paul Hudson
                      Ø What criteria you use for splitting user stories? Can this story be split into two, both of which have value to the customer? If so, split ‘em. Lather,
                      Message 10 of 26 , Aug 31, 2009
                      • 0 Attachment

                        Ø  What criteria you use for splitting user stories?

                         

                        Can this story be split into two, both of which have value to the customer? If so, split ‘em. Lather, rinse, repeat.

                         

                        Paul

                      • petriheiramo
                        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
                        Message 11 of 26 , Aug 31, 2009
                        • 0 Attachment
                          Hi,


                          > 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?

                          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.

                          Just as a side note, I realize the term "get credit for stories" is one I don't like. It's like the team is awarded points just like in a game. But it isn't game. The purpose of the velocity isn't to measure the team or serve as a metric of the team's performance (and thus averaging it over several iterations shouldn't be a problem). Instead, it is merely an averaged out value used to provide visibility into what can be expected to be achieved in the future.

                          With that approach, the whole discussion of "when the team should get credit" is totally irrelevant.


                          Yours Sincerely,


                          Petri

                          ---
                          Petri Heiramo
                          Process Development Manager, Agile Coach (CST)
                          Digia Plc., Finland
                        • petriheiramo
                          Hi Juan, ... Please define work balancing . If it is what I think it is, you don t do it. In general, the approach Ron suggests requires that the team has the
                          Message 12 of 26 , Aug 31, 2009
                          • 0 Attachment
                            Hi Juan,


                            > But how do you do work balancing? I mean, what criteria you use for splitting user stories?

                            Please define "work balancing". If it is what I think it is, you don't do it.

                            In general, the approach Ron suggests requires that the team has the skills to break down the stories into level in which the variation in size is not highly relevant. The law of big numbers adds up their amount into a meaningful velocity value. I personally don't think unexperienced teams would be well off with this approach, but I've never tried it with a team yet (I usually end up coaching new teams as we are still ramping up the use of Scrum in our company).

                            The approach is somewhat like saying "from this point on, let's break our stories small enough that they are about 5." Once you do that, you can simply add them up.


                            Yours Sincerely,


                            Petri

                            ---
                            Petri Heiramo
                            Process Development Manager, Agile Coach (CST)
                            Digia Plc., Finland


                            >
                            > --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@> wrote:
                            > >
                            > > Hello, juan_banda. On Monday, August 31, 2009, at 10:18:53 AM,
                            > > you wrote:
                            > >
                            > > > Do you measure user stories size using hours, complexity or a mix of both?
                            > >
                            > > Count them.
                            > >
                            > > Ron Jeffries
                            > > www.XProgramming.com
                            > > www.xprogramming.com/blog
                            > > Debugging is twice as hard as writing the code in the first place.
                            > > Therefore, if you write the code as cleverly as possible, you are,
                            > > by definition, not smart enough to debug it. -- Brian Kernighan
                            > >
                            >
                          • Piotr Żołnierek
                            Hi I agree with mostly with Ron. Stories is a little bit to thick-grained. We use tasks instead, each is supposed to be approximately between 4 and 12 hours of
                            Message 13 of 26 , Aug 31, 2009
                            • 0 Attachment

                              Hi

                               

                              I agree with mostly with Ron. Stories is a little bit to thick-grained. We use tasks instead, each is supposed to be approximately between 4 and 12 hours of ideal work.

                              Story Points never worked well with the teams I worked with, and they are “extra work” which people find hard to understand.

                              Then we have our board and we can visually see our progress by the number of tasks (cards) still active.

                               

                              But going back to the main topic… either a story is done 99.9% or it isn’t done at all.

                               

                              Piotr

                               

                              From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of petriheiramo
                              Sent: Monday, August 31, 2009 9:22 PM
                              To: scrumdevelopment@yahoogroups.com
                              Subject: [scrumdevelopment] Re: What is the credit for an unfinished user story?

                               

                               

                              Hi Juan,

                              > But how do you do work balancing? I mean, what criteria you use for
                              splitting user stories?

                              Please define "work balancing". If it is what I think it is, you don't do it.

                              In general, the approach Ron suggests requires that the team has the skills to break down the stories into level in which the variation in size is not highly relevant. The law of big numbers adds up their amount into a meaningful velocity value. I personally don't think unexperienced teams would be well off with this approach, but I've never tried it with a team yet (I usually end up coaching new teams as we are still ramping up the use of Scrum in our company).

                              The approach is somewhat like saying "from this point on, let's break our stories small enough that they are about 5." Once you do that, you can simply add them up.

                              Yours Sincerely,

                              Petri

                              ---
                              Petri Heiramo
                              Process Development Manager, Agile Coach (CST)
                              Digia Plc., Finland

                              >
                              > --- In scrumdevelopment@yahoogroups.com,
                              Ron Jeffries <ronjeffries@> wrote:
                              > >
                              > > Hello, juan_banda. On Monday, August 31, 2009, at 10:18:53 AM,
                              > > you wrote:
                              > >
                              > > > Do you measure user stories size using hours, complexity or a
                              mix of both?
                              > >
                              > > Count them.
                              > >
                              > > Ron Jeffries
                              > > www.XProgramming.com
                              > > www.xprogramming.com/blog
                              > > Debugging is twice as hard as writing the code in the first place.
                              > > Therefore, if you write the code as cleverly as possible, you are,
                              > > by definition, not smart enough to debug it. -- Brian Kernighan
                              > >
                              >

                               

                            • Adrian Howard
                              ... 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
                              Message 14 of 26 , Aug 31, 2009
                              • 0 Attachment
                                On 31 Aug 2009, at 20:14, petriheiramo wrote:

                                > 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.

                                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?

                                Adrian

                                --
                                http://quietstars.com - twitter.com/adrianh - delicious.com/adrianh
                              • Markus Gaertner
                                Hi Sten, First of all it s fine to define a story incomplete not counting for the overall velocity. You don t know how much effort will be left, is it finished
                                Message 15 of 26 , Aug 31, 2009
                                • 0 Attachment
                                  Hi Sten,

                                  First of all it's fine to define a story incomplete not counting for the
                                  overall velocity. You don't know how much effort will be left, is it finished
                                  by 80%? Maybe 79.8%? In addition I see a problem when giving partial credit
                                  during the next iteration. By then the velocity will actually not reflect what
                                  was achieved. I see several options here:
                                  - the story was too huge for the iteration. It should have been replaced by a
                                  smaller one.
                                  - the story should have been broken down into several smaller parts
                                  - the story was taken into the iteration consciously in order to have it
                                  finished in the next iteration.

                                  I am sure that you can imagine an even longer list of possible interpretations.

                                  In any case you should make a reflection on this and have the team decide how
                                  to interpret the result when a user story was not completed. Then go ahead and
                                  try to fix the root cause behind this, so it's unlikely to re-occur in the future.

                                  Kind regards
                                  Markus Gärtner

                                  > 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?
                                • inanc_gumus
                                  Hello, sten.johsen, ... I agree with Ron. We are trying this (counting only stories) for three months and it works good, it feels good. Before, we tried
                                  Message 16 of 26 , Aug 31, 2009
                                  • 0 Attachment
                                    Hello, sten.johsen,
                                    --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <ronjeffries@...> wrote:
                                    >
                                    > I no longer recommend story points. I'd just count stories. If this
                                    > seems to be a problem because stories vary in size, it tells us that
                                    > stories vary too much in size, not that we need a way of sizing
                                    > stories.
                                    >
                                    > Ron Jeffries
                                    >

                                    I agree with Ron. We are trying this (counting only stories) for three months and it works good, it feels good.

                                    Before, we tried counting with points, but we came to an understanding empirically that the real essence is to split the stories to an end which each story's size is nearly equal. To and end that, you can include a few stories in a sprint that team commits, by not points, by gut-feeling divided by two.

                                    And then, you can also calculate a velocity for estimation about future work. In the end, by definition, average of all of the stories will be your velocity.

                                    Also, aware of that, your team wants to produce results. So, help them, not measure them which causes an unwanted disruption.
                                  • Sten Otto Johnsen
                                    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
                                    Message 17 of 26 , Aug 31, 2009
                                    • 0 Attachment

                                       

                                      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. size

                                    • George Dinwiddie
                                      Cool! Glad to help, Sten. Please report back on what happens. - George ... -- ... * George Dinwiddie * http://blog.gdinwiddie.com
                                      Message 18 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 19 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 20 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 21 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 22 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 23 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 24 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 25 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 26 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.