A story that has been picked up by a development team is too big. Is it 'okay' to break it down even though work has already commenced?

  • 3
    Why did the development team start work on a story that is too big, before trying to split it into more manageable pieces? Jun 30, 2016 at 9:15

3 Answers 3


Yes, this is "Okay." ;-)

The Scrum Guide (scrumguides.org) actually encourages responding this way to emergence:

The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal. - scrum guide / sprint backlog

Additional points from the Scrum Guide

  • The Sprint Goal is what guides the Dev TeamThe Sprint Backlog BELONGS to the Development Team
  • No one tells the Development Team HOW to turn the product backlog into Increments of potentially releasable functionality
  • If work has commenced then the item is in the sprint backlog not the product backlog
    – Ewan
    Jul 3, 2016 at 10:15

Why not? It's even better to do this as it makes you more flexible during development, by minimizing work in progress or in case velocity dropdown or changes in the sprint backlog. Check 10 strategies to split large user stories and New Story Splitting Resource.

  • 1
    Or to phrase it differently, it minimizes 'work in progress', which is always desirable.
    – Nathan
    Jun 30, 2016 at 0:23
  • @NathanCooper Edited comment respectively. Jun 30, 2016 at 7:08

No, don't change stuff once work has started.

Even if you can split it without changing the requirements it will change the way it is implemented because you will be effectively adding interface requirements between the sub tasks.


Paint the fence red! Dev proceeds to buy paint sprayer

Paint this fence plank red. Dont change the colour of the pther planks! Dev throws away paint sprayer and scrubs paint off half the planks. Buys paint brush

  • Why, I can add interface requirements to new story's and throw them to backlog. Jun 29, 2016 at 17:23
  • because work.has already started so some of those components will be written. If you change requirements you are pulling the rug out from under the team
    – Ewan
    Jun 29, 2016 at 17:25
  • Its equivilant to saying, spend a week redoing that bit so we can split this 2 week task into 2 1 week tasks
    – Ewan
    Jun 29, 2016 at 17:27
  • 1
    I get your point, but in most case's you see what has been committed to git, and present on CI, and hear the progress on daily standups, so you can chop the story's that are not affected. It's a rare things to see, that developers start to implement everything in a big story at once. Typically they make their own undocumented split. Jun 29, 2016 at 17:29
  • No. Its a very bad idea. You will screw up the architecture
    – Ewan
    Jun 29, 2016 at 17:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.