In Jira, what should I do if changed requirements increase a task's estimation singnificantly?
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.
Demir last edited by
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".)