Sprint Best Practices

View information about your sprints relative to the best practices of running sprints.
View Live Demo

The Sprint Best Practices report automatically calculates information about Sprint best practices in terms of how development time is spent on tickets that adhere to best practices.

Development time is calculated by allocating work hours between commits to the commit that follows. So, if you work 9-5 and commit at 1 PM and 5 PM, the 5 PM commit would be counted as one half day of development time.

The Sprint Best Practices report displays the following information about how development time is spent:

  1. Ticket Estimates - The portion of time spent on tickets that have estimates. Estimates are important. Without an estimate, it is difficult to have any expectations about how long a ticket will take and proactively break down tickets that are too big. The estimate can be a story point estimate or a time estimate.
  2. No Omnibus Tickets - The portion of time spent on tickets that are “small” (defined as less than 5 development days). Large tasks are the enemy of productivity. Big tasks make it harder to understand the status of work, are difficult to estimate, and pose a greater risk of not having a clear definition of done.
  3. On-Sprint Work - The portion of time spent on tickets that are in the active sprint. It is important that developers primarily work on tickets that are in an active sprint rather than working off-the-book tickets. If people don't work in the sprint, then it is difficult to predictably meet expectations.
  4. No Multi-Sprint Rollover - The portion of time spent on tickets that have active work in no more than two sprints. It is normal for some tickets not to finish by the end of a sprint and spill into the next one. Tickets may also get bumped from multiple sprints before work starts. However, once work begins on a ticket, it is a problem if it spans more than two sprints. ​​ In addition to the ticket likely being too big or having flow efficiency problems, this means that sprint commitments are unreliable and defeats many of the benefits that sprints provide.
  5. Stable Sprint Scope - The portion of time spent on tickets that were in the sprint at the beginning. An issue that can disrupt sprint reliability is when teams are inundated with last-minute requests, urgent bugs, or new work that comes up due to lack of internal planning. This leads to the original sprint work getting pushed back, which erodes the reliability of sprint commitments.

You can easily customize the report to filter by team or person to see more detail on how well various groups perform on these metrics.

This report is useful to engineers, team leads, engineering leaders, scrum masters, and anyone interested in the health of Sprints.