Background:
As a junior project manager, I have had the opportunity to gain a number of experiences in leading and tracking sprints for my software engineering and marketing teams. Developing a product for your business comes with a lot of moving parts, so it is crucial to know how your team is progressing throughout the sprint process.
If you are new to this whole project management thing like how I was two years ago, no need to worry! I've got you covered in this article with a few basics and then some. After doing some extensive research and based on my personal experiences, I've compiled this guide to a successful sprint and some useful.
Useful Scrum/Agile Terms
Backlog – A prioritized list of items for the product development team to accomplish and deliver. You can use a tool like Jira, tape sticky notes to a whiteboard, or use a spreadsheet in Excel.
Backlog Item/Task – The smallest unit of work that a team member will undertake to complete a story.
Bug – Similar to a story, but distinguished as a correction of unexpected behavior vs. new desired behavior. Typically this is an issue in the code or development that can be fixed in one sprint.
Epic - A large user story that should be broken down into a number of smaller stories. This can take longer than one sprint to complete
Retrospective - A look book over the completed sprint. Questions to ask the team include, what went well, what did not go well, and how can we improve the next sprint. These sessions are typically done after each sprint (two weeks).
Story Points – A number reflecting how big an item is compared to others in the backlog. An item’s size can reflect the relative complexity, the amount of work needed to complete it, and/or any risk factors involved.
User Story – Work that typically gets done in one sprint. This represents a new user-facing feature or functionality that gets delivered in a product release.
Velocity - A measure of the amount of work the team can complete during a single sprint. It is calculated by totaling the points for all completed user stories.
Types of Methodologies
Lean - Focus on ensuring a flow of value from the organization to its customers and eliminating wasteful activities. Common metrics include lead time and cycle time. Best for client facing teams, such as sales.
Kanban - Focus on workflow, organizing, prioritizing work, and simply getting the work done. A common metric is a cumulative flow. Best for marketing teams.
Scrum: Focus on the predictable delivery of working software to customers. The burndown chart and team velocity are common metrics. Best for software development teams.
Why are Metrics Important?
Agile methodologies place a special emphasis on quality because the end goal is to deliver working and bug-free software to customers, so metrics are useful to achieve this goal. From my experiences, tracking team progress is how we continually improve and deliver better products.
Roadmapping
It is a good idea to have metrics rooted into the roadmap, which can be created at the beginning of each quarter. For each initiative on the roadmap, include several key performance indicators (KPIs) that map to the development goals. A great way to measure the success of a feature is to include success criteria in the product requirement documentation, such as adoption rate by end-users or percentage of code covered by automated tests.
Estimating
Estimating allows the team to gauge the amount of time and effort it will talk to complete a story. This also gives a good idea of when the team will be done with important aspects of the planned work.
Some of my favorite methods of estimating include:
Setting an estimation range for stories
Setting some reference points using the Fibonacci scale
Estimating bugs, chores, and spikes
It is important to remember that estimates represent the size of work, not the value. You can use numbers like 2, 5, 8, or 11 as story points for estimates. Expected bugs, chores, and spikes can be estimated since they cost time and money, but if they represent emergent work that must be completed in the current sprint, then they don't need to be estimated.
Now that we have gotten some of the basics out the way, let's get into the metrics. Below are what I consider the top 5 Agile tracking metrics that can be used in almost any sprint process.
Top 5 Charts & Graphs to Track Sprints
Note: These tools are built into Jira by Atlassian
1. Sprint Burndown Chart
What is it?
This is a graphic representation that shows the rate at which work is completed and how much work needs to be done. The chart slopes downward over the Sprint duration and across story points completed.
How do we use it? Jira Tutorial
Scrum teams organize development into time-boxed sprints.
At the start of the sprint, the team forecasts how much work they can complete during the two week period.
Throughout the sprint, a sprint burndown report then tracks the completion of the tasks, The x-axis represents time, and the y-axis refers to the amount of work left to complete, measured in either story points or hours.
The goal is to have all the forecasted work completed by the end of the sprint.
Potential Problems
The team does not commit to enough work and repeatedly finishes each sprint early.
The team commits too much work and misses their forecast every sprint.
The work has not been broken down into granular pieces, which causes the burndown line to make steep drops rather than a more gradual burndown.
The product owner adds or changes the scope in the middle of the sprint.
2. Epic & Release Burndown
What is it?
This report shows you how your team is progressing against the work for an epic. Burndown charts track the progress of development over a larger body of work, rather than the sprint burndown and guide development for both scrum and kanban teams.
How do we use it? - Jira Tutorial
Consider the "Scope Creep", which is the injection of more requirements into a previously-defined project. Sope change within epics are a natural consequence of agile development, but constantly tolerating scope creep can be considered bad practice.
The product owner may decide to take on or remove work based on new information coming down the pipeline, as the team moves through the project.
The epic and release burndown charts can keep the team aware of the work flow inside the epic.
Potential Problems
Epic or release forecasts are not updated as the team powers through the work.
Chronic scope creep, which may be a sign that the product owner does not fully understand the problem that needs to be solved or the needs of the customer.
Scope grows faster than the team can handle during the sprint.
The team does not ship incremental releases throughout the development of an epic.
3. Velocity Chart
What is it?
This is the average amount of work a scrum team completes during a sprint and is measured in either story points or hours, and is very useful for forecasting. The velocity report tracks the forecasted and completed work over several iterations and the more iterations, the more accurate the forecast. As a product owner, you can use velocity to predict how quickly a team can work through the backlog. A decrease in average velocity is usually a sign that some part of the teams' development process has become inefficient and should be brought up at the next retrospective.
How do we use it? - Jira Tutorial
Velocity can be measured in person-hours, number of tasks, t-shirt sizes, story points, or any other unit of measurement can be used for estimating work.
Tally up the number of tasks completed in a day for a sprint week. Jira does this for you.
For example, our team planned to complete 42 story points in our first sprint. We actually completed 29 story points and rolled 13 uncompleted story points over to the next sprint. So our velocity for our first sprint is 29.
We then use 29, to predict the number of story points for the second sprint.
Add the two velocity points from the first and second sprint, and then divide by 2 to get an average velocity. Continue this process for each sprint thereafter by using the number of completed story points for each sprint, add them up, and then divide by the number of sprints completed.
Potential Problems
Velocity charts are the best metrics in my opinion, because they come with the least amount of problems, from my experiences. When velocity is inconsistent over a long period of time, always revisit the team's estimation practices. It might be a good idea to ask the following questions during the team's retrospective:
Are there unforeseen development challenges we didn't account for when estimating this work?
How can we better break down the work to uncover any challenges?
Is the team being pushed beyond their limits due to high-level business pressure?
Is adherence to the development of best practices suffering as a result?
As a team, are we overzealous in forecasting for the sprint?
4. Control Chart
What is it?
This chart focuses on the work cycle time of individual issues – the total time from "in progress" to "done". Do not forget to identify the "definition of done" for your team. Teams that have consistent work cycles are more predictable in delivering work and teams with shorter cycle times are likely to have higher throughput. While cycle time is a primary metric for kanban teams, scrum teams can benefit from optimized cycle time as well.
Measuring cycle time allows the team to make any adjustments right away, because the results of changes are discernable, almost immediately. The end goal is to have a consistent and short cycle time, regardless of the type of work (new feature, technical debt, etc.)
How do we use it? Jira Tutorial
Jira has a built-in tool that allows you to create and view a control chart. Here are the instructions listed on Jira:
Issue details: Select a dot to see data for a specific issue.
Zoom in: Highlight an area of the chart to focus on a specific time period.
Time scale: Configure the time period you want data for.
Refine report: Select the columns, filters, and swimlanes you want data for.
Potential Problems
Control charts can appear volatile at first, but noticing trends can help save you time, money, and energy. There are two areas of concern you may want to look out for:
Increasing cycle time - This can drain some of the team energy. In the team's retrospective, take time to understand the trend in cycle time increase. One exception: if the team's definition of done has expanded, cycle time will probably expand too.
Unstable cycle time – The goal is to have consistent cycle time for work items that have similar story point values. Filter the control chart for each story point value to check for consistency. If cycle time is erratic on small and large story point values, spend time in the retrospective examining the misses and improving future estimations.
5. Cumulative Flow Diagram
What is it?
To ensure the flow of work across the team is consistent, kanban teams might use the cumulative flow diagram. With a number of issues on the Y-axis, time on the X-axis, and colors to indicate the various workflow states, it visually points out shortages, bottlenecks, and works in conjunction with Work In Progress (WIP) limits.
How do we use it? Jira Tutorial
The CFD is a useful metric for identifying bottlenecks. If your chart contains an area that is widening vertically over time, the column that equates to the widening area is generally considered to be a bottleneck.
Jira provides a tool that allows you to view the CFD with the steps listed below:
Go to the project where your board is located, then select your board from the Board menu.
Click Reports, then select Cumulative Flow Diagram.
To refine the data shown in the report, click Refine report, and select the desired filters.
To select a different time frame, click the date range drop-down at the top of the chart.
To select a different date range, drag your cursor across the 'Overview' at the bottom of the chart.
Potential Problems
Blocking issues create large bottlenecks in some parts of the sprint process and can hinder other areas of work as well.
There is potential for an unchecked backlog growth over time. This results from product owners not closing issues that are obsolete or simply too low in priority to be pulled into the sprint.
Conclusion:
What works best for your team is subjective based on the work that is being done. There is not always a "one-size-fits-all" solution to tracking your team's progress, so understanding the needs and goals of your team and customers will help you identify which type of metric should be used for tracking sprints. I hope that this article helps you and feel free to leave a comment below if you use any of these metrics with your team!
Adapted from Atlassian.com, spin.atomicobject.com, and productcoalition.com