Anyone working in the agile environment would agree there are a million different terms to wrap your head around. As a marketer with no agile or software development experience, this is definitely true for me. Once you comprehend the definition, you are then tasked with understanding the role each play in the development life cycle and how they integrate with the associated agile methodology 🤯
In an attempt to alleviate any confusion, It's only fitting a couple of those key terms are deciphered … sprints and versions. What teams use them? What are they actually referring to? How do they contribute to the development life cycle?
Before diving into it, it’s important to consider context. Each teams environment will be unique and sprints and versions may be integrated differently. The goal of this blog post is to provide a wholesome understanding of both, in which you can take this information as the foundations for one to build upon, adjust to suit your teams environment and work at a sustainable pace.
Versions in a nutshell
In essence, a version is the culmination of your teams work that you will ship to the customer. It often includes a set of features and fixes that are released together as a single update to your product. Both scrum and kanban teams can work in versions.
Versions and releases are often used interchangeably, and look to a specific point in time or a milestone for your team to work towards. In Jira, working in versions assists the team with organising issues. We can consider a version as a container of issues that have all been stamped with a customer release number. The version or release is the result of what your team has been working on. It’s at this stage the latest version is ready to be shipped.
Sprints in a nutshell
At the core a sprint is a fixed block of time. During which development teams aim to implement and deliver improvements or a new feature for a product. More holistically, you might consider a sprint as a type of cadence for how your team works. Scrum teams work in sprints, whereas kanban teams do not. A sprint caters for fixed timeframes which work well in scrum, kanban calls for the team to adopt a more continuous flow of work hence sprints are not typically followed.
In Jira, the work you complete during a sprint comes from your backlog. Once you have filled your sprint with issues or stories to action, your team can now start working. At the end of the sprint the idea is to have a working component of the product. Working in sprints give your team the chance to organise your workload into smaller more manageable chunks of work. You may choose to move the issues you have worked on during a sprint to the version you will ship to the customer.
It often helps to seperate sprints and versions by considering the motive. Sprints focus on the internal work to be completed and a version as the external outputs that the customer will receive.The main difference is to consider sprints as time-boxes and versions as a specific point in time.
Versions are more customer focused, where as sprints are more specific to the teams capacity. In Jira, when selecting the issues from your backlog a scrum team will prioritise issues into sprints and a kanban team will always take the top item and work towards the version.
Some teams may organise sprints around completing work for a specific version. For example, a scrum team might complete four sprints before the output reaches the version, where as a kanban team adopts a less structured way of working towards the latest release.
For the most part, the principle of both sprints and versions in Jira is to allow your team to filter your stories and issues in a way that prioritises the work to optimise delivery and improve efficiency. One of the many benefits of working in an agile team is the chance to acknowledge what’s working and how to improve it in the future. So whilst sprints or versions work for you now, it might not always be the case.
Make of that what you will, and consider how the framework of sprints and versions will work best in your environment to create your own teams methodology. As a way to filter your teams focus and prioritise your backlog into sprints or versions, consider Easy Agile’s User Story Maps for Jira.
Check out our blog to find out more!