A glossary of terms used by Agile Sprints.
A Key Performance Indicator is a measurable value that demonstrates how effectively a company is achieving key business objectives. Organizations use KPIs at multiple levels to evaluate their success at reaching targets. High-level KPIs may focus on the overall performance of the business, while low-level KPIs may focus on processes in departments such as sales, marketing, HR, support, and others.
A KPI must be SMART:
- Specific: What exactly do you want to achieve?
- Measurable: How will you identify that you have achieved your goal?
- Achievable: Is your goal really attainable?
- Relevant: Is it relevant to you or, in other words, does it align with where you want to be?
- Time-bound (or timely): When will you deliver your goal, and what are the key milestones?
Objectives and Key Results is a collaborative goal-setting tool used by teams and individuals to set challenging, ambitious goals with measurable results. OKRs are how you track progress, create alignment, and encourage engagement around measurable goals.
An Objective is simply what is to be achieved, no more and no less. By definition, objectives are significant, concrete, action-oriented, and (ideally) inspirational. When properly designed and deployed, they’re a vaccine against fuzzy thinking—and fuzzy execution.
Key Results benchmark and monitor how we get to the objective. Effective KRs are specific and time-bound, aggressive yet realistic. Most of all, they are measurable and verifiable. You either meet a key result’s requirements or you don’t; there is no gray area, no room for doubt. At the end of the designated period, typically a quarter, we do a regular check and grade the key results as fulfilled or not.
The agile methodology is a practice that promotes continuous iteration of development and testing throughout the software development lifecycle of the project. In the Agile model, both development and testing activities are concurrent, unlike the Waterfall model.
It was popularized by the Manifesto for Agile Software Development. The values and principles espoused in this manifesto were derived from and underpin a broad range of software development frameworks, including Scrum and Kanban.
The principles of agile methodology are:
- Customer satisfaction
- Adapt to changes
- Deliver working software frequently
- Business people and developers must work together throughout the project
- Build projects around motivated individuals
- Adopt face-to-face conversation
- Working software is the primary measure of progress
- The sponsors, developers, and users should be able to maintain a constant pace indefinitely
- Continuous attention to technical excellence and good design enhances agility
- Simplicity--the art of maximizing the amount of work not done--is essential
- The best architectures, requirements, and designs emerge from self-organizing teams
- At regular intervals, the team reflects on how to become more effective
Scrum is an agile project management methodology or framework used primarily for software development projects with the goal of delivering new software capability every 2-4 weeks. It is one of the approaches that influenced the Agile Manifesto, which articulates a set of values and principles to guide decisions on how to develop higher-quality software faster. Scrum is widely used by software development teams. In fact, it's the most popular agile methodology. According to the 12th annual State of Agile report, 70% of software teams use Scrum or a Scrum hybrid. However, Scrum has spread to other business functions including IT and marketing where there are projects that must move forward in the presence of complexity and ambiguity. Leadership teams are also basing their agile management practices on Scrum, often combining it with lean and Kanban practices (subgroups of agile project management).
A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work. Sprints are at the very heart of scrum and agile methodologies, and getting sprints right will help your agile team ship better software with fewer headaches. “With Scrum, a product is built in a series of iterations called sprints that break down big, complex projects into bite-sized pieces," said Megan Cook, Group Product Manager for Jira Software at Atlassian.
Velocity is the master KPI you should look at. It is a measure of the amount of work your team can tackle during a single sprint and is the key metric in Scrum. How fast are we going is the question. It is a compound indicator of 5 different variables that are (n) number of commits, (e) edition, (t) number of merged tickets, (p) merged tickets average lead time, (r) average time to review. The computation is: velocity = n * e * t / (1000 * p * r).
Augmenting the teams' velocity should be your goal as a manager. To do so, you have to identify the pain points in your organization such as stale tickets and lack of reviews.
In the future, we will offer tooling and learning to augment your velocity.
In agile development, a feature is a chunk of functionality that delivers business value. Features can include additions or changes to existing functionality. For planning purposes, some agile methodologies also use the notion of "work items" that can include features, bug fixes, documents, and other artifacts
A feature should:
- Provide business value
- Be estimable
- Be small enough to fit within an iteration
- Be testable
Using Lines Of Code as a metric is meaningful on large scales only. So using it project-wise makes sense. Comparing LOCs produced per developer is pointless since their work may differ qualitatively. But comparing the evolution of LOCs sprints-wise gives a macroscopic view of your progress.
Remember to exclude large autogenerated files from the analysis by setting the exclusion patterns in our app.
Similar to saving a file that's been edited, a commit records changes to one or more files in your project. A commit identifies:
- The specific changes
- When the changes were made
- Who created the changes
When you make a commit, you must include a commit message that briefly describes the changes. You can also add a co-author on any commits you collaborate on.
Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.
They should correspond to the tickets you opened. A ticket can typically either tackle a new feature, a bug, or a chore.
Reviews allow others to comment on the changes proposed in pull requests, approve the changes, or request further changes before the pull request is merged. It is an incremental process that delivers value to your business by requiring the input of others on one's work.
The review turnaround is how much time has passed between the opening of the ticket or the previous review of the same author and the review. A large turnaround can mean that the ticket stales or is abandoned. You should aim for the quickest turnaround possible to increase your velocity.
Tags or Releases are deployable software iterations you can package and make available for a wider audience to download and use. They often have a name such as "v1.0.0" or "v3.2.1-beta".