Why do we have this Sprint Goal?

The idea of a Sprint Goal is to know why you are doing things. In the previous version of the Scrum Guide, it was about completing the sprint, now it’s about meeting the sprint goal. That’s in a lot of aspects the same thing, but for example, when the Sprint Goal becomes absolete, there is no need to complete the sprint, since the Sprint Goal has no value. Using a Sprint Goal helps the Scrum team to focus on the purpose and value of what they’re doing, instead of just finishing the sprint.

It is not mentioned in the Scrum Guide how to document the Sprint Goal, or even if you should do that at all. I would say that the purpose of a Sprint Goal is met when the Scrum team has the Sprint Goal clear for everybody. Tools to help there would be:

• Writing it on a big piece of paper and put it on the wall of the team’s location, next to / on the Scrum Board;
• Share it in a visible way digitally (helpful when not all team members are on the same location);
• Talk about it (at least in the Daily Scrum)

·        …

These are the most important parts in the Scrum Guide (2013) about the Sprint Goal:

Topic One: What can be done this Sprint?

…

After the Development Team forecasts the Product Backlog items it will deliver in the Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment.

Sprint Goal

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

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.

Daily Scrum

…

The Development Team uses the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog. The Daily Scrum optimizes the probability that the Development Team will meet the Sprint Goal. Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint. The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.

The Distributed SCRUM Team: agile teams anywhere on the globe

"We are looking for a location where we can all be, regardless of where we all are."

After 48 weeks of doing SCRUM, with the number of teams growing from 1 to 6 and trying out different implementations, we now face a new, interesting challenge. Our 5th and 6th SCRUM teams have started in... Chine and India.


So, here it is: "One of the biggest mantras for Agile teams is that you have to be co-located.  If you are not co-located, you are not going to be highly performant." (Julie LeMoine, the Fidelity Center for Applied Technology) That's the thing. Everybody, at least in our situation, beleives that one of the biggest benefits is that all team members and teams are at walking distance. Most of them even at pebble throwing distance. And they also agree that most of the problems we face are communication problems with people who are further away then the earlier mentioned.


So how are we going to handle two teams in another part of the world, are we going to share the backlog? Do we instate another product owner? Are they actually working on another product? How do we do shared meetings when we are in different time zones, e.g. for our daily stand up?


Of course there are theories and people who have thought about issues like these, but like always, one also needs to regard the issues of the specific company. And what the possibilities we have to change things. So I'll be probably reading the books below, but also start a discussion, maybe just a theoretic one, with some people and see how we get all advantages there are out of it.


I would be very interested in your opinion and experiences on this, and maybe communicate with the collegues in China and India on a more regular basis, to see what happens from your perspective.


These might be interesting to read:

• A Practical Guide to Distributed Scrum
• The Black Book of Agile Project Delivery with Distributed Teams
• Distributed Agile: DH2A - The Proven Agile Software Development Approach and Toolkit for Geographically Dispersed Teams