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

Re: Non-story PBIs

Expand Messages
  • JackM
    Try to make this just part of the done criteria for a story. Jack www.agilebuddy.com
    Message 1 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 2 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 3 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 4 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 5 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.