Agile teams who start their Agile journey in Scrum quickly learn something called story pointing, and how to use it to enhance their predictability. (Hopefully they also learn to avoid trying to leverage story pointing to understand productivity, but that’s a separate story.) Anyway, there are many internet references to story pointing. Pointing is a clever way to avoid the need to make all the stories in our backlog roughly the same size prior to implementation.
When the team is also developing on a static cadence, say a “sprint” length of two weeks, then we can call out a set of stories, put them “in” our sprint backlog to be done in this sprint, add together their story points, and call that our forecast, say 40 points. It used to be called commitment and I still think that’s a good name: we commit to the Business that we’ll do everything we can to make our forecast. We can do that because we’ve established historical perspective that tells us we are consistently able to complete that many story points in every sprint. Jira (among many tools) shows us this in the Velocity Chart report.
Velocity, then, is about a forecast over a static time period. However Kanban teams are among those who don’t “sprint”; they don’t develop on cadence. They do demonstration and review on demand, and to establish predictable behavior they consider flow instead of velocity. They have more work to do on their stories: instead of pointing them, a Kanban team needs to split their stories until all the stories they develop and deliver are about the same size. When that is true and if we are on a cadence, we could switch our units of velocity from story points per sprint to stories per sprint and it wouldn’t matter much. When we are not on a cadence as on a Kanban team, we think about flow instead, or the average time to complete a story once it is selected for development; this is called Cycle time. (Separately we can have a discussion about the related measure, Lead time.) Note that Cycle time and Velocity are inversely proportional to each other if both are being measured with the same units (either stories, or story points). Example using stories:
Let Velocity be the average stories per sprint
Let Flow be average days to complete a story
then Velocity = L / Flow
where L = sprint length in days
If we are using story points rather than stories, and not trying to get all our stories to be about the same size, Jira only helps us if we are on cadence, ie sprinting. Jira does not measure cycle time for story points, only for stories, so a story point-based cycle time must be calculated manually. That being the case, we discourage story pointing unless our squad is sprinting. Instead we encourage splitting our stories until all the stories we select for development are of similar size.
Cadence, such as the sprints in Scrum, is very useful. Teams typically thrive on the rhythm and story pointing is not difficult (at least, not once you “get it” – yet another separate story!). Kanban teams have more flexibility but as is so often the case, it’s a trade off: more discipline in story splitting is needed to be successful.