1

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? – Bart van Ingen Schenau Jun 30 '16 at 9:15
2

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 '16 at 10:15
5

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 Cooper Jun 30 '16 at 0:23
  • @NathanCooper Edited comment respectively. – Alexander Averchenko Jun 30 '16 at 7:08
-2

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.

Ie.

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. – Alexander Averchenko Jun 29 '16 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 '16 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 '16 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. – Alexander Averchenko Jun 29 '16 at 17:29
  • No. Its a very bad idea. You will screw up the architecture – Ewan Jun 29 '16 at 17:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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