What if the Scrum Team Fulfills the Sprint Goal Before the End of the Sprint?
Fleeting- External reference: https://pm.stackexchange.com/questions/27888/what-to-do-when-theres-not-enough-work-related-to-the-sprint-goal
Some common misconceptions about scrum, suggesting that the sprint should optimize the amount of work instead of reaching the agreed outcome that was meant to optimize the value.
what if the scrum team fulfills the spring goal before the end of the sprint?
As long as it is the most valuable thing to be done and that the sprint is short enough, that should be ok1, shouldn’t it? If there is bonus work that can be achieved during that iteration, that’s for the better2, 3.
If the developers fulfil the sprint goal before the end of the sprint or think they finally won’t be able to make it by the end of the sprint, they have to renegotiate the scope of the sprint goal to have one that fits. This means that most of the first sprints will end with discussions with the product owner to adjust the scope until the team finds its velocity.
Also, it may be the symptom of the misconception that the sprint goal is about a bunch of work, not the outcome4. Remember that the goal is a tool to help people focus5, 6 towards a common objective (a.k.a. behave as a team).
If the “goal” does not fulfil its purpose, the team should adapt7.
finding a Sprint Goal to a diverse team
-
External reference: https://www.scrum.org/forum/scrum-forum/40788/finding-sprint-goal-diverse-team Finding a Sprint Goal to a diverse team
The case that the team works on separate issues on totally different technologies8 does not change the fact that they can agree on an outcome that should be reached by the end of the current sprint9. Whatever is done should make sure it does not jeopardize that.
being committed towards the sprint goal does not necessarily mean always working towards it
Also, the sprint goal is said to be a commitment to be done by the end of the sprint, but not at all that the sprint goal should be the only thing on what we work. If the team finishes the goal early, then can work on something else, provided that it is the next action that is the most valuable (the product owner’s role is to help assessing this). The only thing that changes is that the team is not committed to end this by the end of the sprint.
If that happens to often, the team should realize this and adapt by adjusting some parameter, like the sprint size, the way the goals are defined or estimated, the definition of done,….
Also, even if the scrum team is cross-functional, that does not mean that everyone can work on the sprint goal at any point in time. It makes sense them to let team members that cannot work towards the sprint goal work on the next most important things that they can move forward. The only imperative of the method is to have the whole team committed towards the sprint goal. That means that in at some point, the developers that could not contribute can contribute, then they should fill the duty to let their work behind to focus on the sprint goal. Also, they have the duty to still feel concerned about this goal and react whenever they realize they have some important information that would help.
Tools like jira help with this, as one can put some tickets into the “jira sprint”. As long as the team always focus on the sprint goal, they should be able to now what tickets are needed to be done by the end of the sprint to fulfil the goal and what are only meant to still have work to do when one cannot contribute to the sprint goal. Also, the “jira sprint” can be adjusted at will, as long as the team always keep in mind the sprint goal to fulfil. We could even imagine that all the tickets of the “jira sprint” could be dropped and a bunch of new ones are added, as long as the scrum team feels confident that the sprint goal is still to be achieved.
Notes linking here
Permalink
-
↩︎if “the most important business goal” is being routinely met each iteration, why does it matter that the Sprint isn’t being packed to the brim
[…]
Assuming that your Sprint length and goal selection processes are already optimal
-
↩︎not necessary for all work selected for a Sprint to be aligned with the Sprint Goal.
[…]
If the Development Team is aware of what work is directly supporting the Sprint Goal and what work isn’t, it gives them flexibility to self-organize and self-manage toward achieving the goal
-
↩︎the slack time afforded by a sprint whose goal was completed early is a blessing for you and your team. Use this time to scaffold, or adapt to environmental change, or react to changes by external actors (like making your build system more resilient to NPM outages if you run a node.js stack, for instance), or to refactor or improve the maintainability of your system.
-
↩︎your sprints are work-focused, not increment-focused. A lot of teams make this mistake
[…]
They load up the sprint with work tasks, then try to form a sprint goal. In all fairness,
-
↩︎Some teams may drift a little during a sprint if they do not have a clear focus and an understanding of the value the sprint delivers. The sprint goal helps teams to avoid this
-
↩︎Sprint Goal is a focusing tool for the Development Team
-
↩︎If, however, the team is experiencing the problems that the sprint goal were intended to prevent then you need to consider adapting your process
-
#+BEGIN_QUOTE the UX/UI is working on features that will go into development in 2-3 Sprints. And the Automation engineer is working on features that have been developed half a year ago ↩︎
-
↩︎If you were using Scrum, then the entire team would be working on the same bodies of work that would deliver a potentially releasable increment of value at the end of the Sprint.
— https://www.scrum.org/forum/scrum-forum/40788/finding-sprint-goal-diverse-team