0

Let's suppose a Scrum team estimated a Story and added it to a Sprint backlog. And during the work on that task a customer adds or changes some requirements and this increases the amount of work requied to complete the task.

We can do the following:

  • add the changed/additional requirements to the task.
  • create a new task for modifying/adding some functionality.

In the first case we can get a too large task (larger than recommended by Scrum practitioners).

In the second case we have two phisical Jira tasks for one logical task.

  • In your question, it's a bit confusing whether the requirements affect only one/some of the tasks or the entire story. (In my answer, I assumed it's the latter.) – Llewellyn Dec 19 '19 at 20:04
  • I should have written "Story", not "Task". – Chris Brettini Dec 20 '19 at 16:41
  • @ChrisBrettini, what would you do if the added/changed requirements came in after the team completed the story? Would it make sense to do the same when the team is actively working on the story (i.e. it has been added to the sprint backlog of the current sprint)? – Bart van Ingen Schenau Dec 21 '19 at 9:45
2

The way I see it, you have 4 options. Which one is best really depends on the exact circumstances. Personally, I'd worry less about the task size as the likelihood of reaching your Sprint goal under the changed circumstances.

1.) If the new requirements completely change the story, so that it needs to be replanned, and the story was one of the main focus points of the current Sprint, it might be best to simply abort the Sprint and restart the Planning phase with a new story, which you break into new tasks. (You might be able to move some unchanged tasks to the new stories.)

2.) If the new requirements completely change the story, but it was not the main focus of the Sprint, you could postpone the entire story until the next Sprint's Planning session and work on the other stories instead. Again, create a new story and new tasks.

3.) If the new requirements mainly add something to the story, you might be able to continue with the planned tasks with only slight adjustments (some tasks might be postponed, others slightly tweaked) and defer the updates to the future. For this option, you would keep the story, mostly keep your current tasks (with minor changes) and add new tasks for the necessary updates. (I guess that would be your option 1.)

4.) If the requirement changes are small enough to be incorporated into the current Sprint, but would invalidate the work planned for some tasks, the team could decide to adjust the current Sprint's tasks on the fly. (The story remains the same, and there should be no or very few new tasks.)

Options 1 and 2 make the cost of requirement changes very visible to the stakeholders. (The story gets postponed.) On the other end of the spectrum, option 4 sort of hides the cost, which might set a bad precedent. And option 3 falls somewhere in the middle.

What all of these have in common is that the team needs to discuss the options and that the requirements changes for a story in active development need to be addressed in the Retrospective.

Note that there's nothing wrong with splitting a big tasks into smaller ones. By definition, they'll cover different aspects. (If the initial tasks was "Implement widget" and under the changed requirements, this task becomes too big, you could split out the update into a new task, e.g. "Update widget visualization". If you want, you can rename the old task to "Implement basic widget".)

| improve this answer | |
  • Thank you very much for your answer, Llewellyn! It is very useful. But my question's focus is more on requirements traking, organizing them in Jira, keeping them in one place. Not about the next step after the requirement has changed. Could you please update your answer? – Chris Brettini Dec 19 '19 at 19:15
  • @ChrisBrettini I've added some recommendations for how to deal with the tasks. – Llewellyn Dec 19 '19 at 20:04

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.