Conflicting requirements between delivered user story and build ready user story

Last post 10:20 am January 21, 2022
by Balaji Dhamodaran
4 replies
Author
Messages
01:28 pm January 19, 2022

Sprint 1 Usecase 1:

Perform an action based on the user contact details. And there are 3 different acceptance criteria for that story. It is already completed and demonstrated to PO and SME.

Sprint 2 Usecase 2:

 

Same feature and same screen same button but on click perform an action that conflicts Usecase 1 story and acceptance criteria.

 

What should be done to make it clear to dev team and test team that Usecase 2 is valid and delivered user story is invalid.

 

Should BA updated delivered user story cards or in new user story card s/he should update all those cases that invalidates or descopes the feature delivered.

 

Please advice.

 

11:09 pm January 19, 2022

What should be done to make it clear to dev team and test team that Usecase 2 is valid and delivered user story is invalid.

I wouldn't say that the delivered user story was invalid if it satisfied the criteria stated. In fact, delivery of that story led to the realization that the criteria needed to change and thus Usecase 2 came to be.  That is the whole point of incremental delivery and shows the value of feedback received because of doing work.  It is empiricism in action. 

Should BA updated delivered user story cards or in new user story card s/he should update all those cases that invalidates or descopes the feature delivered.

It is the responsibility of the Product Owner to maintain a backlog of information about the changes, additions, deletions for the Product to keep it valuable. This is the opening statement of the Scrum Guide's section that explains the Product Backlog.

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

As the first idea was delivered as requested that work is complete.  Any changes to the current product should be documented in the backlog in a way that the Development team can understand the changes needed and the value the changes will deliver. 

I have intentionally avoided bringing up your Definition of Done, your reference to a dev team and test team, or your expectation of a BA because this would become a much longer post.  I am going to suggest that you revisit the Scrum Guide (https://scrumguides.org/) to refresh your understanding of the Scrum framework.  

11:44 pm January 19, 2022

What should be done to make it clear to dev team and test team that Usecase 2 is valid and delivered user story is invalid.

If you've got separate dev and test teams it's unlikely it ever will be clear. Neither will be accountable for the application of validated learning.

11:57 pm January 19, 2022

It depends on what is meant by "invalid".

If Use Case 1 didn't represent what the stakeholders had in mind, I would want to understand how there was a disconnect between the Scrum Team and the stakeholders.

If Use Case 1 represented what the stakeholders were thinking originally, but the delivery of that change led to feedback from stakeholders that led to creating Use Case 2, that's the point of iterative and incremental development methodologies. It's better to learn this quickly - after a short iteration - rather than the end of a very long design, development, test, and deployment process.

Personally, I like to look at Product Backlog Items as changes or deltas. If 2 requires that something done in 1 be undone or modified, then the description would somehow reflect this. I don't think that it's generally necessary to go back in time and update PBIs that reflect delivered work. However, I can think of some cases where that could be desired and useful - like most things, it depends on the particular context in which you are working.

10:20 am January 21, 2022

what ever implemented in sprint 1 could have been the understanding of the PO, stakeholders users at that point of time. it is good that the same feature has already got feedback from users/stakeholders to modify or enhance. it should not be seen as conflict.

So the change can be handled as a new product backlog item not to reopen the old cards. Modifications will be always there to maximise its value. it doesn't mean what was done in previous iterations were waste of time.

What should be done to make it clear to dev team and test team that Usecase 2 is valid and delivered user story is invalid.

the need of sprinting is to build better products through empiricism.  This basics need to be made clear to the team.

You will keep correcting your art until it comes beautiful. isn't it ?