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

Non-story PBIs

Expand Messages
  • Bret Wortman
    How do you all deal with non-story PBIs. I have some new-to-scrum and new-to-Agile developers who have recently written stories like this: As a developer, I
    Message 1 of 14 , Feb 1, 2012
    • 0 Attachment
      How do you all deal with non-story PBIs. I have some new-to-scrum and new-to-Agile developers who have recently written stories like this:

      "As a developer, I want a clean separation beteween generated code and hand-written code so I don't have to manually merge code each time I have to...." and so on. The ideas being put forward have definite merit, but they're not stories (they fail the V in INVEST, for starters) but I'm not sure how to best capture them.  Should they reside in the backlog as non-stories, should they be captured during the retrospective as best practices to be put into practice during the next sprint? How would you handle this?


      Bret Wortman

    • RonJeffries
      Those are not PBIs as I understand the idea. R ... Ron Jeffries www.XProgramming.com I know we always like to say it ll be easier to do it now than it will be
      Message 2 of 14 , Feb 1, 2012
      • 0 Attachment
        Those are not PBIs as I understand the idea.
        R
        On Feb 1, 2012, at 7:50 AM, Bret Wortman wrote:

        "As a developer, I want a clean separation beteween generated code and hand-written code so I don't have to manually merge code each time I have to...." and so on. The ideas being put forward have definite merit, but they're not stories (they fail the V in INVEST, for starters) but I'm not sure how to best capture them.  Should they reside in the backlog as non-stories, should they be captured during the retrospective as best practices to be put into practice during the next sprint? How would you handle this?


        Ron Jeffries
        I know we always like to say it'll be easier to do it now than it
        will be to do it later. Not likely. I plan to be smarter later than
        I am now, so I think it'll be just as easy later, maybe even easier.
        Why pay now when we can pay later?

      • Bret Wortman
        Good. They re not as I understand it either. I m just really struggling with how the team ought to capture the fact that there s work to be done to make these
        Message 3 of 14 , Feb 1, 2012
        • 0 Attachment
          Good. They're not as I understand it either. I'm just really struggling with how the team ought to capture the fact that there's work to be done to make these wants, shared by the team as a whole, come to fruition. Or is this something that, if it truly is desired by the whole team, will just start to happen as a result of everyone's focus being brought to the issue? Does it even need to be captured anywhere at all?

          Is the conversation enough?


          Bret Wortman



          On Wed, Feb 1, 2012 at 9:08 AM, RonJeffries <ronjeffries@...> wrote:
           

          Those are not PBIs as I understand the idea.

          R

          On Feb 1, 2012, at 7:50 AM, Bret Wortman wrote:

          "As a developer, I want a clean separation beteween generated code and hand-written code so I don't have to manually merge code each time I have to...." and so on. The ideas being put forward have definite merit, but they're not stories (they fail the V in INVEST, for starters) but I'm not sure how to best capture them.  Should they reside in the backlog as non-stories, should they be captured during the retrospective as best practices to be put into practice during the next sprint? How would you handle this?


          Ron Jeffries
          I know we always like to say it'll be easier to do it now than it
          will be to do it later. Not likely. I plan to be smarter later than
          I am now, so I think it'll be just as easy later, maybe even easier.
          Why pay now when we can pay later?


        • Richard Hundhausen
          It would make more sense to add a technical practice like that to the team s definition of done. I d rewrite it to be more normalized (auditable) with the
          Message 4 of 14 , Feb 1, 2012
          • 0 Attachment

            It would make more sense to add a technical practice like that to the team’s definition of done.

             

            I’d rewrite it to be more normalized (auditable) with the other definitions.

             

            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of RonJeffries
            Sent: Wednesday, February 01, 2012 7:08 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: Re: [scrumdevelopment] Non-story PBIs

             

             

            Those are not PBIs as I understand the idea.

            R

            On Feb 1, 2012, at 7:50 AM, Bret Wortman wrote:



            "As a developer, I want a clean separation beteween generated code and hand-written code so I don't have to manually merge code each time I have to...." and so on. The ideas being put forward have definite merit, but they're not stories (they fail the V in INVEST, for starters) but I'm not sure how to best capture them.  Should they reside in the backlog as non-stories, should they be captured during the retrospective as best practices to be put into practice during the next sprint? How would you handle this?

             


            Ron Jeffries

            I know we always like to say it'll be easier to do it now than it

            will be to do it later. Not likely. I plan to be smarter later than

            I am now, so I think it'll be just as easy later, maybe even easier.

            Why pay now when we can pay later?

             

          • Michael James
            One way to handle it: If this is a cross-cutting need, the team may write this down as part of their definition of done affecting all other PBIs. --mj
            Message 5 of 14 , Feb 1, 2012
            • 0 Attachment
              One way to handle it: If this is a cross-cutting need, the team may write this down as part of their definition of done affecting all other PBIs.
              --mj

              On Feb 1, 2012, at 9:08 AM, RonJeffries wrote:

               

              Those are not PBIs as I understand the idea.

              R
              On Feb 1, 2012, at 7:50 AM, Bret Wortman wrote:

              "As a developer, I want a clean separation beteween generated code and hand-written code so I don't have to manually merge code each time I have to...." and so on. The ideas being put forward have definite merit, but they're not stories (they fail the V in INVEST, for starters) but I'm not sure how to best capture them.  Should they reside in the backlog as non-stories, should they be captured during the retrospective as best practices to be put into practice during the next sprint? How would you handle this?


              Ron Jeffries
              I know we always like to say it'll be easier to do it now than it
              will be to do it later. Not likely. I plan to be smarter later than
              I am now, so I think it'll be just as easy later, maybe even easier.
              Why pay now when we can pay later?



            • Steve
              I agree with Michael but some organisations (Agile immature) still like to have this sort of stuff in the requirements . They are effectively non-functional
              Message 6 of 14 , Feb 1, 2012
              • 0 Attachment
                I agree with Michael but some organisations (Agile immature) still like to have this sort of stuff in 'the requirements'. They are effectively 'non-functional requirements' just as User Stories are effectively 'functional requirements'.

                Of course your example could form part of the 'coding standards' or 'project constraints' - there are many ways of 'skinning this cat', the trick is to find the right way for your organisation but they should not be in the PB (IMHO)

                --- In scrumdevelopment@yahoogroups.com, Michael James <mj4scrum@...> wrote:
                >
                > One way to handle it: If this is a cross-cutting need, the team may write this down as part of their definition of done affecting all other PBIs.
                > --mj
                >
                > On Feb 1, 2012, at 9:08 AM, RonJeffries wrote:
                >
                > > Those are not PBIs as I understand the idea.
                > >
                > > R
                > > On Feb 1, 2012, at 7:50 AM, Bret Wortman wrote:
                > >
                > >> "As a developer, I want a clean separation beteween generated code and hand-written code so I don't have to manually merge code each time I have to...." and so on. The ideas being put forward have definite merit, but they're not stories (they fail the V in INVEST, for starters) but I'm not sure how to best capture them. Should they reside in the backlog as non-stories, should they be captured during the retrospective as best practices to be put into practice during the next sprint? How would you handle this?
                > >
                > >
                > > Ron Jeffries
                > > www.XProgramming.com
                > > I know we always like to say it'll be easier to do it now than it
                > > will be to do it later. Not likely. I plan to be smarter later than
                > > I am now, so I think it'll be just as easy later, maybe even easier.
                > > Why pay now when we can pay later?
                > >
                > >
                > >
                >
              • Steve Ropa
                My inclination would be to leave it as a team agreement. Just part of how we do business. Not everything needs to be documented. One question would be,
                Message 7 of 14 , Feb 1, 2012
                • 0 Attachment

                  My inclination would be to leave it as a team agreement.  Just part of how we do business.  Not everything needs to be documented.  One question would be, especially with something as obvious as the example you give, how would documenting it change the behavior of the team, if at all?

                   

                  On the other hand, this does feel like it would fit in the XP practice of Code Standard.

                   

                  From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Bret Wortman
                  Sent: Wednesday, February 01, 2012 7:14 AM
                  To: scrumdevelopment@yahoogroups.com
                  Subject: Re: [scrumdevelopment] Non-story PBIs

                   

                   

                  Good. They're not as I understand it either. I'm just really struggling with how the team ought to capture the fact that there's work to be done to make these wants, shared by the team as a whole, come to fruition. Or is this something that, if it truly is desired by the whole team, will just start to happen as a result of everyone's focus being brought to the issue? Does it even need to be captured anywhere at all?

                   

                  Is the conversation enough?


                  Bret Wortman


                  On Wed, Feb 1, 2012 at 9:08 AM, RonJeffries <ronjeffries@...> wrote:

                   

                  Those are not PBIs as I understand the idea.

                  R

                   

                  On Feb 1, 2012, at 7:50 AM, Bret Wortman wrote:



                  "As a developer, I want a clean separation beteween generated code and hand-written code so I don't have to manually merge code each time I have to...." and so on. The ideas being put forward have definite merit, but they're not stories (they fail the V in INVEST, for starters) but I'm not sure how to best capture them.  Should they reside in the backlog as non-stories, should they be captured during the retrospective as best practices to be put into practice during the next sprint? How would you handle this?

                   


                  Ron Jeffries

                  I know we always like to say it'll be easier to do it now than it

                  will be to do it later. Not likely. I plan to be smarter later than

                  I am now, so I think it'll be just as easy later, maybe even easier.

                  Why pay now when we can pay later?

                   

                   

                • mj4scrum@gmail.com
                  I ve seen value in having the team write their agreements with each other, even if that document will not be retained. I m thinking of a markerboard or
                  Message 8 of 14 , Feb 1, 2012
                  • 0 Attachment
                    I've seen value in having the team write their agreements with each other, even if that document will not be retained. I'm thinking of a markerboard or flipchart sheet. The problem with communication is the illusion it has occurred. 

                    --mj

                    Sent from a phone that often corrects words I tapped to words I may not have meant. 

                    On Feb 1, 2012, at 3:14 PM, "Steve Ropa" <theropas@...> wrote:

                     

                    My inclination would be to leave it as a team agreement.  Just part of how we do business.  Not everything needs to be documented.  One question would be, especially with something as obvious as the example you give, how would documenting it change the behavior of the team, if at all?

                     

                    On the other hand, this does feel like it would fit in the XP practice of Code Standard.

                     

                    From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Bret Wortman
                    Sent: Wednesday, February 01, 2012 7:14 AM
                    To: scrumdevelopment@yahoogroups.com
                    Subject: Re: [scrumdevelopment] Non-story PBIs

                     

                     

                    Good. They're not as I understand it either. I'm just really struggling with how the team ought to capture the fact that there's work to be done to make these wants, shared by the team as a whole, come to fruition. Or is this something that, if it truly is desired by the whole team, will just start to happen as a result of everyone's focus being brought to the issue? Does it even need to be captured anywhere at all?

                     

                    Is the conversation enough?


                    Bret Wortman


                    On Wed, Feb 1, 2012 at 9:08 AM, RonJeffries <ronjeffries@...> wrote:

                     

                    Those are not PBIs as I understand the idea.

                    R

                     

                    On Feb 1, 2012, at 7:50 AM, Bret Wortman wrote:



                    "As a developer, I want a clean separation beteween generated code and hand-written code so I don't have to manually merge code each time I have to...." and so on. The ideas being put forward have definite merit, but they're not stories (they fail the V in INVEST, for starters) but I'm not sure how to best capture them.  Should they reside in the backlog as non-stories, should they be captured during the retrospective as best practices to be put into practice during the next sprint? How would you handle this?

                     


                    Ron Jeffries

                    I know we always like to say it'll be easier to do it now than it

                    will be to do it later. Not likely. I plan to be smarter later than

                    I am now, so I think it'll be just as easy later, maybe even easier.

                    Why pay now when we can pay later?

                     

                     

                  • Wouter Lagerweij
                    This indeed doesn t belong on a product backlog. You might include the (catching-up) work in a sprint backlog, though. These are the kind of issues that I d
                    Message 9 of 14 , Feb 1, 2012
                    • 0 Attachment
                      This indeed doesn't belong on a product backlog.
                      You might include the (catching-up) work in a sprint backlog, though.

                      These are the kind of issues that I'd expect to come out of a retrospective: 'We're losing time merging'. Why? 'Cause there's a lot of generated code in our repository that gets changed every time.' Why? 'Because the generated code is in the same folder structure as the hand-written code.' Why? 'Because we don't use accepted standards (maven?) in our project structure.' Why? 'Because it wasn't set-up like that, and it takes time to fix it'.

                      So you have an impediment, a technical one, with a clear way to fix it. If the team thinks it's important enough, then take fixing that into your next sprint (and consequently take less from the product backlog into that sprint). 

                      This doesn't count towards your velocity (no value added), though in the long term it will perhaps increase it.

                      Wouter

                      On Wed, Feb 1, 2012 at 3:14 PM, Bret Wortman <bret@...> wrote:
                       

                      Good. They're not as I understand it either. I'm just really struggling with how the team ought to capture the fact that there's work to be done to make these wants, shared by the team as a whole, come to fruition. Or is this something that, if it truly is desired by the whole team, will just start to happen as a result of everyone's focus being brought to the issue? Does it even need to be captured anywhere at all?


                      Is the conversation enough?


                      Bret Wortman




                      On Wed, Feb 1, 2012 at 9:08 AM, RonJeffries <ronjeffries@...> wrote:
                       

                      Those are not PBIs as I understand the idea.

                      R

                      On Feb 1, 2012, at 7:50 AM, Bret Wortman wrote:

                      "As a developer, I want a clean separation beteween generated code and hand-written code so I don't have to manually merge code each time I have to...." and so on. The ideas being put forward have definite merit, but they're not stories (they fail the V in INVEST, for starters) but I'm not sure how to best capture them.  Should they reside in the backlog as non-stories, should they be captured during the retrospective as best practices to be put into practice during the next sprint? How would you handle this?


                      Ron Jeffries
                      I know we always like to say it'll be easier to do it now than it
                      will be to do it later. Not likely. I plan to be smarter later than
                      I am now, so I think it'll be just as easy later, maybe even easier.
                      Why pay now when we can pay later?





                      --
                      Wouter Lagerweij         | wouter@...
                    • JackM
                      Try to make this just part of the done criteria for a story. Jack www.agilebuddy.com
                      Message 10 of 14 , Feb 1, 2012
                      • 0 Attachment
                        Try to make this just part of the done criteria for a story.

                        Jack
                        www.agilebuddy.com

                        --- In scrumdevelopment@yahoogroups.com, Bret Wortman <bret@...> wrote:
                        >
                        > How do you all deal with non-story PBIs. I have some new-to-scrum and
                        > new-to-Agile developers who have recently written stories like this:
                        >
                        > "As a developer, I want a clean separation beteween generated code and
                        > hand-written code so I don't have to manually merge code each time I have
                        > to...." and so on. The ideas being put forward have definite merit, but
                        > they're not stories (they fail the V in INVEST, for starters) but I'm not
                        > sure how to best capture them. Should they reside in the backlog as
                        > non-stories, should they be captured during the retrospective as best
                        > practices to be put into practice during the next sprint? How would you
                        > handle this?
                        >
                        >
                        > *Bret Wortman***
                        >
                      • Abhilash c
                        I agree with wouter Such stories/activities are type of technical debts. These can be part of the definition of done for each PBI s. We add such non-function
                        Message 11 of 14 , Feb 2, 2012
                        • 0 Attachment
                          I agree with wouter
                           
                          Such stories/activities are type of technical debts. These can be part of the definition of done for each PBI's. We add such non-function requirements as constraints to each PBI.
                           
                          These technical debts can be identified during retrospectives or during the first few sprints. Some of these stories can be done easily but sometimes these tasks require considerable effort. In such cases we create a separate private PBI with zero story points.

                           
                          Regards
                          Abhilash
                          On 2 February 2012 04:51, Wouter Lagerweij <wouter@...> wrote:
                           

                          This indeed doesn't belong on a product backlog.

                          You might include the (catching-up) work in a sprint backlog, though.

                          These are the kind of issues that I'd expect to come out of a retrospective: 'We're losing time merging'. Why? 'Cause there's a lot of generated code in our repository that gets changed every time.' Why? 'Because the generated code is in the same folder structure as the hand-written code.' Why? 'Because we don't use accepted standards (maven?) in our project structure.' Why? 'Because it wasn't set-up like that, and it takes time to fix it'.

                          So you have an impediment, a technical one, with a clear way to fix it. If the team thinks it's important enough, then take fixing that into your next sprint (and consequently take less from the product backlog into that sprint). 

                          This doesn't count towards your velocity (no value added), though in the long term it will perhaps increase it.

                          Wouter


                          On Wed, Feb 1, 2012 at 3:14 PM, Bret Wortman <bret@...> wrote:
                           

                          Good. They're not as I understand it either. I'm just really struggling with how the team ought to capture the fact that there's work to be done to make these wants, shared by the team as a whole, come to fruition. Or is this something that, if it truly is desired by the whole team, will just start to happen as a result of everyone's focus being brought to the issue? Does it even need to be captured anywhere at all?


                          Is the conversation enough?


                          Bret Wortman




                          On Wed, Feb 1, 2012 at 9:08 AM, RonJeffries <ronjeffries@...> wrote:
                           

                          Those are not PBIs as I understand the idea.

                          R

                          On Feb 1, 2012, at 7:50 AM, Bret Wortman wrote:

                          "As a developer, I want a clean separation beteween generated code and hand-written code so I don't have to manually merge code each time I have to...." and so on. The ideas being put forward have definite merit, but they're not stories (they fail the V in INVEST, for starters) but I'm not sure how to best capture them.  Should they reside in the backlog as non-stories, should they be captured during the retrospective as best practices to be put into practice during the next sprint? How would you handle this?


                          Ron Jeffries
                          I know we always like to say it'll be easier to do it now than it
                          will be to do it later. Not likely. I plan to be smarter later than
                          I am now, so I think it'll be just as easy later, maybe even easier.
                          Why pay now when we can pay later?





                          --
                          Wouter Lagerweij         | wouter@...


                        • Tim Lesher
                          ... I like this approach, but one of the ways we run into trouble here is that measured velocity is perceived as effort--so there s a strong pressure to make
                          Message 12 of 14 , Feb 2, 2012
                          • 0 Attachment
                            On Wed, Feb 1, 2012 at 18:21, Wouter Lagerweij <wouter@...> wrote:
                             

                            This indeed doesn't belong on a product backlog.

                            [...]
                             
                            So you have an impediment, a technical one, with a clear way to fix it. If the team thinks it's important enough, then take fixing that into your next sprint (and consequently take less from the product backlog into that sprint). 

                            This doesn't count towards your velocity (no value added), though in the long term it will perhaps increase it.


                            I like this approach, but one of the ways we run into trouble here is that measured velocity is perceived as effort--so there's a strong pressure to make sure that any activities done in furthering the project "get captured" as points (those are exactly the words used).

                            We've even had release planning meetings assigned "points", just so that people outside the team looking at project numbers see that we're "making progress".

                            Has anyone been in this situation and recovered from it? If so, how?

                            Thanks!
                             
                            --
                            Tim Lesher <tlesher@...>
                          • Alan Dayley
                            When you start delivering working product every sprint the desire to show and see other measures of progress drops significantly. Alan
                            Message 13 of 14 , Feb 3, 2012
                            • 0 Attachment
                              When you start delivering working product every sprint the desire to show and see other "measures of progress" drops significantly.

                              Alan

                              On Feb 2, 2012, at 7:30 AM, Tim Lesher <tlesher@...> wrote:

                               



                              On Wed, Feb 1, 2012 at 18:21, Wouter Lagerweij <wouter@...> wrote:
                               

                              This indeed doesn't belong on a product backlog.

                              [...]
                               
                              So you have an impediment, a technical one, with a clear way to fix it. If the team thinks it's important enough, then take fixing that into your next sprint (and consequently take less from the product backlog into that sprint). 

                              This doesn't count towards your velocity (no value added), though in the long term it will perhaps increase it.


                              I like this approach, but one of the ways we run into trouble here is that measured velocity is perceived as effort--so there's a strong pressure to make sure that any activities done in furthering the project "get captured" as points (those are exactly the words used).

                              We've even had release planning meetings assigned "points", just so that people outside the team looking at project numbers see that we're "making progress".

                              Has anyone been in this situation and recovered from it? If so, how?

                              Thanks!
                               
                              --
                              Tim Lesher <tlesher@...>

                            • Wouter Lagerweij
                              ... Hi Tim, Yes, I ve also seen that happen. This is a thorough misuse of the concept of velocity. I ve only been able to change that by being very clear on
                              Message 14 of 14 , Feb 3, 2012
                              • 0 Attachment
                                On Thu, Feb 2, 2012 at 3:30 PM, Tim Lesher <tlesher@...> wrote:
                                On Wed, Feb 1, 2012 at 18:21, Wouter Lagerweij <wouter@...> wrote:
                                 This indeed doesn't belong on a product backlog.
                                [...]
                                So you have an impediment, a technical one, with a clear way to fix it. If the team thinks it's important enough, then take fixing that into your next sprint (and consequently take less from the product backlog into that sprint). 

                                This doesn't count towards your velocity (no value added), though in the long term it will perhaps increase it.
                                I like this approach, but one of the ways we run into trouble here is that measured velocity is perceived as effort--so there's a strong pressure to make sure that any activities done in furthering the project "get captured" as points (those are exactly the words used).

                                We've even had release planning meetings assigned "points", just so that people outside the team looking at project numbers see that we're "making progress".

                                Has anyone been in this situation and recovered from it? If so, how?

                                Hi Tim, 

                                Yes, I've also seen that happen. This is a thorough misuse of the concept of velocity.
                                I've only been able to change that by being very clear on what velocity is, an what it's use for planning is.

                                Velocity is meant to give some indication of the delivery of value. Towards delivery of new functionality for the project.
                                You use historical velocity to create a release planning. This only works if what velocity is measuring is delivery of the thing you're planning to deliver! It's about how effective you are as a team in delivering value.

                                Effort doesn't have to be measured. Effort is easy! Everyone is working 40 hours a week, so you can easily calculate how many hours of effort are being put into the project. It's all about what you do with that time. All the stuff you do that is not delivering value is overhead. If you sit in meetings for days on end, you don't 'get points' for that. If your quality is lousy and you have to spend time fixing bugs, you don't 'get points' for that. If you have to fix your project set-up because it's slowing you down because your merges take longer, you don't get points for that. 

                                The reason is simple: you're now doing things sub-optimally, meaning that your progress is slower than it could be. When you fix such impediments, what is supposed to happen is that your velocity goes up. But if you're counting all kinds of other things as part of that velocity, this increase in velocity will not be visible. You won't be able to update your release plan, because your velocity is not related to the project at al. It's simply directly coupled to time.

                                This  can be hard to accept for some teams, especially if they don't feel valued by the rest of the organisation, and are being put under a lot of pressure to appear busy. I've made this more acceptable in some teams by counting two figures: effort, which includes things like bug-fixes and 'technical debt' PBIs, and velocity, which doesn't. Meetings never come in to those figures, btw. Then we at least have useful figures for planning, and they don't feel that their efforts are undervalues. But really, this is an indication that there is a fairly serious trust issue between the team and its management.

                                Not trying to lecture you, just giving some ammunition for the discussions that you're bound to have on this:-)

                                Wouter

                                PS Some of this, and a few other potential velocity problems, I put in a blog post a while back: http://www.lagerweij.com/2011/07/08/5-ways-to-make-sure-velocity-is-useless/
                                 
                                --
                                Wouter Lagerweij         | wouter@...
                              Your message has been successfully submitted and would be delivered to recipients shortly.