Change during Sprint initiated by Product Owner

1. The change should not violate the sprint goal.

2. The development team 'owns' the sprint backlog. Changes should be negotiated with the dev team.

The Sprint Backlog is the Development Team’s forecast of work for meeting the Sprint Goal. They wholly own that forecast and it is theirs to replan as needed.

In the situation you describe, why does the Product Owner wish to change the team’s plan of work? Is the PO also a member of the Development Team in this case? Or has the Product Backlog been insufficiently refined for the PO to trust the team’s judgment regarding their implementation choices during the Sprint?

I'm starting to understand that the concept of a proper Sprint Goal is crucial. I wonder why there  are so few discussions about that topic. In real world, I've seen many Scrum implementations where the goal of the Sprint was delivering the estimated User Stories without any proper Sprint Goal. Maybe Scrum is not understood correctly in this cases. 

As a Scrum Master how do I coach the team/organization to make more use of Sprint Goals? Here are my thoughts

• A Sprint Goal in Scrum is similar to the traditional Project Goal. It should express the business needs and be the guide why software is developed. There should also be a Return Of Investment calculation for the Sprint Goal. A Sprint should be as independent as pUsossible from other Sprints.
• In a Sprint everything can change but the Sprint Goal. For example if the Scrum Team finds a complete different solution meeting the Sprint Goal during the Sprint, that's fine. This fosters creativity.
• A Development Team will commit to a Sprint Goal with much more creative energy than in committing to an estimated set of concrete work.
• If it's tricky to find a proper Sprint Goal than try to experiment with the length of the Sprint. Maybe features are small and widely spread or are big and belonging together.( But please don't change Sprint length often just  fit to the Sprint Goal) . I think things are different for products in chancing  quadrants in a growth share matrix. The poor dogs business needs differ a lot from the needs of the question marks.
• Using User Stories is not part of the Scrum Framework. It's an implementation issue. Why should the Product Backlog consist of User Stories and not of goodwill Sprint Goals? 

Comments welcome

I fully agree with everything Ian and Norbert wrote. 

>> Yesterday a Scrum Master said that he doesn't like it if the Product Owner changes requirements during sprint. This >> statement made me think about it.

I'd be curious to know what the Development team says about this in their retrospectives?  How have these changes impacted their ability to meet their Sprint Goals? 

Jorg,

My responses to some of your observations are below:

There should also be a Return Of Investment calculation for the Sprint Goal. 

What is most critical for the Development Team is to be able to identify the business value of the work they forecast for the sprint.   A ROI "calculation" may require additional translation to the Development Team.   A simple statement/discussion may suffice.

In a Sprint everything can change but the Sprint Goal.

Even if the solution identified by the team changes in the sprint, that should never necessitate the scrapping of an entire sprint forecast.  

Stories should be designed around a business benefit (what) without needing to identify a potential solution (how).   Sprint Goals can be crafted around related business benefits.   The team's forecast should be based on delivering the Sprint Goal (and related business benefits), and that should not change if the team changes how to deliver those benefits.

If it's tricky to find a proper Sprint Goal than try to experiment with the length of the Sprint. 

I would highly caution against an approach where the sprint length is variable.   Adjusting sprint lengths may be in response to the Development Team's ability to deliver work according to their DoD, or actual changes to the DoD, but not as a result of difficulty identifying Sprint Goals.

Why should the Product Backlog consist of User Stories and not of goodwill Sprint Goals?

Because Sprint Goals are simply objectives.   They are inherently nebulous.   Per the Scrum Guide, they don't even exist until Sprint Planning.  

How would a team even forecast a Sprint Goal with a high degree of confidence/certainty without clear refinement of the items needed to achieve it?

 

Timothy, thx for your answer.

I need to dig through the blogs and older threads to improve my understanding of Sprint Goals. I am really curious about to understand the value of Sprint Goals and to reflect on the question if Scrum without proper Sprint Goals is still Scrum or a type of Scrumban.

Late to the party here but thought I would ask anyway. 

I'm a trainee PO and was wondering how the amount of effort for a story can be estimated (and therefore how long it is going to take) if the Stories only state what needs to be done, not how to do it. 

In other words, if the WAY that stories are fulfilled is open to change at the beginning of a sprint, then surely you can't know how much effort this is going to take? 

                @Jamie Shaw, The development team make a forecast that how much work they can take and make it to done in the given time box (Sprint). And to forecast that work they decide what technique they use for estimation and its transparent to PO and other stakeholders. 

                 Development team owns the sprint backlog and they know how the work has to be done. As a PO, you should respect their decision that how the work will be performed to make the story as "Done". In Agile  we welcome changes even in late development but it needs a discussion with the team and negotiation to know how the change will not affect the sprint goal. Development team also knows that customer's satisfaction is a top priority so if they do not feel comfortable to change they come with some genuine reason.