Skip to main content

Managing Sprint / Delivery Cycles

Treno - Customer Knowledge BaseKey Use Cases

Managing Sprint / Delivery Cycles

DEFINITION:

Treno can be used to maintain operational excellence by monitoring and providing observability into your software development delivery (sprint) cycles. 

ROLES:

  • Engineering Manager

  • Product Manager

  • Solutions Architect

  • Engineering Lead

RECOMMENDED USAGE:

  • Every other day during the delivery cycle

ANALYSIS ACTIVITIES:

 

 A. Identify delivery work that may be blocked or at risk.

 

  1. Select the desired project

  2. Navigate to the Analyze/Overview page

  3. Select the shortest time frame (14D) or the current sprint

  4. At the bottom, view the “Reviews and Issues that need attention during” section

  5. From the Active Reviews Tab  (data pulled from Code Repository)

    • View open reviews that have been open longer than normal (baseline)

  6. From the Active Issues Tab (data pulled from Project Management tool)

    • View open reviews that have been open longer than normal (baseline)

What to look for:

  1. The sort feature should allow you to identify reviews and issues that might be stuck.  

  2. Of less value is to sort by the longest open review or issue.  The long standing items are more than likely remnants that should have been closed or that are just discarded or left uncompleted for various less than critical reasons.

What to do:

  1. The sort feature should allow you to identify reviews and issues that might be stuck.

 

 

 B. Review work in progress

 

  1. Select the desired project

  2. Navigate to the Analyze/Transaction page

  3. Select one of the these metrics: 

    • Sprints Started - shows sprint and the issues in each Sprint

    • Total Open Reviews - shows all active reviews

    • Issues Created - shows open issues

What to look for?

  1. Sprints Started will show the current status of each issue in the active and most recent Sprint.  

    • Look for a large number of items stuck in the same stage - especially workflow stages related to review and QA and deployment.  These are usually the bottleneck workflow stages.

  2. Of less value is to sort by the longest open review or issue.  The long standing items are more than likely remnants that should have been closed or that are just discarded or left uncompleted for various less than critical reasons.

What to do?

  1. Look for issues that are “stuck” and sitting in the same workflow stage for more than one of your analysis checks.

  2. Review from Analyze/Management page the average time an issue stays in a workflow stage - issues that stay longer are “bottlenecked”

  3. Add time in stage to the weekly 1:1s you have with the delivery leads.  Common bottleneck causes are:

    • Poorly written stories

    • Overloaded teams or engineers

    • Overly complicated QA process

    • Mobile focused deployment processes

    • Disconnected DevOps teams and processes

  4. If bottlenecks are found, leverage the spotlight metrics to identify potential areas for improvement in your software development lifecycle