Skip to main content

Transparency or Trouble ?

Last post 02:32 pm August 12, 2021 by Thomas Owens
3 replies
01:07 pm August 12, 2021

During the sprint review, The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

It is known that the team demonstrate/review the outcome only the 'Done' stories and see if the sprint goal is met. If some of the stories are not done then sprint goal is considered not met? In this case we should be highlighting this to stakeholders for transparency ? or will it become trouble for the scrum team as they get lot of questions for not achieving the goal ?


01:14 pm August 12, 2021

The sprint goal is reviewed during each Daily Scrum, and not just at Sprint Review.  Any PBI that has not met the DoD should not be included in the increment, and should be reviewed and put back into the PB for possible later selection in future sprints. 

If the Developers determine that a PBI cannot be completed during the sprint, and that this would result in the sprint goal no longer being met (SG should be aligned with the PG), then they should renegotiate the sprint scope with the PO.  If the PO determines that the sprint is no longer caüable of achieving the SG, then the PO can cancel the sprint so that the Scrum Team can then start Sprint Planning for the next sprint.


01:22 pm August 12, 2021

If some of the stories are not done then sprint goal is considered not met?

Why? Why would the team fill their Sprint Backlog with requirements that are essential to achieving the Sprint Goal, knowing that the goal is their commitment, and if they dropped even one thing they'd fail to meet it?

Wouldn't it be better to control Sprint Goal risk, under complex and uncertain conditions, by allowing for some contingency and flexibility in planned scope?


02:32 pm August 12, 2021

If some of the stories are not done then sprint goal is considered not met?

Just because some Product Backlog Items aren't Done doesn't necessarily mean that the Sprint Goal hasn't been met. Depending on what the Sprint Goal is and what Product Backlog Items were selected for the Sprint, it could be possible to achieve the Sprint Goal by only completing a subset of the Product Backlog Items. Personally, I encourage teams to align their Sprint Goal with a subset of the Product Backlog. Being able to regularly make and achieve goals is more important than completing the body of work.

In this case we should be highlighting this to stakeholders for transparency ? or will it become trouble for the scrum team as they get lot of questions for not achieving the goal ?

If you fail to achieve the Sprint Goal, this should absolutely come out at the Sprint Review. However, it shouldn't be "trouble" if the Scrum Team doesn't achieve its goal. That happens sometimes. I would see a problem if the Scrum Team frequently or regularly doesn't achieve their Sprint Goal. If the Sprint Goal isn't achieved, the Scrum Team should use their Sprint Retrospective to figure out what went wrong and how to fix it for the next (and future) Sprints.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.