Dealing with spillovers

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: