Dev team velocity vs Scrum team velocity

 I have been exploring the concept of velocity, which is typically calculated based on the number of story points burned during previous sprints

Velocity is sometimes corrupted and delivery undermined that way, yes. 

story points can only be burned when a user story is marked as DONE

Velocity is the rate at which work is Done. Story points, as a means of estimation, are quite incombustible and cannot burn. There is an estimate of work remaining.

Considering that the DoD encompasses the PO's validation

In Scrum the PO doesn't validate a damned thing about Done, unless he or she is also one of the Developers. It is the Developers who are accountable for assuring the quality of the Increment. If the PO's benediction or blessing is required, something's gone wrong, and the Developers accountability is not being respected.

Velocity is speed at which scrum team as a whole is able to complete their done. It neither just depend on story points nor on developers.

PO is responsible for ensuring the backlog items are as clear as possible such that developers can realize it in MVPs or increments in a Sprint. Post sprint planning and goal commitment, even PO is not allowed to modify/alter sprint backlog. Sprint backlog belongs to development team and hence sprint velocity is wholly dependent on them.

Ideally it also means, developers have made the PBI to 'done' state and hence velocity will be measured against development team.

As per Scrum principles, story points can only be burned when a user story is marked as DONE, and this DONE state should align with the Definition of Done (DoD). Ideally, the DoD includes validation by the Product Owner (PO).

I'm not sure where you have been doing your research but none of this is mentioned in the Scrum Guide.  In fact, the words "story points" do not appear at all in the guide.  As @Ian points out, you are reading a lot of info that has caused many problems with understanding Scrum.

@Ian's definition of velocity is very good.  Since velocity is a measurement of speed why would you consider using Story Points as it's basis. Story Points are a relative estimate (i.e. guess) based upon information known at the time that the estimate is made.  That has nothing to do with the rate that the work is completed. Consider using flow metrics like throughput or cycle time as they measure actual durations for the work.

I am not sure why the Definition of Done needs to include validation by the Product Owner.  If the Product Owner has done their job of communicating the need, all quality measures should be known by the Developers.  If the Product Owner trusts the Developers to do their job, as the Developers trusts the Product Owner to do theirs, then if the Developers say the need has been satisfied and the increment is done, that should be enough.

If you were to use flow metrics, you could encompass the entire team's efforts.  For example, Lead Time measures the time from inception to completion.  This would start at the time the item was first introduced to the Product Backlog through completion.  You would be including all the time the item was refined, the time it sat waiting to be introduced into a Sprint, the time it takes to develop the solution.  Notice that I said "completion" not "done".  Completion can be what you want it to be.  Is it meeting the definition of done?  Is it available for users?  That is entirely up to you to decide. 

Hello everyone,

Thank you all for your responses.

@Daniel, you are correct that I should not have mentioned "Scrum Principles" since it is not explicitly stated in the Scrum Guide. It was more of an observation based on numerous articles and forum discussions I have come across on this topic.

I find it odd that the Product Owner's intervention in the DoD is not necessary. I have encountered many instances where this is the case or read articles that confirm this. You can find an example among many others in this article.

Additionally, during the sprint review, it is expected that the Scrum team presents the work accomplished to stakeholders. Considering that the presentation can be done by the Product Owner, it raises the question of how he/she can showcase functionalities that have not been validated by him/her beforehand.

I am not sure why the Definition of Done needs to include validation by the Product Owner.  If the Product Owner has done their job of communicating the need, all quality measures should be known by the Developers.

I agree on this point but between knowing the guidelines and actually applying them...

Burn-down chart represents the remaining work effort, considering both time and stories that still need to be completed (i.e., those with unburned points when story points are used for estimating user stories), it becomes unclear why story points would be quite incombustible and cannot burn. Is Jira (Atlassian) wrong about this?

I believe that focusing more on the velocity of the entire Scrum team rather than solely the developers might provide a clearer understanding. It feels quite confusing at the moment to determine the true best practice, especially when the Scrum Guide itself does not explicitly specify it.

Once again, I appreciate your insights and thoughts on this matter.

Velocity is the INTERNAL business of each Scrum team. Like family affair is internal matter of the family.

Only output of the scrum team which indicates its failure or success is a value which driven by increment. Scrum team defines if value is monetary or else, but it should be clearly defined...

Although story points are not mentioned in the scrum guide, it is not unreasonable to use the DoD to determine if an item is done. Then on completion of an item all the story points are reduced. It is all or nothing, not partial points.. This possible more discussed in the Agile literature.

We only take items into account that enters the sprint backlog, and mark it as done when the dev team is done. Additional release testing and verification is outside the dev team. Also velocity is just a rough guide for us, to determine how much to pull in in sprint planning.

Your example is where the PO validates. I agree that "gate keepers" should be limited, maybe something to discuss with the PO. Then again probably not uncommon, but can that not be done in the sprint review, and validate the items in the current sprint? This way the PO validation is not holding the process up. 

Apologies not trying to make a long story..

In short I think the concern is the velocity calculations are being made to complex  Don't overthink it. Velocity is only a rough estimate to gauge how much can be done in a sprint. 

Try reduce gate keeping. Empower the dev team.and let them take accountability.

Salut, Pierre

It is important to note that the Definition of Done is one of the three commitments that must be made to the three Scrum artefacts, specifically to increment. This means that having the DoD in your roadmap after Sprint planning is a MUST (it was a must from the beginning of Scrum, but now it is a part of the artefacts, which changed many things about Scrum radically).

Additionally, the explanation of how an increment is created has been clarified. The moment when PBI fulfills DoD, an increment is born, without the need for further human intervention, contrary to earlier misconceptions that the product owner or the scrum team might accept or reject an increment.

It's interesting that Jira, which is generally built around 2017 version has a option for story points but no special option for DoD - you can write it in when you creating an issue

In fact, the Scrum Guide makes indirect references to story points, along with any other Scrum tools and artifacts.

Permit me to cite, please:

"Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making."

@Nicholas

In fact, the Scrum Guide makes indirect references to story points, along with any other Scrum tools and artifacts.

The reference you made is not specific to Story Points.  A burn-down, burn-up chart can be done by number of items and not the estimated relative number that was made up by the Developers.  The "burn" charts are actually graphical representations of work that is left to be done.  Since Story Points are estimates and not actual work, "burning" those are not realistic.  However, "burning" an actual work item makes sense if that item has been completed.  Cumulative flow diagrams also represent the body of work as it exists in various states.  It would be interesting to know how you would split Story Points into the various stages of work to create a cumulative flow diagram for that.  It is very easy to create one based upon the Sprint Backlog Item if you have your workflow defined.

@Sacha

The article that you referenced as an example of the Definition of Done is full of misconceived patterns.  The Scrum Guide states this about the Definition of Done

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

Your article says this

The definition of done (DoD) is when all conditions, or acceptance criteria, that a software product must satisfy are met and ready to be accepted by a user, customer, team, or consuming system.  We must meet the definition of done to ensure quality.  It lowers rework, by preventing user stories that don’t meet the definition from being promoted to higher level environments. It will prevent features that don’t meet the definition from being delivered to the customer or user.

Notice that the Scrum Guide uses the Definition of Done as a measurement of the Increment, your articles uses it as a measurement of release.  There is a difference.  Not all increments have to be released. 

Your article also references User Stories and Epics as if they are required.  They are not.  In fact, the Scrum Guide goes to lengths not to define how a Product Backlog Item is to be structured.  

The article also describes multiple "types" of Definitions of Done (User Story, Feature, Epic).  While some teams will create various levels of the Definition of Done, that is their choice.  The Scrum Guide states that the Definition of Done exists for the increment. It is the commitment made by the Scrum Team to validate the readiness of the increment, not individual Product/Sprint Backlog Items. 

One thing that I recommend is that you first learn the Scrum Guide and the definitions that are presented there.  Remember that Scrum is a framework not a process or methodology.  The processes that the organization wants to put in place are entirely up to them.  However, one of the Scrum Master's responsibilities is to help the organization understand the framework and how it will benefit the ability to react to change.  They should help organizations realize if their processes impact the framework's benefits adversely.  Many of the articles you will find online are presenting Scrum as a process, methodology, or (even worse) a commercialized implementation of things that will allow them to make money through the sale of a product or services. Jira is an example of that.  Jira was not created as a Scrum tool. It was created as a service ticketing tool but they saw an opportunity to "cash in" on the Agile movement.  

Scrum is not Agile.  Scrum is agile.  The difference between the "A" and "a" is that Agile is a mechanism to commercialize the Manifesto for agile software delivery.  While agile is the ability to move quickly.  The Manifesto was created to provide some values and principles that would enable organizations to adapt quickly and easier to changes in software requirements and economic direction. As a framework, Scrum provides a structure to support building upon.  For example, a house will have a framework that supports the walls, roof, flooring, etc. The framework provides boundaries for the space. However, the framework doesn't define the type of space that is created. A square space could be a bedroom, a storage space, an office, a playroom or many more options.