Changing the Sprint Backlog

No, because there is no evidence that the work is in fact required. The Development Team have not determined that it is necessary for the agreed Sprint Goal to be accomplished.

I think the spirit of "As new work is required, the Development Team adds it to the Sprint Backlog." is around adding it in collaboration with the product owner and, if your team is using development tasks to support stories, adding tasks. Adding a wholesale new item to the backlog without the product owner taking the lead on that would be removing transparency and ultimately undermining trust with the product owner. By the way, you don't HAVE to have tasks make up stories and you don't even HAVE to have stories as your requirements - it's just a couple of practices many of people tend to do.

Hi I think that the product owner should solve this problem, this role should be the main contact with the business, the scrum team is focus in deliver the product and should not have to deal with this kind of decisions

Thanks for the quick response guys. All clear now.

The statement.. "As new work is required, the Development Team adds it to the Sprint Backlog." relates to work regarding a specific Product Backlog Item.

The Dev. Team may have broken down a backlog item into tasks and as they proceed with the Sprint they may identify more tasks required to complete that Backlog item.. The Dev. team may add these tasks (new work) to the Sprint Backlog without discussing with the Product Owner as it still aligns with the Sprint goal to finish the Product Backlog.

The question relates to the CEO adding a new item (which may not be even on the Product Backlog) to the Sprint Backlog. This can only be done if the Product Owner says so (after discussion with the Dev Team) as it will have a direct impact on the achievement of the Sprint Goal.

In the sprint planning, the Product Owner and the Development Team agree on dedication to realize a set of items from the Product backlog. The Sprint backlog contains the tasks necessary to realize the increment. Not all tasks will be known in advance at the sprint planning, so the Development Team will add tasks when these emerge.

In the question, the word item refers to a desirable product feature, a Product Backlog item. The CEO is not allowed to interfere with the sprint goal.

The Product owner represents the stake holders / clients / customer to the Development team and visa versa.

So, the Development Team is free to manage the works items necessary to realize the agreed Sprint Goal. If the CEO wants to change priorities, he should talk to the Product Owner not to the Development team.

In addition to this, I have the following question.

We work in devops teams and therefor it is not uncommon for new user stories to be taken into the Sprint (PO and dev-team agree). But when they do so, should the user story lowest on the SB be removed?

My thoughts on this:
1. Yes: because that is what the dev-team wants. And the dev-team has committed (forecast) the Sprint and so it's their call. Ofcourse the PO should agree the US is important enough to let the team shift focus and potentially harm the Sprint goal.
2: No: it does not support transparency because this way the burn-down still goes down nicely and the team can report it has done the velocity they forecast during the Sprint Planning. Stakeholders however should notified at the review that work was added because there was a change in priorities. At the end of the sprint the user stories lowest on the Sprint Backlog won't be finished, so the result is the same as in point 1 above, but there's more transparency.

What would be your advice to the team and PO?

> ...the PO should agree the US is important
> enough to let the team shift focus and
> potentially harm the Sprint goal.

In Scrum the only reason for replanning the Sprint Backlog is to improve the prospects for achieving the Sprint Goal. Neither the PO nor the Dev Team would revise the backlog if, in so doing, they put the Goal at increased risk.

If the delivery of any part of the Sprint Backlog is considered to be more important than the attainment of the Goal, then the Sprint itself is devalued and Scrum is not being applied.

I’d say no, and see what you all learn.

- Everybody calls in sick / burnout / leave the company after this sprint
- There is no potentially releasable increment
- You can do much more in a sprint than imagined
- The sprint planning was bad
- Scrum team should learn to say no
- The PO has a problem with setting priorities / having a product vision
- The sprint time box is too long
- You guys conclude that Scrum doesn’t work
- ???

Haha I think the latter Christiaan! ; )

@Ian: what's general practice for devops teams doing Scrum in that case? Operational issues that can often have higher priority over feature development and is difficult to plan. What's your experiance?

Haha Jasper, if you guys abandon Scrum, I know this method where change does not exist by definition.

It is called: waterFAIL!
;-)

(Couldn’t resist making the joke, apologies to all)

> what's general practice for devops teams doing Scrum in that case

In my experience the best Scrum Teams are DevOps teams. By bridging the so-called "Dev-Ops Divide" they are more likely to have the skills needed to deliver feature-complete increments into production.

However, it is also my experience that very few self-described DevOps teams are actually doing Scrum. What they generally "do" is some variant of Scrumban in which the quality of service is permitted to vary. Typically they will offer an "expedite" or "fast track" class of service for certain unforeseen incidents. There is a cost-driver behind this model, because it amounts to one team doing double-duty for both capitalized (project) work and incident handling.

Another variation is to take a DSDM approach to timeboxing, and use the iteration backlog as a trading space. New requirements can be traded out of timeboxed scope by exchanging them for work of an equivalent size. This latter technique is perhaps more in line with the approach you have described.

These delivery models aren't necessarily "unagile". In my experience they do however become inappropriate when they are confused with Scrum, and terms like "Sprint" and "Sprint Goal" are applied to them. That isn't right, because Scrum vocabulary is very rigorously defined and the use of its terminology is held to mean quite specific things.

Hi Ian,

You say the best Scrum Teams are DevOps teams, yet you also say that very few DevOps teams are actually doing Scrum.

Can you describe a good DevOps team doing Scrum?

> Can you describe a good DevOps team doing Scrum?

A good Scrum Development Team will exhibit a DevOps capability. Team members will be able to perform all of the work that is needed to deliver production-quality increments. They will not be working in a "Dev" environment and deferring the matter of deployment to a separate "Ops" team. This comprehensive capability will be reflected in their Definition of Done.

Furthermore, any changes to the Product, however small, will be owned by the Product Owner and ordered on the Product Backlog. These items will not be subjected to a triaging mechanism that directs them away from the Product Backlog for handling by a separate Operations team.

Advanced Scrum Teams may support continuous integration and deployment into a business-facing environment. The Sprint Increment in such cases would be an aggregation of discrete releases rather than a single "drop" at the end of the Sprint, and there would likely be a high level of process automation. This capability is often associated with DevOps although it is not essential to it.

What if the customer wants to add features to that sprint? e.g. a DevTeam is working on a new feature for a client and mid-way through the client wants to add a new feature to the Sprint ? Should a Product Owner allow this or tell the client it will go in the Product Backlog?

The PO should tell the client it will go on the Product Backlog. What happens at that point depends upon the value of the item in relation to the Sprint Goal. If it improves the likelihood of meeting the Goal more effectively, then the PO should discuss this matter with the Development Team. The Development Team is expected to replan as needed during a Sprint so the agreed Goal can be better served.

Thank you, this is an issue I see often - at times I think those who are not involved with building software have no concept of the time to scope, build, test, and release the product vs. wanting it now (and hard is it.)

You brought up another point I am having difficulty finding exactness on and that is:

-Who defines the GOAL? Is it solely the PO, or the DevTeam or both?

-Is the goal the tasks to complete?

-How does the goal differentiate from definition of done and "potentially releasable product?"

Quote from the Scrum guide, "The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal...The Sprint Backlog makes visible all of the work that the Development Team identifies as necessary to meet the Sprint Goal."

In my opinion the term Goal is not fully defined in the guide, but it is such a powerful term for the functionality of Scrum that I need more clarification.

> Who defines the GOAL? Is it solely the PO, or the DevTeam or both? 

In the section on Sprint Planning, the Scrum Guide says:

"After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal"

> In my opinion the term Goal is not fully
> defined in the guide, but it is such a powerful
> term for the functionality of Scrum that I need
> more clarification.

The key concepts I'd pick out from the Guide's treatment of the Sprint Goal are:

- it's an objective that will be met
- it gives guidance on why the increment is being built
- it allows implementation flexibility
- it amounts to a single coherence
- it's a reason for team members to work together rather than separately
- it allows negotiation of scope in the Sprint

Try coming up with examples of Sprint Goals that satisfy these terms.

To the Sprint Goal concepts I’d like to suggest:

- It gives guidance to the three questions/answers on the Daily Scrum
- It communicates to the stakeholders what the Scrum Team is doing.
- It gives context to the Sprint Review

The last two are not in the Scrum Guide, but I think it makes sense.