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

57173Re: [scrumdevelopment] Spike stories - estimation and acceptance criteria ?

Expand Messages
  • Ron Jeffries
    Aug 29, 2013
    • 0 Attachment
      Hi Fredrik,

      On Aug 28, 2013, at 3:36 PM, frede_swe <fredrik.vestin@...> wrote:

      However, the backlog should contain ALL the requirements for the product which I think assumes that work that do not have obvious business value should also be on the backlog, e.g. spikes, rewriting/refactoring etc. Some suggest that "technical tasks" should be included as tasks in user stories but I think that shoehorning this kind of work into stories reduce transparency. 

      There should be transparency of course.

      There should be no work done, none, not any, that does not have business value. The Product Owner is the only role that can put work into the Sprint Backlog. Since no one else can choose an item, the PO needs to understand the item. 

      Technical tasks are historically part of Scrum but many have found them to be weak in several regards. First, they tend to reduce transparency, as you mention above. Second, they tend to lock the team into a specific solution, at the time in the Sprint when they know the least. Third, they tend to support specialist development, and to work against people becoming more capable. Fourth, they tend to result in work queues, and queues are always bad. Fifth, they tend to result in one kind of work holding back many stories.

      Despite all this, technical tasks are a valid way to work. It's just that they're not often the best way.

      Ron Jeffries
      Sometimes I give myself admirable advice, but I am incapable of taking it.
      -- Mary Wortley Montagu

    • Show all 17 messages in this topic