57175Re: [scrumdevelopment] Re: Spike stories - estimation and acceptance criteria ?
- Aug 28, 2013Hi all,We use spikes for risk reduction - most of the time to determine if something is technically feasible.Reducing project risks early is valuable to the business.TimOn 29 August 2013 08:12, srinivas chillara <ceezone@...> wrote:Hallo Fredrik,I think you are on the topic....otherwise I agree with you. spikes can have business value, but often difficult to know ahead of time.Basically spikes help us make reasonably informed decisions later on.cheersSrinivas
From: frede_swe <fredrik.vestin@...>
Sent: Thursday, 29 August 2013 1:06 AM
Subject: [scrumdevelopment] Re: Spike stories - estimation and acceptance criteria ?
Sorry for being a bit off-topic here but I think this is an interesting discussion.
The Scrum guide does not say exactly how a PBI should be expressed or that all PBIs must be expressed in the same way. There seem to be some disagreement in the scrum community whether all PBIs must have direct business value or not. Some say yes, some say no.
The PO is responsible for ROI and to make any intelligent decision about how to prioritize the backlog the PO must understand the items and they must also make sense to stakeholders, which suggests that the product backlog should only contain user stories. 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.
--- In email@example.com, Ron Jeffries <ronjeffries@...> wrote:
> On Aug 28, 2013, at 2:07 AM, srinivas chillara <ceezone@...> wrote:
> > POs can (and should) understand items that are not written as user stories as well.
> People can and should understand many things. However, Product Backlog items all need to bear business value that is understandable enough so that the Product Owner (and any observer) can compare them to decide which to do first.
> I don't care what format they are written in. The "As a" format, for example, is training wheels and probably an obstacle to progress after the first few weeks.
> Scrum backlog items, in order to be ordered properly, need to be comparable in the mind of the Product Owner. If they are comparable it doesn't matter how they are written, they are OK. If they are not comparable, it doesn't matter how they are written: they are trouble.
> Ron Jeffries
> Sometimes I give myself admirable advice, but I am incapable of taking it.
> -- Mary Wortley Montagu
Tim021 251 5593
- << Previous post in topic Next post in topic >>