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

Technical Tasks in the Product Backlog

Expand Messages
  • PAUL
    Hi All, I m a Generic Agile Coach with an XP slant. I often come across Agile teams who place tecnical tasks in their backlog. Many of these teams call these
    Message 1 of 89 , Jun 23, 2011
    • 0 Attachment
      Hi All,

      I'm a "Generic Agile" Coach with an XP slant. I often come across Agile teams who place tecnical tasks in their backlog. Many of these teams call these technical tasks "User Stories". These tasks cover a whole range of stuff, such as re-factoring, technical investigations, non-functional requirements, release preperation, bug fixes, etc.

      Now I haven't got my Schwaber and Beedle book to hand, but I remember Scrum being pretty loose about what qualifies as something that can go on the backlog, hence why I'm asking this question here.

      Should anything other then pure user stories appear on a Scrum backlog, and should these tasks be prioritised along side user stories by the product owner?

      Where I've seen this approach applied, invariably the product owner prioritises new features over technical tasks, leading to an inadvertant build up of technical debt.

      As anyone else seen this, and does anyone have a solution?

      XP, the way I was taught, solves this problem by keeping technical tasks within the remit of the team. The team gets to decide what technical tasks should be performed each sprint, leaving their remaining velocity to be assigned to user stories prioritised by the customer.

      This makes more sense to me, since it addresses the approriate balance of responsibilities between developers and customers. Developers should have technical responsibility, whilst the customer has feature responsibility.

      I don't think Scrum sees it this way. Is this just an historcal accident (XP came after Scrum and hence had the benefit of hindsight), or is there a good reason for the Scrum stance?

      Many thanks in advance,

      Paul.
    • Ron Jeffries
      Hello, Kathleen. On Friday, July 1, 2011, at 9:47:13 AM, you ... Yes, I do agree. And at the same time one does need to start /somewhere/, inside the safe
      Message 89 of 89 , Jul 2, 2011
      • 0 Attachment
        Hello, Kathleen. On Friday, July 1, 2011, at 9:47:13 AM, you
        wrote:

        > In some posts, there seems to be a focus on doing things 'by the
        > book', rather than exploring the possibilities of other concepts
        > or techniques that might be useful. It implies that the method is
        > the 'one true way' of doing things, and that you don't need to
        > learn anything else to be successful. Unfortunately, reality is
        > way too messy for that to be true.

        > To get really good at something, you need to go beyond mastery of
        > a given method (or words of a specific master). You need to learn
        > the underlying theory and principles (like what was mentioned
        > before), then integrate the ideas and processes in new ways to
        > deal with your current situation.

        Yes, I do agree. And at the same time one does need to start
        /somewhere/, inside the "safe region" for learning before you die.
        Scrum purports to define part of the safe region.

        > Creating new concepts should be encouraged. We should all be
        > challenging the status quo and pushing for better ways to do
        > things. Isn't that how agile got started? Why stop now?

        Agile got started based on the combined experience of a large number
        of people who had observed a large number of teams for a large
        number of years. It is possible that those people knew rather a lot.
        It is also possible that teams starting out to do this stuff are not
        yet qualified to make decisions about what to do and what not to do.

        Ron Jeffries
        www.XProgramming.com
        Show me the features!
      Your message has been successfully submitted and would be delivered to recipients shortly.