Skip to main content

Are external approvals part of "done"?

Last post 08:19 pm April 15, 2021 by Daniel Wilhite
4 replies
11:54 pm April 14, 2021

Hi folks,

Our developers write release notes as part of our work, and these release notes then are sent to another (non scrum) team for approval. My question is where does our scrum work finish? Once we've completed the doco and sent it off, does that = Done?



Or do we wait to gain approval, which we're not responsible for, and which the waiting leads to several scrum backlog items sitting as not-done at by the end of the sprint?

Thanks!


06:19 pm April 15, 2021

It all depends on what your agreed upon DoD states. 

If it says that release notes need to be created and approved, then yes, the PBI will not be Done until approval has been received. 

If the DoD only says that the release notes need to be created, then Done has been achieved without approval. 

As the Developers are supposed to have all the skills necessary to create a Done increment, why is the approver not part of the team instead of being an impediment? 


07:10 pm April 15, 2021

My question is where does our scrum work finish? Once we've completed the doco and sent it off, does that = Done?

Would it be fit for use without that "approval"? It doesn't sound like it, in which case the work cannot yet be said to be Done.

What you've highlighted is an organizational impediment to agile practice. The team do not have all of the skills, competencies, and/or authorizations that are needed to genuinely finish work. They cannot therefore be expected to frame a commitment around doing so, and the outcomes one might expect from Scrum will not be forthcoming. Perhaps the right thing to do is to shine a light on the problem so it can then be challenged.


07:42 pm April 15, 2021

There are a few points to consider here.

What it means for work to be done is defined by the team's (or the organization's) Definition of Done. If the Definition of Done says that the release notes must be approved by another team, then the work is not done until it's approved by another team. The Definition of Done is one of the artifacts that helps promote visibility and transparency - when the team communicates the state of work (especially when saying that work is done), everyone knows that it conforms to the Definition of Done.

The real question, though, is if this makes sense. One of the key aspects of Scrum is a Scrum Team that "the members have all the skills necessary to create value each Sprint". It seems like this does not hold for this particular Scrum Team. However, there may be good reasons to have the work done reviewed and approved by another team. For example, it may not be feasible to put a legal or regulatory expert on every team, so something may need to be passed to a legal department for review and approval.

Since there are cases where the team may need to hand off work to an external entity, my preference is to remove that external team from the Definition of Done and do what is necessary to maximize the ability of the team to produce work that will pass this approval process. The need for rework should be a rare occurrence, and cases of rework can be treated as seriously as a defect in the product as found by an end user.


08:19 pm April 15, 2021

Why can't the release notes be done incrementally throughout the Sprint with multiple delivery/feedback/update loops? 

As everyone has says, this boils down to the Definition of Done.  If there is an organizational requirement that release notes be approved by another entity, that would be an organizational Definition of Done requirement. And as such the organization has to make it possible for every Scrum Team to be successful given the limitations.

I am curious though.  What other team has enough insight into the actual work done that they can approve the release notes?  Is this approval for content? Grammar?  Legal restrictions? And if so, why can't the other team do the work to modify the release notes with input from your developers?  In that scenario, your team's commitment is to provide an accurate description of all work undertaken.  After providing that, they would become stakeholders in the other team's work and be done with the work they are held accountable for delivering.


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.