Creating small user stories has been seen as desirable for reasons such as easier estimation, scope control, and early value delivery. This idea sometimes encounters friction from product developers (e.g., engineers) who see smaller user stories incurring higher overhead costs such as increased time spent creating documentation, test cases etc. After all, why would you need to split a user story about a contact-us form into three stories about viewing the form, validating it, and then sending the data to an external party? It seems logical to just group it all together. Does creating smaller and smaller stories become detrimental to productivity?
A Theory of User Story Sizing
A Theory of User Story Sizing
A Theory of User Story Sizing
Creating small user stories has been seen as desirable for reasons such as easier estimation, scope control, and early value delivery. This idea sometimes encounters friction from product developers (e.g., engineers) who see smaller user stories incurring higher overhead costs such as increased time spent creating documentation, test cases etc. After all, why would you need to split a user story about a contact-us form into three stories about viewing the form, validating it, and then sending the data to an external party? It seems logical to just group it all together. Does creating smaller and smaller stories become detrimental to productivity?