Velocity
Submitted
Scrum Inc.
, Dec 10 2012 11:42 PM | Last updated May 18 2013 03:59 PM
Related Articles
-
Scrum: The Future of Work
06 May 2013 -
A3 Process
21 Apr 2013 -
Leadership in Scrum
16 Feb 2013 -
Origins of Scrum
16 Feb 2013 -
Scrum Flow
13 Feb 2013
Similar Blog Entries
-
Good article by Linda Rising on S...
Jun 04 2002 08:50 AM
Rising, Linda. Agile Meetings. STQE Magazine, May/Jun 2002.<p>... -
Rugby, Anyone?
Jul 09 2002 09:13 AM
Scrum is a good alternative for flexible programming that turns around a... -
Taking Programming to the Extreme
Jul 23 2002 10:33 AM
By Erik Sherman July 19, 2002“The quest for... -
SCRUM vs. Waterfall: Point and Co...
Sep 15 2002 08:41 PM
Note: CMM is a service mark of the Software Engineering Institute at Car... -
Agile User Groups
Sep 26 2002 03:36 PM
There are user groups springing up around the Agile Alliance focused on...
Velocity is a measure of the amount of work a Team can tackle during a single Sprint, and is one of the key Metrics in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories. Points from partially-completed or incomplete stories should not be counted in calculating Velocity. Velocity should be tracked throughout the Sprint on the Sprint Burndown Chart and be made visible to all Team members. The slides on the left give a nice overview of how the Metrics are made visible.
Velocity is a key feedback mechanism for the Team. It helps them measure whether process changes they make are improving their productivity or hurting it. While a Team's velocity will oscillate up and down from Sprint to Sprint, over time a well-functioning Scrum Team's Velocity should steadily trend upward by roughly 10% each Sprint.
Velocity also facilitates very accurate forecasting of how many stories a Team can do in a Sprint. (In Scrum this is called using Yesterday’s Weather.) For forecasting purposes the average of the last three Sprint's Velocity should be used. Of course, this means it takes three Sprints of experience for a Team to determine its Velocity accurately, which can sometimes be difficult to explain to impatient stakeholders.
Without Velocity, Release Planning is impossible. By knowing Velocity, a Product Owner can figure out how many Sprints it will take the Team to achieve a desired level of functionality that can then be shipped. Depending on the length of the Sprint, the Product owner can fix a date for the release.
Velocity is a key feedback mechanism for the Team. It helps them measure whether process changes they make are improving their productivity or hurting it. While a Team's velocity will oscillate up and down from Sprint to Sprint, over time a well-functioning Scrum Team's Velocity should steadily trend upward by roughly 10% each Sprint.
Velocity also facilitates very accurate forecasting of how many stories a Team can do in a Sprint. (In Scrum this is called using Yesterday’s Weather.) For forecasting purposes the average of the last three Sprint's Velocity should be used. Of course, this means it takes three Sprints of experience for a Team to determine its Velocity accurately, which can sometimes be difficult to explain to impatient stakeholders.
Without Velocity, Release Planning is impossible. By knowing Velocity, a Product Owner can figure out how many Sprints it will take the Team to achieve a desired level of functionality that can then be shipped. Depending on the length of the Sprint, the Product owner can fix a date for the release.
