Agile - Dealing with changing requirements for already implemented features

views:

232

answers:

+3 Q:

Agile - Dealing with changing requirements for already implemented features

In a recent meeting with my client, we discovered we missed out on a Detail of User Story, that has already been implemented several iterations before.

The new requirement is not only an additional Feature but changed behaviour.

The original User Story goes like: "Can View XYZ"

The new request however goes like: "Can View XYZ but if B then XYZ must look like ABC"

Shall i consider this a Bug or a New User Story, or should i simply reopen the old user Story and edit it to account for the new request? What is the "best-practice", what are pros and cons of each approach?

+8 A:

Developer Art 2009-09-11 09:45:44

http://www.flickr.com/photos/dratz/1045336659/ :)

Thiyagaraj 2009-09-11 09:48:44

ok, but should i make it a new User Story?

Johannes Rudolph 2009-09-11 10:05:18

thanks, excellent explanation! That way i could also track if I forget features (->lack of description on my side) or if my Customers like to forget to tell me what they want :-) I will mark correct answer in next 24h

Johannes Rudolph 2009-09-11 10:15:16

The question is: Does tracking have or provide value? If not, it's waste.

Pascal Thivent 2009-09-11 10:21:28

yup, it does, i learn how to deal with them, when to ask the right questions etc :-)

Johannes Rudolph 2009-09-11 15:02:09

I would edit the old story to document the modification. Otherwise you may have contradictions between the new story and the old one.

This can hardly be considered as a defect (or bug) if the customer changed its mind.

Be pragmatic: estimate it, schedule it and implement it.

philippe 2009-09-11 10:04:09

well, they didnt change their mind, they simply forgot to tell me (see above, ive edited the question to make that clear)

Johannes Rudolph 2009-09-11 10:08:53

OK, thanks for the clarification. But I insist on documenting it, especially since you seem to maintain the stories electronically (reopen and edit). Otherwise you can have contradictions between your stories.

philippe 2009-09-11 11:49:37

Who cares if an open story has contradictions with a finished/closed one? Documenting the contradiction is pure "Cover Your Ass", it's adding more waste to some previous waste. It doesn't sound really lean/agile to me.

Pascal Thivent 2009-09-11 12:18:54

In a pure agile environment, that's right. But we do not know the context here - it seems the stories are not kept on index cards but in an electronic document. If this document is used in any way, it might be better to update the initial story.

philippe 2009-10-02 11:34:35

+3 A:

A Bug, a new User Story, reopening the old Story... is that really important? In any case, your customer is asking for a feature that is currently not implemented. So, as long as you can estimate its size and as long as he can prioritize it, it doesn't really matter how you call the way you capture the needs.

So, unless you have to deal with specific contractual constraints, just pick one solution, estimate the size and let the customer prioritize it (personally, I'd create a new user story).

Pascal Thivent 2009-09-11 10:08:44

it's about the "best-practice" the pro and cons of each approach (added that to the question), thanks for your thoughts

Johannes Rudolph 2009-09-11 10:10:35

The best practice is to satisfy the customer, to welcome change, to deliver working software, etc. http://agilemanifesto.org/principles.html :)

Pascal Thivent 2009-09-11 10:16:56

I would say this should count as the old story. Your team should report reduced throughput (velocity) because of these changing requirements, especially if the original feature has not already shipped.

Chris Simmons 2009-09-11 14:02:31

ansaurus

tags:

views:

answers:

Agile - Dealing with changing requirements for already implemented features

related questions