57173Re: [scrumdevelopment] Spike stories - estimation and acceptance criteria ?
- Aug 29, 2013Hi 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.
- << Previous post in topic Next post in topic >>