GoLeanSixSigma.com Green Belt Eduardo Torres did a great job of cutting waste out of the process of fixing software bugs. The use of software is growing fast, and with no known way to guarantee new software is error-free, rapidly fixing bugs found is critical. Eduardo not only cut nearly 40% of the process time, but also cut the variability in half, greatly improving reliability! – Susan Tighe, GoLeanSixSigma.com Master Black Belt Coach --- Eduardo Torres is a Senior Project Manager and Lean Six Sigma Green Belt with expertise in the Telecommunications Field. For his Green Belt Project, he decided to tackle the long lead time for software bug fixes – reducing the total lead time from 25 to 15 days!

1. Software Bug Fixes Lead Time
Improvements
Eduardo M. Torres PMP
Green Belt Project Storyboard

2. Storyboard Checklist
2
Storyboard submission is key to certification - You will be certified based on the following:
1. Complete all required Storyboard elements - See checklist below
2. Tell your story succinctly - 25 slides maximum - unlimited Appendix
3. Use the tools wisely - Use the right tools for the right reasons and include a "Take Away" or learning on each slide
4. Label your graphs clearly - Title all graphs & charts, label each axis and indicate the time frame of the data
5. Be clear about your analysis - Describe all root cause hypotheses along with how you verified or disproved each one
6. Show measurable Improvement - Document each reduction in waste, time or defects and show "before" and "after"
Submit all required Storyboard elements
- For any requirement with more than one option - please include one or more of the options listed
- Review "Example" tab on templates to see how to fill in each field
(T) = Template available
Slides
What is the story of your project?
Green Belt Storyboard (T) 1-31
Have you completed all the required elements of the storyboard?
Green Belt Storyboard Checklist (T)
What is the one-page summary of your work?
Executive Summary (T) Note: includes "Before & After" Project Y graphic showing improvement
What was the problem, goal, scope and reason for this project to exist?
Project Charter (T) Goal Statement Builder (T) - use to insure proper format
What is the high-level view of the process being addressed?
SIPOC (T)
What is the detailed view of one or more of the steps in the SIPOC ("As Is" Map)?
Detailed Map Swimlane (T) Value Stream (T) Basic Flow
4
Define Phase Requirements
6
8
7
2-3
Green Belt Storyboard Checklist
Green Belt Candidate:
Introduction Phase Requirements

3. Storyboard Checklist (part 2)
3
What was the plan for collecting data? What type? How much? By whom and how?
Data Collection Plan (T) (Operational Definitions must be included, Start with Project Y) 10
What does the baseline data look like when displayed?
Baseline Data Display (Run Chart required) Run Chart and Histogram or ☐Boxplot 11-12
What were the suspected root causes of the problem with the Project Y?
Fishbone Diagram (T) (With key root causes circled) 14
What issues or opportunities did you discover by studying the process?
Project Specific Map Value-Added Flow Analysis (T) Spaghetti (T) Other
What were your main theories about the root causes of Project Y issues and how did you verify them?
Hypothesis Statement(s) and Results Root Cause Hypothesis Worksheet (T)
What data, observations or other proof do you have of root caues hypothesis verification?
Verification of Root Cause Pareto Chart Box Plot Run Chart Histogram
What were the solutions you developed to solve the problem at the root?
List of Improvements Solution Selection Matrix (T) Impact Effort Matrix (T)
What does the improved process look like with waste removed and solutions implemented?
"To Be" Map (or segment) Swimlane (T) Value Stream (T) Flow Map Spaghetti (T)
What measurements or graphs do you have to show the "after" process is better?
Proof of Improvement Run Chart Box Plot Histogram Other
What are the lessons learned? Soft/hard savings? Potential replication? Process Owner sign off?
Project Closure (T) If solution will be repurposed, include Transfer Opportunities (T)
What terms and acronyms did you use that people outside your might need explained?
Key Words - Definitions of non-DMAIC, industry specific terms
Additional Slides as needed
23-24
Control Phase Requirements
26
Appendix
30-31
22
Measure Phase Requirements
Analyze Phase Requirements
15-16
18
17, 19
Improve Phase Requirements
21

4. Key Take Away: The project was a great success! Customer perception
changed in a good way!
Executive Summary
4
Business Case
Root Cause Analysis
What are the critical findings/root causes that were discovered?
Solutions Implemented
Data showed bug fix ticket assignments and fix deliveries to official branch
took too long, lots of time spent in software building in multiple process
steps, and unnecesary code inspections.
Graphical Display of Improvement
Improved SW Bug Fix Lead Time
List key solutions that were implemented to address root causes
1. Use Kanban methodology for bug fix tickets assignments
2. Removal of Code Inspections for LOC < 250
3. SW deliveries directly to Official Branch
4. Conducted Cross-Training for build and delivery to Official Branch flexibility
Executive Summary
Project Results
What is the importance of doing this project? (State in lost dollars,
productivity loss, customer dissatisfaction, cost avoidance, risk, etc.)
What are the measurable process improvements/wins?
SW Bug Fix Lead Time has reduced from 25 days to 15 days
Lead time improvement for Software Bug Fixes will result in an cost savings
and improved used of resources. Lead Time improvement could translate into
monetary benefits because we will be able to utilize development and testing
resources to work on more features, which could increase customer revenue.
This aligns with our 'Best In Class' mission.

5. Define Phase

6. Project Charter
Key Take Away: Excellent buy-in – project is worth doing.
6
Phase Actual
Define: September 1st September 3rd
Measure: September 17th September 28th
Analyze: October 21st November 1st
Improve: November 21st December 1st
Control: December 14th December 13th
1st Process Step Position Person Title % of Time
Last Process Step Team Lead Eduardo M. Torres Lean Six Sigma
Green Belt
Candidate
40%
Sponsor Phil D. Director 15%
In Scope: Team Member Bharati R. Release Lead 20%
Team Member Rashmi M. Software Builder 20%
Out of Scope: Hardware
additions,
Official Build Load
delivery and Test
processes done
by external teams
Team Member Sundar E. Software Developer 20%
Team Member Errol D. Software Tester 20%
Ticket Assignment Process, Code Development Process
Development and Software Build Process
Goal Statement Timeline
Decrease the Software Bug Fixes Lead Time form 25 Days to 15 Days by
4/1/2019
Scope - First/Last and In/Out Team Members
Fix Request Ticket Created by Customer
The current total lead time for Software Bug Fixes is an average of 25 days.
This results in missing milestones by test teams and delivery delays to
customers
Fix Request Ticket built in the Official Branch
Lead time improvement for Software Bug Fixes will result in an cost savings
and improved used of resources. Lead Time improvement could translate
into monetary benefits because we will be able to utilize development and
testing resources to work on more features, which could increase
customer revenue. This aligns with our 'Best In Class' mission.
Planned Completion Date
Project Charter
Problem Statement Business Case & Benefits
Software Bug Fixes Lead Time Improvement

7. SIPOC
Key Take Away: The scope of the project is from the moment a bug fix ticket is
created until the bug fix is built in the Official branch 7
S I P O C
Suppliers Inputs Process Outputs Customers
Testers and Fix Request Testers
Customer Support
Patch Testing
Results
Customer Support
Sanity Test Team Sanity Test Results
Fix Request Ticket
Ready for Testing
SIPOC
Fix Request Ticket
Created
Ticket Assigned to
Developer
Develop fix by
assigned developer
Build, test,deliver fix
to local branch
Customer Requirements
Response-Time
Target Response Time is 15 days or less
Build, test,deliver fix
to official branch
Fix Delivered and
built in Official
Branch

8. “As-Is” Detailed Map Segment
Key Take Away: The team learned how long is taking to provide a fix to the
customer! Provides a bigger picture of the impact the work they do. 8
Software Bug Fix Delivery
Yes
No
Yes
No
No Yes
Customer
Release
Lead
SW
Developer
SW Builder
Sanity
Testing
Team
Creates
Ticket
Test
OK
Private
Patch
Testing
Code
Inspection
Code
Changes
Assigns
Ticket to
Developer
Deliver to
Parent
Branch
Local
Branch
Build
Sanity
Testing
Inspectio
n OK
Test
OK
Deliver to
Official
Branch
In Scope
Out of
Scope
Dev Build
Official SW
Load with fix
delivered
Official
Branch
Build

9. Measure Phase

10. Data Collection Plan
Key Take Away: Since this is a lead time project, most of the measures turned
about to be continuous measures of different segments of time. The discrete
measure is to determine if a process step is really needed 10
Measure
Title
Data Type
(Continuous
or Discrete)
Operational Definition
Stratification
Factors
(By who/what/
where/when)
Sampling Notes
(Time Frame, etc.)
Who and How
(Person responsible and
method - Check Sheet?)
SW Bug Fix
Lead Time
Days -
Continuous
The amount of time (in Days) it takes from the
moment the customer creates a bug fix ticket
(ticket state Created) to the moment the bug fix
is built into the official SW branch (ticket state
Ready For Testing 'RFT').
None
Sample every bug fix
ticket for the next 6
weeks starting 8/1
Release Leader will check the
date stamps on the bug
tracking tool
Ticket
Assigned Lead
Time
Days -
Continuous
The amount of time (in Days) it takes from the
moment the customer creates a bug fix ticket
(ticket state Created) to the moment the bug fix
ticket is assigned to a SW developer (ticket
state Assigned).
None
Sample every bug fix
ticket for the next 6
weeks starting 8/1
Release Leader will check the
date stamps on the bug
tracking tool
Ticket Ready
to Submit
Lead Time
Days -
Continuous
The amount of time (in Days) it takes from the
moment the the bug fix ticket is assigned to a
SW developer (ticket state Assigned) to the
moment SW developer is ready to deliver the
code (ticket state Ready to Submit).
Development testing is done, and Code
Inspection is approved in the Ready to Submit
State.
None
Sample every bug fix
ticket for the next 6
weeks starting 8/1
Release Leader will check the
date stamps on the bug
tracking tool
Ticket Code
Commited
Lead Time
Days -
Continuous
The amount of time (in Days) it takes from the
moment the SW developer is ready to deliver
the code (ticket state Ready to Submit) to the
moment SW developer delivered the code to
parent branch (ticket state Code Committed).
Development testing is done, and Code
Inspection is approved in the Ready to Submit
State.
None
Sample every bug fix
ticket for the next 6
weeks starting 8/1
Release Leader will check the
date stamps on the bug
tracking tool
Ticket Ready
for Testing
Lead Time
Days -
Continuous
The amount of time (in Days) it takes from the
moment SW developer delivered the code to
parent branch (ticket state Code Committed) to
the moment bug fix is built into the official SW
branch (ticket state Ready For Testing 'RFT').
None
Sample every bug fix
ticket for the next 6
weeks starting 8/1
Release Leader will check the
date stamps on the bug
tracking tool
Code
Inspections
Lead Time
Days -
Continuous
The amount of time (in Days) it takes from the
moment code inspection is created to the
moment the code inspection is approved.
None
Sample 20 Code
Inspections per week for
the next 6 weeks starting
8/1
Release Leader will check the
number of comments on the
code inspection tool
Comments per
Code
Inspections
Discrete
The ammount of Comments in a Code
Inspections
By LOC (Lines of
Code)
Sample 20 Code
Inspections per week for
the next 6 weeks starting
8/1
Release Leader will check the
number of comments on the
code inspection tool
Data Collection Plan

11. Baseline – Project Y
Key Take Away: Lots of variation in the process and the average time to deliver
bug fixes is 25 days which is very high! 11
Mean: 25.81
0
10
20
30
40
50
60
Days
Baseline Lead Time of Software Bug Fixes (August 2018-September 2018)

12. Baseline – Software Bug Fixes Lead Time
Key Take Away: Target delivery is 15 days or less, so the bug fix delivery
process is clearly not capable. 75th Percentile is 33 days! 12
0
5
10
15
20
25
30
0.0
3.0
6.0
9.0
12.0
15.0
18.0
21.0
24.0
27.0
30.0
33.0
36.0
39.0
42.0
45.0
48.0
51.0
54.0
Frequency
Lead Time in Days
Baseline Lead Time of Software Bug Fixes (August 2018 - September 2018)
Count = 279
Mean = 25.817
StDev = 10.568
Minimum = 3
25th Percentile (Q1) = 18
50th Percentile (Median) = 25
75th Percentile (Q3) = 33
Maximum = 55
95% CI Mean = 24.572 to 27.063
95% CI Sigma = 9.758 to 11.526
Anderson-Darling Normality Test:
A-Squared = 0.430934
P-Value = 0.3045

13. Analyze Phase

14. Fishbone Diagram
Key Take Away: The biggest areas to analyze further where code inspections,
delivery to parent branches, assignment of bug fix tickets. 14
Fishbone Diagram
Not enough hardw are for
testing
Process
Parent branch locked all the time
Tickets assignment taking too long
Environment
Lab enviroment not the same
as customer environment
Test need to be redone due
to test environment issues
Only China Site doing
Sanity Testing
People
Bug Fix
Deliveries
taking Too
Loong
Debug Capabilities not robust enough
Tests are not automated
Issue Difficult to reproduce
Logs provided incomplete or no logs
No feedback fromtest team w ith
test results
Policies
Requirements Not Clear
Not enough time for developers to
review Code Inspection
Code inspection approval is slow
Competence area not
enough staffed

15. Map Segment Showing Analysis
Key Take Away: Process analysis showed a potential for removing unnecessary
steps that are not adding value or causing bottlenecks 15
Software Bug Fix Delivery
Yes
No
Yes
No
No Yes
Customer
Release
Lead
SW
Developer
SW Builder
Sanity
Testing
Team
Creates
Ticket
Test
OK
Private
Patch
Testing
Code
Inspection
Code
Changes
Assigns
Ticket to
Developer
Deliver to
Parent
Branch
Local
Branch
Build
Sanity
Testing
Inspectio
n OK
Test
OK
Deliver to
Official
Branch
In Scope
Out of
Scope
Dev Build
Code Inspection
may not needed.
Code delivery
potential delay.
Possible delay
assigning work.
Official SW
Load with fix
delivered
Official
Branch
Build

16. Map Segment Showing Analysis
Key Take Away: Biggest opportunities to remove steps are Code Inspections
and Deliver to Parent Branch. Opportunities for time reduction in Assign Tickets
to Software Developers step. 16
Name: Eduardo M. Torre Process Name:
Date: November 7th
Time
Measured In: Minutes Hours Days
# Process Step
Step Label
(VA, NVA,
NVAr)
Value
Added
Time
NVA & NVA-
Required
Work Time
NVA - Wait
Time
1 Assign Ticket to Software Developer NVAr 2
2 Software Code Changes VA 10
3 Development Build VA 1
4 Code Inspection NVA 3
5 Private Patch Testing VA 1
6 Deliver to Parent Branch NVA 3
7 Local Branch Build NVA 1
8 Sanity Testing NVAr 2
9 Deliver to Official Branch NVAr 1
10 Official Branch Build VA 1
Time %of total
13 52.00% 50
12 48.00%
0 0.00%
25 100.00%Total Cycle Time
Value-Added Flow Analysis
Software Bug Fixes Delivery
(select units)
Total Value-Added Work Time
Total Non-Value-Added or NVA-r Work Time
NVA - Wait Time

17. Value Added Flow Data
Key Take Away: Split of the Baseline data based on the ticket state. Deliver to
Parent branch time is all wasted time. Removing code inspection saves
average 3 days in the lead time 17
# Process Step Lead Time
Total Lead
Time
1 Assign Ticket to Software Developer Ticket Assigned Lead Time 2
2 Software Code Changes
4 Development Build
3 Code Inspection
5 Private Patch Testing
6 Deliver to Parent Branch Ticket Code Committed Lead Time 3
7 Local Branch Build
8 Sanity Testing
9 Deliver to Official Branch
10 Official Branch Build
Ticket Ready to Submit Lead Time
Ticket Ready For Testing Lead
Time
15
5

18. Root Cause Hypothesis
Key Take Away: Data confirmed all the hypotheses except the code inspection
not needed for LOC > 250. 18
#
Possible Root Cause (x)
(1 or 2-Word Descriptor)
Root Cause Hypothesis
(Theory of how "X" is influencing the Project "Y")
Theory True
or False?
Verification
(How did you prove or
disprove this theory?)
1 Assignment Time
Tickets Assignemnt Taking too long adding wasted
time in Lead Time
TRUE
See Box Plot on next slide - Average is 2
days target is < 1 day
2 Inspection Not Need Code Inspection is not needed
TRUE and
FALSE
Next slides show pie charts
TRUE for LOC < 250. No Comments in
91% of the inspections
FALSE for LOC > 250 No Comments in
34% of the inspections
3 Delivery Time Delivery to Parent Branch taking too long TRUE
See Box Plot on next slide- Average is 3
days target is < 1 day
Root Cause Hypothesis

19. Root Cause Hypothesis Results
Key Take Away: Data confirmed all the hypotheses except the code inspection
not needed for LOC > 250. 19

20. Improve Phase

21. Selected Solutions
Key Take Away: The effort required to cross-train SW builders (Development
tasks) will not allow to meet the schedule. Code removal buy-in showed that
sometimes some processes are a false sense of security 21
Project Goal
Decrease the Software Bug Fixes Lead Time form 25
Days to 15 Days by 4/1/2019
(As stated on Project Charter)
Very Low
(less good)
Moderate
Very High
(best)
1 2 3 4 5
Potential Solution
(Provide Brief Description)
Potential to
Meet Goal
Positive
Customer
Impact
Cost to
Implement
(1 = $$$
& 5 = $)
Stakeholder
Buy-in
Time to
Implement
(1 = Long
5 = Quick)
Weighted Criteria 10 9 8 7 5
Remove code inspections for LOC < 250 5 3 4 3 5 155 Yes
Cross-train Developers 4 3 3 3 4 132 Yes
Cross-train SW Builders 2 3 3 3 1 97 No
Use Kanban methodology for tickets assignment 4 4 3 4 4 148 Yes
Total
Score
Implement?
Yes/No
Solution Selection Matrix
Please rank each solution for each criteria
by using the 1-5 Scale as indicated below

22. “To Be” Map Segment
Key Take Away: Process changes including remove unnecessary inspections
(for fixes of 250 Lines of Code or Less), removing bottlenecks, Cross-training to
reduce hand-offs and use of Kanban methodologies. 22
Software Bug Fix Delivery
Yes
No
Yes Yes
No
No
No Yes
Customer
Release
Lead
SW
Developer
SW Builder
Sanity
Testing
Team
Creates
Ticket Test
OK
Private
Patch
Testing
Code
Inspection
Code
Changes
Prioritizes
Ticket
Official SW
Load with fix
delivered
Sanity
Testing
Inspectio
n OK
Test
OK
Deliver to
Official
Branch
In Scope
Out of
Scope
Lines of
Code < 250PicksTicket
Use Kanban to
minimize Tickets
not assigned
Remove code
inspections for
LOC < 250
Deliver Directly to
Official Branch
Cross-train
Developers for SW
Builder tasks
Local
Branch
Build
Local Branch Build
done by
developers
Official
Branch
Build

23. Run Chart Showing Improvement
Key Take Away: Improvements had an impact of 39% reduction on Software
Bug Fixes lead time while cutting variability in half! This gave much faster
response time with greatly improved reliability!
23

24. Improved – Software Bug Fixes Lead Time
Key Take Away: Data with improvement solutions shows an average lead time
decrease from 25.8 days to 15.6 days and 75th Percentile is 19 days from 33
days
24
0
2
4
6
8
10
12
14
16
18
4.0
6.0
8.0
10.0
12.0
14.0
16.0
18.0
20.0
22.0
24.0
26.0
Frequency
Lead Time In Days
Improved Lead Time of Software Bug Fixes (November 2018)
Count = 100
Mean = 15.640
StDev = 5.264
Minimum = 4
25th Percentile (Q1) = 12
50th Percentile (Median) = 15.500
75th Percentile (Q3) = 19
Maximum = 27
95% CI Mean = 14.596 to 16.684
95% CI Sigma = 4.622 to 6.115
Anderson-Darling Normality Test:
A-Squared = 0.404791
P-Value = 0.3474

25. Improved Value Added Flow Data
Key Take Away: Improvements showed on Step #1 (from 2 days to <1 day) by
using Kanban and on Step #7 (from 3 days to <1 day) by SW cross-train
developers to deliver directly to Official Branch. 25
# Process Step Lead Time
Total Lead
Time
1 Assign Ticket to Software Developer Ticket Assigned Lead Time 0
2 Software Code Changes
3 Local Branch Build
4 Code Inspections if LOC > 250
5 Private Patch Testing
6 Sanity Testing
7 Deliver to Official Branch Ticket Code Committed Lead Time 0
8 Official Branch Build 1
Ticket Ready to Submit Lead Time 15

26. Control Phase

27. Project Closure
Key Take Away: Ended up with resource effort savings and the VP is thrilled!
27
Do's and Don'ts for Future Efforts
Yes
Yes
Yes
Has been informed of process changes: The Platform Software Team did a great job! We are moving on the right
direction to be "Best In Class" - I'm offically giving my stamp of approval
for documented improvements.
- Phil Diguglielmo - Director
Agrees to continued monitoring of new process:
Has received new process documentation:
Process Owner Hand-off Sign-off From Project Sponsor
Final Calculations of Savings or Gains
Effort savings of 46 People Month that is translated in $384K in savings
Team member morale increased, more time to work on features.
Hard Savings/Profit Increase Soft Savings - Cost or Time
Project Closure
Continuous communication to avoid surprises Customer Perception changed in a good way.
Open Minded attitude due to we will challenge status quo
Be sure to give credit to everyone who came up with good ideas -
credit is free!
In some cases some processes give a false sense of secuirty like Code
Inspection for bug fixes
Lessons Learned Customer Impact
Positive Impacts on External Customer

28. Process Control Plan
Key Take Away: The bug tracking tool has the data needed to collects this
information. We’ll only need the Release Lead to gather the data 28
Customer
Release Lead
SW Developer
SW Builder
Testing Team
List of
Measures:
P1
Cycle Time Starts
Ticket Assigned
Time Starts
P2
Ticket Assigned
Time Ends
P3
Ticket Ready to
Submit Time
Starts
P4
Ticket Ready to
Submit Time Ends
P5
Ticket Code
Committed Time
O1
Ticket Ready For
Testing Time
Starts
O2
Ticket Ready For
Testing Time
Ends
P = Process Measures, O = Output Measures
Process Control Plan
Creates
Ticket
Testing
Sanity
Testing
Delivery to
Official
Branch
Build
Official
Branch
P2
P4
O1
Prioritize
Ticket
Picks
Ticket
Code
Changes
P1
P3
Fix
delivered
O2
P5

29. Monitoring Response Control Plan
Key Take Away: Responding to the last 4 items will help ensure that the first
item (our primary goal) remains low. 29
Name of the Measure
Input,
Process or
Output?
What is the
Target?
Method of Data
Capture
Checking
Frequency
Person
Responsible
Upper/Lower
Trigger Point
Who Will
Respond?
Reaction Plan
Bug Fix Lead Time Output 15 Days or Less
Date stamp when
customer create a
bug fix ticket to date
stamp the fix is built
in the official branch
Weekly Release Lead
No greater than 17
Days
Upper Control Limit
Release Lead
Observe the following Measurements to see why it's taking
longer. Make corrections
- Ticket Assigned Time
- Ticket Ready to Submit Time
- Ticket Code Commited Time
- Ticket Ready For Testing Time
Ticket Assigned Lead
Time
Process 1 Day or Less
Date stamp when
customer create a
bug fix ticket to date
stamp when the
ticket is assigned to
a SW developer
Weekly Release Lead
No greater than 2
Days
Upper Control Limit
Release Lead
Make corrections
- More resources needed?
- Escalation Needed for more resources?
Ready to Submit Lead
Time
Process 12 Days or Less
Date Stamp when the
ticket is assigned to
a developer to a sw
developer is ready to
submit to Official
Branch.
Weekly Release Lead
No greater than 15
Days
Upper Control Limit
Release Lead
Make corrections
- Fast response from the test team?
- Architects or Subject Matter Experts need involvement?
- Environment Issues?
Code Commited Lead
Time
Process 1 Days or Less
Date Stamp when the
ticket is delivered to
Official Branch.
Weekly Release Lead
No greater than 2
Days
Upper Control Limit
Release Lead
Make corrections. Understand why we cannot deliver to
Official Branch
- Environment Issues?
- Official Branch locked due to external issues?
Code Commited Lead
Time
Process 1 Day
Date Stamp when the
ticket is delivered to
Official Branch.
Weekly Release Lead
No greater than 2
Days
Upper Control Limit
Release Lead
Make corrections. Understand why Official Branch is not
doing software builds
- Environment Issues?
- Official Branch locked due to external issues?
Monitoring Plan Response Plan

30. Appendix

31. Key Words
31
Key Word Description
Code Inspection The most formal type of review, which is a kind of static testing to
avoid the defect multiplication at a later stage
Development Branch Software repository created under a Parent Branch and used by
software developers to make code changes
Development Build Build one or more software components in the Development Branch
Lines of Code (LOC) Is a software metric used to measure the size of a computer program
by counting the number of lines in the text of the program's source
code.
Local Branch Software repository created under the Official Software Release
repository
Local Branch Build Build all software components in the Local Branch
Official Branch Official Software Release repository
Official Branch Build Build all software components in the Official Branch
Parent Branch Higher Level repository
People Month Number of Resourses / Month
Private Patch Testing Testing of software code changes done to fix specific bug or issue
Sanity Testing Testing so no further issues are introduced due to these changes.
SW Bug Fix Lead Time The amount of time (in Days) it takes from the moment the customer
creates a bug fix ticket (ticket state Created) to the moment the bug
fix is built into the official SW branch (ticket state Ready For Testing
'RFT').
Ticket Assigned Lead Time
The amount of time (in Days) it takes from the moment the customer
creates a bug fix ticket (ticket state Created) to the moment the bug
fix ticket is assigned to a SW developer (ticket state Assigned).
Ticket Code Commited Lead Time The amount of time (in Days) it takes from the moment the SW
developer is ready to deliver the code (ticket state Ready to Submit)
to the moment SW developer delivered the code to parent branch
(ticket state Code Committed). Development testing is done, and
Code Inspection is approved in the Ready to Submit State.
Ticket Ready for Testing Lead Time The amount of time (in Days) it takes from the moment SW developer
delivered the code to parent branch (ticket state Code Committed) to
the moment bug fix is built into the official SW branch (ticket state
Ready For Testing 'RFT').
Ticket Ready to Submit Lead Time The amount of time (in Days) it takes from the moment the the bug fix
ticket is assigned to a SW developer (ticket state Assigned) to the
moment SW developer is ready to deliver the code (ticket state Ready
to Submit). Development testing is done, and Code Inspection is
approved in the Ready to Submit State.

32. Key Words
32
Ticket State Description
Created Ticket created by a customer
Assigned Ticket Assigned to a developer
Ready to Submit Development testing is done, and code inspection is approved
Code Committed Code delivered to a Parent Branch
Ready for Testing (RFT)Code built in Official Branch and ready for verification