Dealing with spillovers

Often times a feature or a user story is larger than anticipated and it does not get completed within a single sprint. This page describes how to deal with this situation.

1. Create a SPIKE or an investigation ticket before starting the actual development
   
   If there is a lot uncertainty when the ticket is groomed/scored, e.g. there's no consensus on what the score should be OR if the score is higher than 5 story points, consider creating a SPIKE or a task to further investigate the problem since this is a likely indication that the feature is not clear or understood.
   
   
2. Split the ticket into the investigation and development parts
   
   If a ticket has been started but not completed at the end of the sprint and no code has been produced so far, split the ticket into a investigation part (which is to be closed in the current sprint if the investigation has been completed) and the development part which is to be undertaken in the next sprint.
   If the only "code" produced included changes to the schema or RAML, the split ticket should cover the "design" part.

      3. Split the ticket into refactoring and the actual feature development and/or split the feature into smaller parts
If by the end of the sprint, the ticket has been started and "some" code has been written discuss with the team if the feature should be split into more tickets:

1. 1. If the code written so far does not directly relate to the feature but addresses general changes to the codebase required by the feature, e.g refactoring of existing code, providing better test coverage, cleaning or reformatting existing code, etc create a seperate ticket for these changes, score it, and add to the existing sprint replacing the original ticket. If the refactoring work is complete, close the ticket. If the work is to continue, split the ticket further into two parts. Each of the parts should get part of the score.
   2. if the code written so far does already cover some part of the new feature discuss if the feature can be meaningfully broken up into sub-features, create and close tickets accordingly. If there's no obvious way to split the feature into smaller units, simply break up the ticket into "part 1" and "part 2" and assign appropriate scores to each part discussing with the team. IMPORTANT: when breaking the feature up into "part 1" and "part 2", clone the ticket the rename the clone (not the original ticket) to "part 1" and close it. This is to ensure that Jira ID for the feature that is still in progress is not marked as DONE as this would be confusing for people tracking the ticket.