Should we always follow the story approach? What if the nature of the beast is that there is a continuously evolving application where one cannot define even a functional test with data? If you define a story, no sooner than its 'complete', it will need to be changed, since new information comes along that makes your acceptance criteria obsolete.
Since I am currently experiencing such an approach in a particular area of the project I work in, we are veering round to the view that we need not track velocity or story completion of such work. For purposes of documentation, we will still have stories which detail what work needs to be done at a point of time, but we are not going to bother with tracking the acceptance criteria after that and the points delivered once this work is complete.
Comments?
Saturday, December 6, 2008
Subscribe to:
Post Comments (Atom)
5 comments:
If the business situation is changing so rapidly that you can't even have stable acceptance criteria, how do you know that the application has value?
The business situation isnt changing. Its the design of the piece that is evolving since it a heuristic based approach to problem.
Interesting !!
Have you tried using a different definition to such stories. This seems similar to spikes..but these are business solution oriented spikes.
That being said there is no reason I can see that such spikes do not need an acceptance criteria (AT). The AT would probably be more geared towards clarifying the 'decision' one expects to take based on the outcome of the spike
Started reading this blog only today.. Have a question. How are these changes handled? Is it tracked in a new story then? Even in the project I am working on, Acceptance criteria keep changing even after the Story is completed. We create another story with this changed AC and map it to the old one for reference.
Post a Comment