We are currently working on a project where we receive a lot of change requests, and the client insists that we should deliver the changes in the current sprint!

Can I add the new work to the sprint backlog as a new task? Sometimes the tasks' effort changes, like earlier it was an 18 hour job but is now a 32 hour job.

How can I accommodate these changes without making a weird burndown chart? Is it okay to add tasks to a sprint in progress?

  • 1
    How long is your sprint? I agree with Skliwz and CodeGnome answers. Maybe a way to have a quicker feedback and allow PO to earlier influence the work which will be delivered would be to make sprints shorter? – Paweł Polaczyk Feb 12 '14 at 9:30
  • @PawełPolaczyk 2 week sprint – Harish Feb 17 '14 at 11:53

Can I add that to the sprint backlog as a new task ?

Yes, you can add stories to a running sprint, if the team agrees to it. It's not a good practice though as it reduces the usefulness and predictive ability of the methodology.

Some times the task's effort changes like earlier it was an 18 hr job now it's a 32 hr job

This is relatively unimportant: that's why stories are not measured in hours, but in points: the time estimates may vary during the sprint. That said, you only need to keep track of the time left, not the time elapsed.

If you feel that stories were estimated as simple and get more complex as the sprint is developed, there might be a few underlying issues:

  • Did you have enough information during the planning meeting to estimate the story correctly? In other words, has the scope stayed constant but the complexity of the task turned out to be higher than predicted?

  • Did you estimate the original story correctly, but the customer changed their mind during the sprint? If they did so because they legitimately changed their mind, then you should abandon the story and start a new one. If they are, instead, adding scope, then you should add new stories to the backlog for that.

How can i accommodate these changes without making a weird burn down chart ?? Is it okay to add tasks to sprint in progress ??

Yes, burn down charts can go sometimes up instead of down. It's probably not something you want, though!

All in all - these are the basic rules which you should look up to:

  • Only the team can accept new stories in a sprint. They cannot be forced on them. Doing so is simply contrary to basic agile principles.

  • New scope should always be a new story.

  • A new story can be added to a sprint if you take a correspondingly sized story out (the new story needs to be estimated by the team, and the team must accept this change as feasible).

  • A significantly changed sprint can be abandoned. You may stop the sprint, and start a new one from scratch, with a new planning meeting. Obviously, try to avoid this if you can.

  • As new information emerges the team might discover that it will take longer (or shorter!) to develop a story. This is expected. Story points don't change, hours left change.

  • As new information emerges the product owner might discover that they need more stories (or less!) than originally thought. This is expected. Add or remove stories from the backlog with impunity. Add or remove stories from the sprint only if the team agrees to the change and commits to it.


Scope Should Never Change Within a Sprint

We are currently working on a project were we receive a lot of change requests, and the client insists that we should deliver the changes in the current sprint itself!

This is a sign that You Are Doing Scrum Wrong™. While there are certainly edge cases where stories can be added or removed from the Sprint, or when the Sprint Backlog gains or loses tasks necessary to complete the current Sprint Goal, that isn't really the issue here. Instead, the issue appears to be that the client is not working through the Product Owner to review progress and adjust scope at the framework-defined inflection points:

  1. Backlog Grooming
  2. Sprint Review
  3. Meetings between the Product Owner and stakeholders to prioritize the Product Backlog for the next sprint.

How to Fix Your Issue

Stakeholders should not be allowed to change scope within the current sprint without the active cooperation of the Product Owner and an explicit Early Termination of the current sprint. Violating this principle will create invisible work and untracked overhead for the project, which is a big no-no.

That isn't to say that the development team can't work with the stakeholders or an end-user defined in a user story to clarify an in-sprint story or gain insight into the optimal implementation of a feature, but such interactions should not change scope or compromise the Sprint Goal defined during Sprint Planning.

The Product Owner and Scrum Master must work together with the stakeholders to enforce the integrity of the sprint, and to educate them about when (and how) to make changes to the project's scope within the Scrum framework.


The Ideal

All requirements are completely predictable. By doing enough analysis up-front, extra work will be discovered before the sprint starts. Accurate estimation will therefore be possible, and this question will never arise.

The Reality

Parts of your project will be new things you've never done before (otherwise it would be exactly the same project that you did before, and that never happens). Discoveries are inevitable, both in analysis and development. You can't estimate things that you've never done before, and trying to do so will usually result in floundering and / or estimate padding.

What to do about it

Recognize that there's always uncertainty in development and be adults about it. The end of the sprint is there for you to focus on getting feedback from your stakeholders, and that feedback is far more important than any story-point estimation.

Arguments over these discoveries often result in people spending more time trying to analyze the newest, most risky elements of a project ahead of time. Analysis isn't as good at flushing out those discoveries as actually delivering something is (or Waterfall methodologies would work), so when those discoveries are made, it's very important to focus on delivery and feedback.

Otherwise, analysis paralysis sets in, and those elements end up getting pushed to the end of the project instead, when there's no time to react to them.

The purpose of estimation and velocity measurement is threefold:

  • To help decide the focus for the sprint
  • To measure against long-term plans in order to see how a project is progressing
  • To help gain stakeholders' trust through delivery.

Pure Scrum doesn't mandate story points and velocity measurements. Instead of making promises around points, consider making promises around aspects of stakeholder needs on which you'll deliver or showcase something for the purposes of learning and feedback. By addressing the riskiest aspects of a project early on, you'll learn fast, de-risk the project (and help to make more accurate plans), and gain stakeholders' trust through addressing the things that stop them sleeping at night.

Under no circumstances should the story points ever be used to "punish" the team. That will only create a rift between the PO and other team members, and the PO ought to be part of that same team.

If you're looking for a tracking mechanism, and the scope changes happen regularly, consider a burn-up chart, or CFD, instead. That will let you track your work against the scope over the longer term, and you'll also be able to see how scope itself is changing.

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.