Can we add/modify items during sprint ?

Hi Mayank,

there are lots of misguiding resources on the web. Please stick with the Scrum Guide.

`As the Development Team works, it keeps the Sprint Goal in mind. In order to satisfy the Sprint Goal, it implements the functionality and technology. If the work turns out to be different than the Development Team expected, they collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.` (page 10)

During the Sprint:
 No changes are made that would endanger the Sprint Goal;
 Quality goals do not decrease; and,
 Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

People in my classes and coaching ask this question a lot. Here is my answer:

http://www.scrumcrazy.com/scope

http://www.scrumcrazy.com/bugs

First of all the Development team owns the sprint backlog... as such if they feel they can bring in more work as prioritized ny the product backlog then that is okay and further through the decomposition of tasks this can also introduce additional ones as well as changes... Above all as long as the Sprint goal remains intact and work is done without compromising the definiton of done then its okay...

What should a team do if, halfway through the sprint, one or more members of the team have nothing to work on because of skill set? Our critical path items cannot be addressed by some team members, so they have no tasks they can help with. At this point, is it acceptable to add items to the sprint backlog?

If they are unable to collaborate to finish work in progress, how does this collection of people represent a "team"?

Not everyone on the team has identical skill sets. There are certain types of analyses only a subset of the team can do. So, while I get your question, the original problem remains - can we, according to Scrum rules, add tasks to the sprint during the sprint under these conditions?

Jason,

Think of an analogy of an auto assembly plant.

One worker knows how to build doors. There were two "door" stories in the sprint, and halfway through the sprint, that worker completed the door stories. There are other stories in the sprint that the "door" worker doesn't have knowledge or experience with (seats, electronics, drive train, etc).

Does it make sense to have that worker continue to build doors, instead of helping in any way with the "critical" items needed?

Bringing in additional work in response to team member capacity is only one option. What about learning activities, like cross-training, or pair programming? Is there value in that team member simply observing and learning for the rest of the sprint? Can that team member help groom future stories?


Some questions for you:

Does your Scrum environment promote a dynamic where there is team ownership of all the sprint stories accepted/forecasted?

What are the effects of worker specialization and silo-ed work on completion of the "critical path" items? If it is negative, what can be done to help mitigate that effect?

You ask some good questions. I think for the most part, the answer is "yes", but there are definitely some things that only certain members of the team can work on. We're talking about some complex control algorithm development as part of the software and only the team members familiar with these specialized control algorithms can do anything with this aspect of it. It's almost like having software and hardware people on a team and the hardware people knowing nothing about software.

Posted By Jason Bold on 31 May 2016 11:18 AM
... only the team members familiar with these specialized control algorithms can do anything with this aspect of it. It's almost like having software and hardware people on a team and the hardware people knowing nothing about software.

Jason, this "specialization" is a current impediment within your team/organization. It is not only a significant vulnerability (should all work stop if the "specialists" are unavailable?), but it is in fact slowing your progress down.

The question to ask, and to continue asking, is what can be done by your team/organization to mitigate this risk?

Hi everybody:

I kind of have the same question but regarding the estimation of the new added task.

Let's say as the result of a completed task I execute a new one that was not even in the sprint backlog, neither had an estimation (story points, t-shirts size, etc). However since task A was completed, task B was the natural next step and was also completed during the sprint.

What would be the best way to assign its corresponding story points?

Thanks for your feedback!

Why estimate it at all? The only purpose of estimation is so Developers can get their arms around how much work they can take on in a Sprint. Here, it sounds as though you've decided to do it anyway.

Ian thanks for your response.

I was asking about estimation so at the end of the sprint this task is also recorded and take into account for team's velocity. If no estimated at all this might cause a slight deviation, what are your thoughts about it?

I second @Ian Mitchell's response.  If you have already decided to do it in the Sprint you have in fact estimated and decided it can be done during the time remaining in the Sprint.  But you should look at what is already in the Sprint Backlog to make sure that adding this task will not cause others to be unworked. 

The risk of introducing new work into the Sprint is that it could endanger the ability to finish work that was already included.  That is what you should be most concerned about. If estimating it helps to facilitate that discussion, then you should estimate it just as you did any other task.  But if your team feels that they can discuss the implications without an estimate, don't expend the effort to estimate. If you are doing estimation as a team, that effort could be more time than it is worth.  If you are doing estimation by individual, well that is a topic for another time. 

I want to thank you all, great discussion, great inputs, thank you very much for your comments

I was asking about estimation so at the end of the sprint this task is also recorded and take into account for team's velocity. If no estimated at all this might cause a slight deviation, what are your thoughts about it?

I know you asked @Ian Mitchell that question but I'm going to give you my opinion anyway.

If you are using estimates to calculate velocity then you are truly guessing at the team's velocity.  Remember estimates are guesses made based on information available at the time you make your guess.  After work begins you learn more.  If you were to look back, what are the chances that every story estimated as an 8 on the fibonacci sequence took exactly the same amount of time/effort to complete? 

In my experience, using metrics like throughput or cycle time provide a much better indicator of velocity since they are based upon the actual work undertaken. Estimates are useful for the developers to approximate how much work they feel they can do but it is not a good indicator of how much was actually done.