The definition of an Agile sprint is one that’s pretty straight forward, unlike other parts of the framework that enjoy the occasional debate, such as “Sprint Zero”.
The Scrum Guide describes a Sprint as the “the heart of Scrum” and it is one of the major activities within the Scrum framework.
It is the core of the Scrum framework because time-bound sprint sessions are the only periods in which potentially, useable increments are made to a product.
It is during a sprint that an agreed upon scope of work has to be completed.
This means that upon the conclusion of one sprint, another begins, until the entire software product has been built to the customer’s satisfaction.
At Gunner, we determine how much work can be completed in a single sprint (or iteration) based on the concept of effort points and velocity.
Velocity is how many effort points the entire team can complete in a single sprint.
Effort points are a number closely related to time that are assigned to a given bug, feature, research or chore.
Generally bugs that were created from other tickets have an effort point of 0 because we don't want bugs that we created to inflate our velocity score.
Everything else is estimated.
For example, adding a simple feature to prevent users from entering a "." in their username during signup might be a 1.
A complex feature involving, say, creating and implementing a custom algorithm to rate users might be a 16.
(we use a base-2 sequence: 0, 1, 2, 4, 8, 16, 32 and anything higher than 32 must be broken into multiple issues).
When first starting out, we use the overall Gunner velocity average for the given team size to limit the effort points.
For example, if the average team of three has a velocity of 50, we use that number to determine how many effort points (50) we can put into each iteraction.
After about the third iteration on a project, we settle into a project average which rolls from iteration to iteration.
Bug sprints generally have a velocity of 0 since the entire sprint is focused on fixing bugs.
What can happen in projects is that the velocity seems to greatly exceed the average but that's because development is happening so quickly without testing.
A bug sprint serves to baseline the velocity while also fixing bugs that are creating technical debt.