Sprint Case: Interpretation of "No changes are made that would endanger the Sprint Goal"

Martinus,

There are many options to address extra Development Team member capacity within the sprint. One option is to accept additional stories into the sprint that meet the Definition of Ready and are agreed to by the Product Owner.

As you stated, the Sprint Goal has been met, so this option does not place the Sprint Goal at risk.

However, another option is to seek ways to contribute to other sprint work that is in progress. Remember, the Development Team accepted the PBI's that are now in the Sprint Backlog, and they forecasted completion of those items by the end of the sprint.

Another option is learning. If a Development Team member has capacity, what better time to seek ways to gain additional knowledge and expertise so that the member can become more valuable to the team and the organization in the future?

Another option is to seek ways to improve the productivity of the team. Identifying and reducing technical debt, refactoring, improving testing and delivery practices (Test-driven development, Continuous Integration, Continuous Deployment, etc).


To directly respond to your question though, selecting another PBI for the sprint is acceptable by Scrum provided it does not jeopardize the Sprint Goal. It is advisable to consult with the Product Owner beforehand, though (openness, transparency).

All of the selected Product Backlog items have been Done, there should be no reason for the Sprint Goal to be endangered. As Mr. Baffa indicated above, it is completely acceptable to add another item from the Product Backlog . . . preferably through coordination with the Product Owner.

I also appreciate his inclusion other valuable uses of the unexpected capacity. Another great use of this time may be Product Backlog refinement. Perhaps a team celebration on its achievements; not just for the early finish but for all efforts, would be an option. The caution is that weak forecasts should not become the norm for Sprint execution. Inspect and adapt.

I will give you short answers (it's just my opinion),

Usually we will pick another top backlog. In this case, if I pick another backlog, the backlog is not relate to our sprint goal. May I do this?

Yes, you can.

From my opinion, the sprint goal is not endanger, it is already finished. However, if this unrelated backlog added to my sprint, do we the scrum team need to revise our sprint goal?

No, you don't need. Go behond the expectations is rarely a problem ;)

The DT could think how to improve the Increment, both technically and functionally, that is including more stringent criteria for highger quality or re-negotize with the PO the scope to generate more value.

re-negotize with the PO the scope to generate more value.

Product Backlog refinement

a team celebration on its achievements

All are additionally excellent ideas for using excess team capacity. And as Alan stated, the team should review the reasons around excess capacity, especially if it no longer seems to be an exception.

> The DT could think how to improve the Increment, both technically and
> functionally, that is including more stringent criteria for highger quality

This is an important option which, if anything, should be preferred to the bringing forward of work. Wherever there is capacity, it is generally best to use it to improve quality rather than velocity or throughput. So take a look at raising the team's game, such as by bettering the Definition of Done.

Wow, I got some unexpected input. I think my fellow team mates like the idea to find way for improvement.

Actually me and the product owner think some of my fellow team think to complicated for a product backlog, sometimes adding more not needed additional requirement yet into our product backlog. Fortunately, the PO able to see this and show the team that he is okay with requirement already in the backlog.

This made the initial forecast is inflated too much.

Now, I understand why the DoD become tool to asses the effort of backlog.

Thanks everyone.