Question (who tracks the velocity )?

Who is interested in the velocity and why?

> Who is actualy responsible to register velocity of team , for example in a ALM tool? 

If this information is of use to the Scrum Team, then the first team member who sees it needs updating should do so.

Hi Mehdi,
nobody is responsible for this, because it is an administrative task which is not required by SCRUM.
What IS required is that the dev team can forecast what they can achieve during a sprint. If the team thinks past performance is a valuable input for this (It may be that due to rigorous DoD or team changes it is not valuable), they should know their velocity. This is trivial if they use the daily SCRUM to "inspect how progress is trending toward completing the work in the Sprint Backlog" (SCRUM guide), e.g. with a burndown chart.

I also had a bit of difficulty in answering this, the PO uses the velocity information, the scrum master in a way tracks the progress of the dev team during the sprints and then we have the dev team who estimates the work based on their current velocity. So who actually registers the velocity and when? is it done before the sprint planning or at the daily scrums

As per the scrum papers document from Jeff Sutherland, it is done during the daily scrum by the team. However if it is not necessary for the SM and PO to attend, would it be safe to assume that the dev team actually registers the velocity?

@Michelle: Thanks
I understand from previous inputs , each member of Scrum team could update it as needed.
Velocity is the sum of story points that a team can achieve in each sprint , it means it is something that can be updated only once in a sprint, not everyday as you suggest in daily scrum.
For example if dev team pulled 3 user stories from product backlog into sprint backlog, lets say they were estimated in previous refinement meeting with 8, 5, 5 story points . Now on sprint review meeting , if the PO only accept first and second one as done but called third one as not done, the team has done only 8 + 5 = 13 (unit) story points in this sprint. . The average velocity of last few sprints reflects better the performance of team and must be taken into considreation instead of velocity of a single sprint. Mature teams gets after a while more or less constant velocity and that helps PO to forcast how many sprint they might need to finish necessary part of product.

in the Scrum Guide -Sprint-Review part there is following sentence :

The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date (if needed);

I think that is a good candidate for usage of velocity.And PO is a good candidate to track it .

But also retrospective meeting is a good time also for Dev. team to check if they have a constant velocity , and if not to discuss / analyse the root causes.

Mehdi

Thanks Mehdi - Although I am still not 100% confident that the PO is the one who registers the velocity. He/she definately uses it, no doubt there

In the Scrum Papers (by Ken)

The ScrumMaster needs to know what tasks have been completed, what tasks have
started, any new tasks that have been discovered, and any estimates that may have
changed.
...
Burndown Chart
At the Sprint Planning Meeting the Scrum Team identifies and estimates specific tasks that must
be completed for the Sprint to be successful. The total of all Sprint Backlog estimates of work
remaining to be completed is the cumulative backlog. When tasks are completed as the Sprint
proceeds, the ScrumMaster recalculates the remaining work to be done and the Sprint Backlog
decreases, or burns down over time.

Daily Standup Meeting
After the meeting, the team members update the amount of time remaining to complete each of
the tasks that they’ve signed up for on the Sprint Backlog. This information is recorded on a
graph called the Sprint Burndown Chart

...
A well functioning team will dynamically recalculate the
plan daily through a brief discussion and provide enough information for a ScrumMaster, the
team leader, to calculate a “Burndown Chart” of work to be completed

So would this make the Scrum Master who registers the velocity or the Development team who register the velocity?

@Michelle: Thanks

[code]
So would this make the Scrum Master who registers the velocity or the Development team who register the velocity?
[/code]

<u> I see where the mis-understanding comes from. The velocity is not, how fast Dev team finish his current tasks.</u>

what you mentined above is all about current sprint and at the level of Sprint. Normally in this level ,the estimations are also concrete (min., hours, days, ...)

<b> The Dev. Team owns Sprint Backlock and is responsible for that </b> which includes the selected/commited PBIs for the current Sprint plus all relevant Tasks which are needed to do a successful increment. Depending on the DoD, a Sprint Backlog Iteam has normally several related tasks ( Implementing code, Test, documentations,...) .

<b>The updating the status of tasks , remaining effort for the ongoing tasks, sprint burndown chart, ... are only the Dev. Team's job.</b>

BUT
the velocity is measuring at the level of Product Backlog (normally in refinement meetings) and ideally in units (story Points , for example fibonacci series: 1,2,3,5,8,13,...) not concrete effort , the numbers (story points) are just a comparison among PBI and noting to do with how much time exactly required. The advantage of using story points comparing to time effort is that they are independent of Dev. team performance.
Measuring of the velocity is mainly used for forcasting (rough estimation) how many sprint are needed if the team and PBI list remains unchanged for delivering the next release/ full delivery of the product.


Mehdi

Ian got it spot on 23 Apr 2014 08:30 AM
This is a scrum team, consisting of Dev Team, SM, PO one unit, if we use the example "we are a team" none of them are wrong, depends on how responsible or serious the team take it.
The scrum team is responsible if its truly self organizing per scrum, so its in everyone's interest.
Scrum does not say, two roles should not register that information and one must, its a team and if its "SO"
Anyone can "register" that information.

My thought process after a few iterations on this is :
Since this is not a scrum guideline or rule it can be registered by anyone.
Ideally the team can say it will be registered by PO, which is the most sensible approach but since it is not part of the framework, from an exam POV, the right answer seems "no one" to me but can be updated by "anyone".
However the PO should track the performance of the sprints and forecast the possible completion dates but suggested approach is to use the remaining effort rather.
To sum, I am not convinced that anyone is responsible for registering the velocity as per the Scrum guidelines.

As per Scrum Guideline

One of the Inputs for sprint planning:

• The projected capacity of the  sprint planning
• The past performance of the development team 

Who should collect this input  - Scrum Master

Using the projected capacity of the development team, the Scrum Master should calculate the available user story points for the sprint.

Further, make the data:  "user story points" available for the sprint to the PO and Development team as pre-requisite to start the sprint planning part 1.

The user story point is of the input parameter of sprint planning facilitation.

Hi Manjunatha,

'The input to this meeting is the Product Backlog, the latest product Increment, projected

capacity of the Development Team during the Sprint, and past performance of the Development

Team. The number of items selected from the Product Backlog for the Sprint is solely up to the

Development Team. Only the Development Team can assess what it can accomplish over the

upcoming Sprint.'

What do you infer from this paragraph from the Guide?

Using the projected capacity of the development team, the Scrum Master should calculate the available user story points for the sprint.

>> What is meant by the 'available user story points' ?

Regards

Harshal

Who should collect this input  - Scrum Master

Manjunatha, unsure what source you are referring to that states it is the SM responsibility for calculating team capacity and available user story points.   It is not in the Scrum Guide.

According to the Scrum.org glossary the correct answer is the Development Team.

Velocity: an optional, but often used, indication of the average amount of Product Backlog turned into an Increment of product during a Sprint by a Scrum Team, tracked by the Development Team for use within the Scrum Team.

Using the projected capacity of the development team, the Scrum Master should calculate the available user story points for the sprint.

Where in the Scrum Guide does it say anything about "user story points" in regards to capacity for velocity?  And where is the place where it is described that the Scrum Master calculate anything for the Development Team?

As @Chris points out this is solely a Development Team activity because they are the ones responsible for managing their work during a Sprint. 

Can you point us to the source of the information you quoted? I'd really like to read it. 

Using the projected capacity of the development team, the Scrum Master should calculate the available user story points for the sprint.

Might this not be the best way for a Scrum Master to coach the Development Team around self-organization?

I'm very, very late to this party :), but here's my take.



The Scrum Guide 2020 says this:

Developers

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

The specific skills needed by the Developers are often broad and will vary with the domain of work. However, the Developers are always accountable for:

• Creating a plan for the Sprint, the Sprint Backlog;

• Instilling quality by adhering to a Definition of Done;

• Adapting their plan each day toward the Sprint Goal; and,

• Holding each other accountable as professionals.

How I see this is that the Development Team is responsible for the Sprint Backlog. It's in a sense a contract in which they commit to delivering a certain amount of work (in the form of one or more increments). They are responsible for "pulling" work from (the top of) the Product Backlog into the Sprint Backlog. 

This requires the Development Team to be realistic in what they decide to pull into the Sprint Backlog. This in turn requires them to be fully cognizant of their velocity. So how I see it is that the Development Team is the role that HAS to know what the velocity is, because they are the primary role using it in a core responsibility of theirs.



Obviously the Product Owner might utilize knowledge about the velocity to gain a high level idea of when certain features/increments could potentially be delivered. But even that is never a "one man/woman show". When an organization I work for as a PO requires longer term insights / roadmaps etc, I always involve the Development Team in crafting these insights. Because they are the best party to determine how realistic it is to expect something to be ready, even for PBI's further down the line that haven't been fully refined yet.