Sprint Goal modified

if the Dev team has a Sprint Backlog prepared with a Sprint Goal defined, Can the Sprint backlog change during the sprint if necessary meaning adding more backlog items or removing some ?

In Scrum, team members commit to the goals of the team. The Sprint Backlog can be thought of as the team’s forecast of the work needed to meet the Sprint Goal.

Since team members can be expected to commit to a goal rather than a forecast, and since the Daily Scrum is a formal opportunity to inspect and adapt progress towards the Sprint Goal, would you say that the Sprint Backlog ought to be fixed or mutable?

 

But then I wondered: if the Dev team has a Sprint Backlog prepared with a Sprint Goal defined, Can the Sprint backlog change during the sprint if necessary meaning adding more backlog items or removing some ?  

Yes, the Sprint Backlog should change within the Sprint based on inspection and adaptation.  Think of the Sprint Backlog as more than Product Backlog items, as it also contains the forecast of the work needed.  In Sprint Planning the Development Team cannot possibly forecast every bit of work.  They may even remove work, or renegotiate a Product Backlog item with the Product Owner, as long as the Sprint Goal is not jeopardized.  

The Sprint Goal provides the team with focus, or 'the What'.  The Sprint Backlog is 'the How'.  Think of the Daily Scrum as a planning event for the Development Team, where they inspect and adapt the Sprint Backlog and focus on the most important work for the next 24 hours to meet the Sprint Goal.

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. 

So a complete Sprint Backlog contains at least three elements, including:

• Selected PBIs
• A plan for delivering the product Increment
• The Sprint Goal

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

As new work is required, the Development Team adds it to the Sprint Backlog. 

Scrum is a Framework, not a process. Therefore, Scrum Guide does not strictly define what the so-called plan is. Simply put, the so-called plan is HOW to complete each PBI, including what technology, how to disassemble into work items, how to allocate work, and so on.

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Scrum. 

The Sprint Backlog is a highly visible, real-time picture of the work that the Development Team plans to accomplish during the Sprint, 

More realistically, developers will analyze and discuss how each Item is to be done every day. The status of the to-do items, in-process, and completed work items is also updated. These can be the content of the plan that belongs to the Sprint Backlog.

Thank you all for your answers. 

Now I have a new doubt, so the sprint backlog does change during the Sprint, either by adding or removing items to/from it. Wouldn't these actions affect our metrics and therefore the metrics won't be as reliable as expected?

Luis,

It may be worthwhile to have metrics around a team's initial forecast and how much they ended up completing within a sprint, to judge whether such discrepancies (if any) are a result of practices that can improve (i.e. - refinement, sprint planning, estimation).

Ultimately, a team's metrics will be based on story points or value delivered each sprint, to be used as a guide in planning future sprints.   Adding or removing items during a sprint will not affect such metrics.

Wouldn't these actions affect our metrics and therefore the metrics won't be as reliable as expected?

Shouldn’t the metrics be kept up-to-date, so that whenever they are referred to in a timely manner, they always tell the truth?

I think I have to make it clearer. 

so the sprint backlog does change during the Sprint, either by adding or removing items to/from it. Wouldn't these actions affect our metrics and therefore the metrics won't be as reliable as expected?

The work items I mentioned earlier refer to the tasks that the development team needs to do to complete a Product Backlog item. It does not mean that the Development Team can add or remove Backlog Items at any time.

Usually the set of Product Backlog Items selected for the Sprint is unchanged. Unless it is a matter of urgency, or the Product Owner believes that it is not possible to achieve sprint goals without adding the Product Backlog Item. However, this still requires the development team to agree, because the owner of Sprint Backlog is the development team. After new PBI is added, the product owner must discuss the priority of these PBIs with the development team. Because some PBIs may not be done in the end of the Sprint.

I don't know what metrics you care about. As for Metrics, it is important to pay special attention to the data recorded by each Metrics and its purpose and meaning. Otherwise, these Metrics not only have no value, but will affect productivity. But if used well, can achieve the unexpected effect.

Let me give you a very interesting example. Usually we think that the number of Product Backlog Items produced as a performance appraisal is stupid. Because the Product Owner intentionally splits each user story very small.

However, if  "break down every user story very small" is the purpose of the manager? 

This is an interesting discussion and I'd like to ask how this can applied in the context of a team that does not work on a specific product i.e. the team is basically a middle layer that has services that are enhanced depending on the external projects that require its use.

For example, lets say that we have 5 Projects. As a requirement/need of these projects a service (API) that our team is responsible for needs to be enhanced i.e. data returned should be as per the requirements of these 5 projects, in addition to the data the service originally returns. Now, let's say that 2 projects need to be released in October, 1 in November and 2 in December. In such a scenario, do we prioritize the enhancements to our service based on the release date? In this example, is it correct to define our Sprint goal as "Complete all work for October". This will remain the sprint goal until all work related to that release is complete  and then once the October release has happened our Sprint goal would be "Complete all work for November". However, as team capacity permits we would also tackle work that is due for the other releases in such a way it still does not affect the Sprint goal i.e. if we have capacity we will work on items that are due for the November and December releases.

Also, I forgot to add that as work emerges we check the team capacity and then add more work mid sprint, again without endangering the Sprint Goal. 

Are we doing something wrong (because we are completing work without endangering the Sprint goal)?

I've heard many times from many Scrum Masters that once the work is committed it cannot be changed, new work cannot be added etc, but at the same time I'm in a dilemma when the scrum guide says scope can be adjusted provided it does not endanger the sprint goal.

If you can't articulate a sensible sprint goal and you need to react immediately to unforeseen work, is scrum the right fit for you?

Maybe a continuous flow model like Kanban can handle this sort of volatile multi product backlog more effectively.

In this example, is it correct to define our Sprint goal as "Complete all work for October".

Would that goal make the selection of work coherent, as described in the Scrum Guide? 

Is the product being worked on sufficiently complex or high-risk, or does it present enough significant unknowns, to make the organization of work into Sprints and the achievement of Sprint Goals worthwhile?

@Steven Langstaff, the point you mentioned has been raised with our management on several occassions. They however, want to drive Scrum.

@Ian Mitchell, by giving first priority to work that is due for a specific release, the team is clear on the fact that all enhancements to the various APIs we have, from the different projects requesting them are all combined and released into Production. If an enhancement that gets rolled out fails, yes, it would cause a high risk, depending on the service that is being invoked. Is there complexity, yes, again based on the service that is being enhanced. We don't necessarily work on one specific service at any given time. Based on the requirements of the various projects, sometimes, changes are made to the same service and all the changes are then collectively merged to meet a monthly release date.

A flow based approach might be best suited but what's the best way to convince management if they are hell bent on using scrum?

Also, if we are technically doing scrum-ban, that's not stopping us from being agile, is it?

A flow based approach might be best suited but what's the best way to convince management if they are hell bent on using scrum?

There’s nothing to stop you from optimizing value and flow in Scrum, or indeed from implementing Scrum with Kanban. However, if any part of Scrum is not implemented (such as Sprint Goal coherence) then the result will not be Scrum.

If I was in your position I would make that clear to management, rather than fake Sprint Goals which seem to be of little use. No-one will be well-served if Scrum is twisted and forced into contexts for which it is not suited.

Also, if we are technically doing scrum-ban, that's not stopping us from being agile, is it?

Technically, Scrumban is a journey from a mature Scrum implementation towards a Kanban way-of-working. That isn’t what you have. You’ve got a sort of ongoing hybrid which is neither Scrum nor Scrumban nor Kanban.

What is immediately stopping you from being agile is a lack of transparency over these matters and over who ought to be in the driver’s seat regarding a team’s process. Sponsorship from management is important, but it has to be conscientiously applied using very clear terms of reference.

@Ian Mitchell, you are absolutely right in saying that we have a hybrid that is neither Scrum, Scrumban, Kanban. Thank you for the explanation.

Could you help clarify why you said that Scrumban is for a more mature team? Why can it not fit for a team that by nature is best suited for the approaches used in both frameworks? By the way is Kanban a framework or a methodology. I keep hearing both and the Kanban guide says its a strategy.

Could you help clarify why you said that Scrumban is for a more mature team?

Implementing Kanban requires transparency over constraints which are then challenged and optimized. Scrumban is a journey from Scrum to Kanban. Only a mature Scrum Team is likely to have a clear and unobscured view of the constraints it is genuinely operating under.

Why can it not fit for a team that by nature is best suited for the approaches used in both frameworks?

It's possible to have a hybrid agile way-of-working which is better suited for certain challenges than other named approaches. However, that hybrid would not be Scrumban any more than it would be Scrum.

By the way is Kanban a framework or a methodology. I keep hearing both and the Kanban guide says its a strategy.

From a Scrumban perspective Kanban may be seen as a tool. From a Scrum perspective it represents a strategy.

Dear Experts,

If the Sprint Goal is achieved before time but Team is not in a position to complete new story, is it ok to still add that story in sprint backlog and complete it partially? PO is forcing to start working on new story and remaining work is expected in next sprint. Is this the right expectation and approach?

What all are the alternatives to make correct utilization of Dev Team in such situation?

Thank you in advance.

Once the Sprint Goal is achieved the Development Team can do whatever they think best until the end of the Sprint time-box.

They could start work on another Product Backlog item for example, and perhaps without committing to complete it, although they would have to be sure it would not compromise the Goal already achieved and would not incur any unacceptable technical debt. Neither the Product Owner nor anyone else can force the team to start any such work, or indeed force the Development Team to do anything at all.

Thanks Ian for the quick response.

Let me give more details about the situation. We are just in Sprint 01. Everyone is new to the scrum process .

During Sprint planning (2 weeks sprint), team has decided to deliver stories worth 21 story points. However the development (coding) was completed too early than thought of...for all planned stories. Testing team members of the scrum team were still busy in testing the developed functionalities. 

Still 3 days were available where development team had bandwidth. There was no story which team could accommodate and complete in this timeline. Refinement session was not possible as testing members were busy. 

PO was pushing for doing coding of story from next sprint.Team was not ready to take the same since they were aware that testing can not be completed for this new story and hence cannot be completed. 

What you will suggest in this situation? Should team do only coding in this sprint and keep testing part pending for next sprint? What scrum methodology says about this?

This may happen in next few sprints as everyone is new and no idea about the probable velocity  of the team.

Testing team members of the scrum team were still busy in testing the developed functionalities. 

Still 3 days were available where development team had bandwidth. 

No there weren't 3 days "available" to the Development Team. The stories still constituted the Development Team's work-in-progress, because they were not finished. They still needed to be tested. There is no separate "testing team" in Scrum.

PO was pushing for doing coding of story from next sprint.Team was not ready to take the same since they were aware that testing can not be completed for this new story and hence cannot be completed.

The Product Owner should be pulling for completed and release-ready work, not trying to push new work onto the team.

What you will suggest in this situation?

Development Team members should understand that their responsibility is to complete work, and not to merely start it. If testing needs to be done, then that is what team members should do. If any members have a testing specialism, then others should help them as much as they can and further develop their own expertise in this area. The team should also be aware of how bottlenecks can build up when work-in-progress is not sufficiently limited, and aim for a smooth flow of completed work, rather than the transfer of batches of built-up work from coding to testing. Also, the Product Owner should be aware of the need to exert pull. A smooth and efficient agile way-of-working involves having a pull-based system.

@Ian, what you say makes perfect sense, however, I see the problem that @Yashodhan faces. I have seen this happen in some of our teams too. Whilst its ideal to not have a distinction amongst the "developers" of the Development team, in reality there are developers, BSA's and testers. What I can gather from @Yashodhan's description is that his development team has developers and testers, they have a story that constitutes both coding and testing (my assumption), the developers have completed their part of the story and the testers have taken over the testing and are still continuing with that. During this time, the developers are technically in a waiting mode and external management or the PO does not want them to remain idle and hence is asking them to pick up more work. The common arguments I hear when this is challenged is, "Agile does not work for us", "We are wasting time because the developers are idle and we need to give them more work" etc.@Ian, This is where I agree with you that the developers should pitch in to help the testers, but this seldom happens in my team. What I've learnt from this is that there should be a stronger emphasis from management for the members of the development team to be cross functional or else in my opinion, there will be silos within the development team (ex: developers, testers, BSAs) and because of that the developers will appear to have capacity to take on work.

external management or the PO does not want them to remain idle 

It is a misguided approach at best to be concerned about the runners, and not the baton.   Management should care more about the value being produced (and how quickly it can be completed), and less on how busy everyone is.   

As Scrum Masters and Agile practitioners, we should be prepared to highlight dysfunctional practices such as premature optimization.   

From a Lean standpoint, you are just creating excess inventory by asking team members to "work ahead".   In addition, the availability of other team members during testing allows for quick analysis and resolution if testing uncovers any defects.