Add new backlog to the sprint on the end

How can a developer add backlog item to the Sprint backlog without the Development Team agreeing and committing to it?

Also, if its obvious it cannot be completed and "done done", how does it even make it to the Sprint backlog? The work selected (for a sprint) must be achievable given the remaining capacity of the Development Team -- and doable (which means designed, coded, tested, etc, etc) so the "fixed" functionality is part of the potentially releaseable increment.

Opinion (others, please chime in): Assuming no other work left to meet the Sprint Goal, why can't the work for this bug fix begin as long as it is in the Product Backlog (and to be included in the upcoming/next Sprint Backlog) if the PO and Dev Team agree on its priority.

Thank you very much for your comment.

Posted By John Pluto on 18 Feb 2015 11:32 PM
How can a developer add backlog item to the Sprint backlog without the Development Team agreeing and committing to it?

It was agreed, few days before, than if this happen Developer can just pick existing bugs (and only bugs) from the product backlog (from the top of the list). In this specific case the bug was clarified, estimated and prioritized during the sprint (in backlog refinement) - was the first item to be picked during next planning session.
I tried to learn a bit more, and I found that if there is need to add anything to the sprint, it should be done during Daily Scrum - we didn't followed this rule, so perhaps we have a mistake which we should avoid in the future. But this mistake doesn't change the question, because it still unclear for us, if in such case DevTeam should commit to such item just to start work as early as possoble, or if DevTeam should refuse this and wait for a next sprint?

Also, if its obvious it cannot be completed and "done done", how does it even make it to the Sprint backlog? The work selected (for a sprint) must be achievable given the remaining capacity of the Development Team -- and doable (which means designed, coded, tested, etc, etc) so the "fixed" functionality is part of the potentially releaseable increment.

Yes - this was also how I understood how it should be. But this is not a common point of view of all team members, so that I decided to ask also others - more experienced in Scrum :)

Opinion (others, please chime in): Assuming no other work left to meet the Sprint Goal, why can't the work for this bug fix begin as long as it is in the Product Backlog (and to be included in the upcoming/next Sprint Backlog) if the PO and Dev Team agree on its priority.

And answer to this question seems to be essential to solve dilemma which we currently have in the team.

> In the last sprint we faced situation where for some people there
> were no more tasks in sprint possible to take. In cooperation with
> Product Owner we decided that if this happen during the sprint, DevTeam
> can pick bugs from Product Backlog and add them to current sprint.

That might be a reasonable agreement if the Development Team as a whole had no tasks. Remember that in Scrum, planned work belongs to the Development Team and not to individual team members.

No Development Team member should draw new work into progress as long as existing work, corrently in progress, remains incomplete. The first duty of a team member without work is to assist other team members. If they are unable to do so (for example due to "skill silos") then that is an impediment that should be challenged.

> Assuming no other work left to meet the Sprint Goal, why can't the work for
> this bug fix begin as long as it is in the Product Backlog (and to be included
> in the upcoming/next Sprint Backlog) if the PO and Dev Team agree on its priority.

The team can if they so wish, and regardless of whether or not the fix is likely to be completed by the end of the Sprint. The important thing is that the Sprint Goal is not dependent upon it and there is no other work in progress or in the Sprint Backlog. The team are then free to induct new work. If it is not completed within the Sprint, they should re-estimate the associated PBI no later than the Sprint Review to indicate the work that remains for future planning purposes.

It is important to be clear with stakeholders (via the PO) about the status of this item and to establish realistic expectations about its completion.

Thanks a lot for comments and clarifications. It looks so easy, when someone experienced explain this :)

Very interesting topic. Most of all, whole development team should be aware of taking into sprint something new - it's team not one person decision. Another question which comes into my mind - why do you estimate bugs? Adding something into sprint should always bring thinking:
- is goal in danger?
- are more valuable items in danger?
- is it something which we need to do?

Going back to main question - I can imagine situation critical bug can appear and prevent release to happen. For me it may not be always so binary answer.

What is the most important thing - you found way how to solve bugs, you can check the others one too:)

Whenever there is individual capacity at the end of a sprint, there are a number of ways to address it.

One way, which your team formalized to some degree, is to take highly-prioritized "bug-work" from the product backlog. If this option is selected, it should never be done without the entire team's knowledge and assent, in addition to their agreement that it does not jeopardize the current sprint work. There must also be a high confidence that anything else introduced into a sprint can be completed within the sprint. If there is doubt that a new story/bug can be finished according to the DoD by the sprint end, then it should not be brought in.

There are other options though. Of primary importance is the current sprint work. If there is any work-in-progress, then the team member with the extra capacity should seek to help in any way to assist the team in completing those items. It also provides a great learning opportunity for that team member if they are unfamiliar with the technical or business aspects of remaining work.

Excess capacity does not always need to be addressed through sprint work, however. Reviewing code, addressing technical debt, using the extra time as an opportunity to learn - basically any activity that would improve the quality and viability of the team member should be welcomed during the extra-capacity time.

First and foremost though is the current sprint work, and ensuring a successful sprint (with 100% story acceptance and zero carryover).

> There must also be a high confidence that anything else introduced into a sprint
> can be completed within the sprint. If there is doubt that a new story/bug can be
> finished according to the DoD by the sprint end, then it should not be brought in

The Development Team can partially action work as long as doing so does not compromise the Sprint Goal and the ability of the team to assess when the work is Done. If the Goal has been met early, then they can pull in new work from the Product Backlog and with no expectation that it be completed by the end of the Sprint. From a delivery perspective there is no reason for it to satisfy the Definition of Done by that time, as it was not part of the team's commitment and there should be no expectation that it will feature as part of the Sprint Increment.

Undone work at the end of a Sprint should be re-estimated, and the Product Backlog updated. Previously worked-on items may be expected to result in lower estimates, as there is less work remaining. It should be borne in mind however that partially completed work will degrade the longer it is left undone and as such it can also represent a technical debt liability.

Undone work at the end of a Sprint should be re-estimated, and the Product Backlog updated. Previously worked-on items may be expected to result in lower estimates, as there is less work remaining.

Ian, to me, this seems to be a wasteful practice. Partially-done work at the end of a sprint represents not only a potential technical debt liability, but also a possible waste of team effort, especially if the Product Owner decides to prioritize a different set of stories for the next sprint (competitive pressure, business priority, etc). There simply is no assurance that the incomplete story can be continued into the next sprint, so why start it?

In my opinion, any work accepted in a sprint should be completed within that sprint. Allowing "carry-over" (as you suggest) blurs the time-box lines around sprint duration. Why have a time-boxed sprint, if we're suggesting to teams that they can just "work on stuff"? This is a resource optimization practice that should be discouraged in Scrum.

Also, it is a waste to have the team re-estimate a story to reflect remaining work. Are you suggesting that the team get credit for the portion of the story that they did finish in the sprint? If not, that distorts the relative estimation of the story, as the finished portion is not calculated in the team velocity for that sprint.

For example, if the story was estimated at 8 story points, why have the team try to figure out how much of the 8 points they finished? My suggested practice around carryover stories is to keep the estimate intact, and help the team understand that they only get credit for completed stories within a sprint. In the end, it all balances out, and no effort was expended around "re-estimating".

Ian, usually you are spot-on in your observations and advice, but I strongly disagree with your advice in this instance.

> There simply is no assurance that the
> incomplete story can be continued into
> the next sprint, so why start it?

A Development Team must deliver the best possible value to the Product Owner. If they have the opportunity to deliver not only an increment but also to further reduce the estimated work remaining in the Product Backlog, then they may do so if the Product Owner agrees. They are under no obligation to do so or to give any assurances regarding completion of that work.

> In my opinion, any work accepted in a
> sprint should be completed within that sprint.

The work that should be completed within a Sprint is that which is needed to achieve the Sprint Goal. Other work may or may not be done, though it is reasonable to expect a team to try and further maximize the value to the PO within the remainder of the Sprint timebox.

> Allowing "carry-over" (as you suggest)
> blurs the time-box lines around sprint duration.

That is absolutely not what I am suggesting. There should never be any "carry-over" from one sprint to the next. Instead, any work which is undone should be re-estimated on the Product Backlog. Which Sprint that work is subsequently planned into, if any, is a decision the PO must make. That decision may be partly based on the depreciation of accumulated value and the advice provided by the Development Team.

> Why have a time-boxed sprint, if we're
> suggesting to teams that they can just
> "work on stuff"? This is a resource
> optimization practice that should be
> discouraged in Scrum.

The purpose of a time-boxed Sprint is to allow a Sprint Goal to be framed and met, an increment to be released, and for inspection and adaptation to be applied on cadence. In Scrum, team members clearly do not just "work on stuff". However there is no prescription against increasing the value to the PO once a team's commitments have been achieved, such as reducing the size of the Product Backlog and perhaps by even completing additional items. Scrum is a minimally prescriptive framework.

> Also, it is a waste to have the team re-estimate
> a story to reflect remaining work.

Team members should re-estimate regularly, in order to provide transparency over the work remaining. That isn't waste.

> Are you suggesting that the team get
> credit for the portion of the story that
> they did finish in the sprint?

Certainly not. There is no partial credit for undone work in Scrum. It is possible however for the size of the Product Backlog to be revised based on the latest estimates of the work remaining.

> If not, that distorts the relative estimation
> of the story, as the finished portion is not
> calculated in the team velocity for that sprint.

Unfinished work ought to be re-estimated in the Product Backlog to show the amount believed to be remaining. This has no bearing on the velocity of the Sprint.

> For example, if the story was estimated
> at 8 story points, why have the team try to
> figure out how much of the 8 points they finished?

They shouldn't do that at all, as there is no intrinsic value in the points. The purpose of estimates is to help a team figure out how much they can complete in a Sprint, which is not an exact science. The team should deliver the increment they forecast for completion, and may further engage in additional activities before the Sprint timebox expires, should such time prove to be available. If additional items are not completed to the satisfaction of Done, then the size of the Product Backlog should be re-estimated to reflect the work that is believed to remain.

Ian, we will apparently disagree on this one item, although I concur with many of your posts in other threads.

I maintain that it is unwise for a team to accept work into a sprint in response to excess capacity that the team is not confident in completing within that sprint. There is simply no value provided to a PO for stories that are unfinished at the end of a sprint, and unfinished stories do not reduce the size of the product backlog.

Allowing a team the freedom to bring in stories at the end of a sprint unrelated to the sprint goal, without the team conviction to complete the story within the sprint, actually increases WIP/inventory (lean waste). I cannot ascribe to that as a sound practice.

> There is simply no value provided to a PO for
> stories that are unfinished at the end of a sprint,
> and unfinished stories do not reduce the size of the product backlog.

The size of the product backlog should reflect the work that is believed to remain. Any effort expended by the team on work that is related to the Product may affect the corresponding estimates.

> Allowing a team the freedom to bring in stories
> at the end of a sprint unrelated to the sprint goal,
> without the team conviction to complete the story
> within the sprint, actually increases
> WIP/inventory (lean waste). I cannot ascribe to that as a sound practice.

At the end of each Sprint, no work should remain in progress. It should either form part of the increment or be accounted for on the Product Backlog. Whether any Product Backlog Item is completed or not is immaterial; it is possible that none may have been completed at all in a sprint. What matters is that the increment meets the Definition of Done, and that the Sprint Goal has been met and is not subsequently compromised by any further work that might be performed.

If any work is included as part of the increment then it is subject to depreciation as any part of the product may be. Items on the Product Backlog should accurately reflect the work that remains for their completion, including any depreciation of related work that has already been invested in the product.

Ian,

I don't see how we could allow undone work at the end of the sprint (in the form of started, but undone stories) and yet require that the team meets the definition of done for these stories. Maybe I'm misunderstanding something but this is really how I read your responses in this thread.

To me, the most important argument against starting work that the team doesn't feel they are able to complete within a sprint is that they would almost certainly fail on the backlog item(s) DoD.

Piotr

> I don't see how we could allow undone
> work at the end of the sprint (in the
> form of started, but undone stories) and
> yet require that the team meets the
> definition of done for these stories.

The critical thing to understand is that the Definition of Done applies to the increment, and not to product backlog items such as user stories. Secondly, the PBI's that are planned into a Sprint Backlog are a *forecast* of the scope that will be actioned to meet the Sprint Goal. Thirdly, a Development Team must deliver a "Done" increment that actually meets the Goal, and not the forecast.

A team should make a good forecast in order to have transparency over the work remaining in a Sprint. That forecast could turn out to be wrong however, perhaps with no story being completed at all by the end of the timebox, and yet the Sprint Goal could still be met by a competent team with a useful increment delivered. Valuable work will have been performed which meets the Definition of Done and the Sprint Goal, and which is fit for potential release. That work will have been "done" and invested in the increment.

Any undone work must be accounted for on the Product Backlog. Any inaccurate PBI's that were in progress during the Sprint must be re-estimated, revised if necessary to better indicate the scope remaining, and ordered in the Product Backlog by the Product Owner.

Clearly, since PBI's which were planned into a Sprint need not necessarily be completed in order for a valuable "Done" increment to be produced, there is no need for unplanned additional PBI's to be completed.

Ian,

Perhaps this is an interpretation issue?

From the Scrum Guide:

Definition of "Done"

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this varies significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency… The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done.”

The Guide not only acknowledges a DoD at a PBI-level, but it also recognizes the possibility of multiple “increments” of functionality being delivered each sprint. Certainly, there can be instances where an increment is represented by a single PBI.

That being said, the real issue is the wisdom behind introducing an additional story into the sprint in response to excess team capacity that is unrelated to the sprint goal or the increment(s) of functionality being delivered.

Perhaps the strong reservation I have regarding this approach is born from a Lean Agile mindset (WIP, Inventory waste, Transportation waste), and not necessarily a Scrum objection.

I do feel that some of your statements are contradictory though, so I would ask what exactly is your definition of carry-over, and how that differs from the approach you laid out where teams can bring in additional stories into a sprint with no obligation of completing them within the sprint.

> Perhaps this is an interpretation issue?

The Scrum Guide acknowledges that the term "Done" can be applied to individual items of work, and thus warns of the need for clarity when the term is used. However, in Scrum it is essential to have a Definition of Done which applies to an Increment. That is why the Guide says: "The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of 'Done.'"

> Perhaps the strong reservation I have
> regarding this approach is born from a
> Lean Agile mindset (WIP, Inventory
> waste, Transportation waste), and not
> necessarily a Scrum objection.

Yes, I suspect that is indeed the case. The advice I am giving in this thread may appear disconcerting from such a perspective. This is because certain conventions and norms found elsewhere in agile practice are not in fact germane to the Scrum Framework...at least in its present version.

In Lean-Kanban operations, for example, it might be reasonable to expect individual backlog items to be completed as per a "Done" assertion of quality. Scrum on the other hand puts the emphasis on delivering a "Done" Increment that meets a Sprint Goal. The purpose of backlog items is to provide transparency over work in progress, but their actual completion is, strictly speaking, quite immaterial.

> I do feel that some of your statements
> are contradictory though, so I would ask
> what exactly is your definition of carry-over,
> and how that differs from the approach
> you laid out where teams can bring in
> additional stories into a sprint with no
> obligation of completing them within the sprint.

First let me refer you back to my earlier remark:

"There should never be any 'carry-over' from one sprint to the next. Instead, any work which is undone should be re-estimated on the Product Backlog. Which Sprint that work is subsequently planned into, if any, is a decision the PO must make."

Hence in Scrum there should be no work "carried over". Holding on to the idea that work might be "carried over" is unhelpful and it will lead to confusion. My advice is to dismiss the idea entirely. In Scrum there is merely work which is Done and work which still remains to be done.

Ian,

if I get it correctly, the following statement might be one of my biggest learnings recently:

> The critical thing to understand is that the Definition of Done applies to the increment,
> and not to product backlog items such as user stories

Let's say that team took 5 PBIs (4 user stories, 1 defect) into the Sprint Backlog. Does it mean that, in your opinion, when this team will use DoD separately against all those 5 items, that would be just a matter of good practice (as opposed to following a Scrum guideline)?

How does your interpretation works in a situation, when team bundles all 5 PBIs into single Increment, and PO says that he'd like only 3 of them to be released on production?

> if I get it correctly, the following statement might be one of my biggest learnings recently:
>
>> The critical thing to understand is that the Definition of Done applies to the increment,
>> and not to product backlog items such as user stories

That’s right. There can be different levels of “Done”, and it is reasonable to talk about user stories (for example) as being “Done”, but the term “Definition of Done” properly applies to the increment.

> Let's say that team took 5 PBIs (4 user stories, 1 defect) into
> the Sprint Backlog. Does it mean that, in your opinion, when
> this team will use DoD separately against all those 5 items,
> that would be just a matter of good practice (as opposed to
> following a Scrum guideline)?

Yes. However, I would avoid using language in which a “separate" DoD is in some sense applied, as that is likely to cause confusion. It would be better just to say that there may be a level of “Done” which is applied to those items. In the case of user stories we might simply use the term "acceptance criteria". A Definition of Done can prescribe many such levels of Done, and having those levels can be good practice. They can be a good waste limitation strategy for catching and addressing problems prior to integration. Yet the DoD itself applies to the increment, no matter how many levels of “done” it encompasses.

> How does your interpretation works in a situation, when team
> bundles all 5 PBIs into single Increment, and PO says that he’d
> like only 3 of them to be released on production?

During a Sprint, the Development Team agrees to deliver an increment that meets the Sprint Goal. That Goal is a coherence of the selected Product Backlog items which would make the increment valuable. The Sprint Backlog, including those selected items, is a forecast of the work that will be needed to create the increment.

This means that if the PO only wants 3 of 5 items released, the corresponding Goal could be compromised. Remember, a Development Team agrees to deliver an increment which meets a Goal. If that Goal is a coherence of 5 items then there may be a problem if only 3 of them are subsequently wanted. The team did not *necessarily* agree to deliver any discrete elements of work other than the single coherent increment. In other words, they may not have agreed to deliver separately releasable stories at all, because the stories are a forecast of work, and a plan for the team to achieve the Goal. The stories don’t necessarily constitute discrete pieces of inventory.

Much of course depends upon *when* the PO makes the assertion that only three items are to be released:

1. If the PO expresses that desire during Sprint Planning, then there ought not to be a problem, because the Goal that is agreed in that event should represent a coherence of those 3 items only. The other items may be actioned in the Sprint but the Goal would not depend on them.
2. If the PO states that desire once development is underway, the team will have to determine what the impact is on the Goal that has already been agreed. If the Goal is now obsolete, then it may make no sense for the Sprint to continue and it could be aborted. The remainder of the Sprint time box can then be spent delivering those 3 items which the PO values.
3. If the PO announces a wish to only release 3 items during the Sprint Review, then the increment might not be releasable at all. Remember that the team did not *necessarily* agree to deliver any discrete and independently deployable portions of the Sprint Backlog such as user stories. What actually happens next will therefore depend upon 3 factors:
a) The Sprint Goal, and whether or not the Development Team *did* agree to provide independently deployable stories. If the Goal specified such a capability, then it should be possible to release just the 3 items.
b) The negotiated scope. If it is expressly asserted in the acceptance criteria of each of the 3 user stories that it must be independently releasable, then again it should be possible to release just the 3 stories.
c) The Definition of Done for the increment. If the DoD asserts best practices such as configuration management, the use of feature switches, or the need to make features configurable by other means such as scripts, then it might be possible for the team to release those 3 items only.

Ian, that's an exhaustive and thorough answer. I dare to say there are significant number of Scrum Masters who interpret following Scrum Guide statement incorrectly:

The purpose of each Sprint is to deliver Increments of potentially releasable functionality that adhere to the Scrum Team’s current definition of “Done.”

Plural of "increments" could be easily misunderstood, just like in my case, and taken as applicable to both PBIs and Increment. I've just read Scrum Guide in polish and it's the same level of ambiguity to me. Darn, maybe it's just me? I'll do my own research in this matter :-) Again, I'm glad that it came out before my PSM II exam...

In practice I've seen DoD being applied directly to PBIs. Now, in such cases, shifting DoD to Increment level is going to positively impact the speed of development. Yet, there still will be cases that it won't actually matter as many teams use feature branches and switches as a sound engineering practices (in web development, especially).

Another important aspect of DoD for an Increment is how it puts emphasis on a Sprint Goal. As you said, by releasing subset of SBIs a Sprint Goal might not be achieved. And if it was, what value it actually brings? If that's the case, then the difference between Scrum and Kanban is less significant.

> Yet, there still will be cases that it won't
> actually matter as many teams use feature
> branches and switches as a sound
> engineering practices (in web development, especially).

It could also cease to matter if the team agrees to provide an increment that consists of many smaller discrete increments. Scrum doesn't say anything about that situation, but the framework does not forbid it either.

> I'm glad that it came out before my PSM II exam...

For PSM I it is important to know and understand what the Scrum Guide says. For PSM II you should know and understand what it doesn't say, and why it doesn't say it.

> For PSM I it is important to know and understand what the Scrum Guide says.
> For PSM II you should know and understand what it doesn't say, and why it doesn't say it.

Well said, thanks.