6th International Conference in Software Engineering Research and Innovation: San Luis Potosí, S.L.P., México

1. The 6th International Conference in Software Engineering Research and Innovation
Fernando Sambinelli
imagem: http://www.scrumhint.com/
Modeling and Performance Analysis of
Scrumban with Test-Driven Development using
Discrete Event and Fuzzy Logic
Edson L. Ursini Marcos A. F. Borges Paulo S. Martins
School of Technology
University of Campinas
Limeira, Brazil

2. 2
Roadmap
Case StudiesA
Implementation9
Context & MotivationB
imagem: https://blogs.aca-it.be/
4 Computational Model
Results & DiscussionW
ConclusionY
2

3. 3 3
The way software is built has considerably
changed since the emergence of agile methods
in the late 1990s
B Context & Motivation

4. 4
B Context & Motivation
4
Test-Driven Development
(TDD)
Fail
Pass
Refactor

5. 5
B Context & Motivation
5
There is no consensus in the literature on TDD
adoption in relation to productivity improvement
Variation of productivity in agile teams that adopt TDD
+-
Reduction of -57% Increase of +72%

6. 6
B Context & Motivation
6
No studies were found that analyzed the
productivity impacts of TDD practitioners in
relation to some contexts:
Product Complexity Project Duration
simple complex short term long term

7. The goal was to analyze the
impact of TDD adoption on the
productivity of development
process as a function of the
duration of the project and the
complexity of the product
Objective
7
imagem: http://www.scrumhint.com/
Y

8. Two Hypotheses
8
Independently from product complexity,
there is no improvement in productivity
when using TDD
Hypothesis (H1)
Independently from the duration of the
project, there is no improvement in
productivity when using TDD
Hypothesis (H2)

9. 9 9
Our Approach
Discrete Event
Modeling and
Simulation
Fuzzy
Logic
A real-world
company in Brazil
(“A”)

10. 10
imagem: https://blogs.aca-it.be/
Roadmap
10
Case StudiesA
Implementation9
Context & MotivationB
4 Computational Model
Results & DiscussionW
ConclusionY

11. 11
4 Computational Model 11
Theoretical Scrumban Life-cycle Model
1. Product
Idea
2. User Stories
Specification
(meetings)
3. Product
Backlog
4. Sprint
Backlog
(batch)
5. Planning
Meeting
6. Coding of
Automated Unit Test
(only adopting TDD)
7. Coding of
User Story
8. Functional
and Acceptance
Tests
9. Incremental
Software Delivery
(to the Product
Owner)
Sprint

12. 12
4 12
Black Box of the Simulated Process
Performance Model
Product Complexity
(low, medium, high)
Project Duration
(working days)
User Stories
Adopts TDD
(yes, no)
Productivity
(story points/
working days)
Computational Model

13. 13
4 13Computational Model
Low Complexity
User Story
Medium Complexity
User Story
High Complexity
User Story
1 or 2 Story Points
triangular distribution
(1h, 3h, 5h)
3 or 5 Story Points
triangular distribution
(3h, 5h, 8h)
8 or 13 Story Points
triangular distribution
(7h, 10h, 19h)
Relationship between the development effort (hours) and a unit of complexity (story points)
Model Factors: product complexity

14. 14
4 14Computational Model
Low Complexity
Product
Medium Complexity
Product
High Complexity
Product
10%
30%
60%
20%
40%
40%
50%
30%
20%
Low Complexity
User Story
Medium Complexity
User Story
High Complexity
User Story
Model Factors: product complexity

15. 15
4 15Computational Model
Model Factors: project duration
Short Term
Project
Up to 60
Working Days
Medium Term
Project
From 61 to 255
Working Days
Long Term
Project
Greater than 255
Working Days
*1 Working day = 8 hours

16. 16
4 16Computational Model
Arrival Rates of User Stories
*1 Sprint = 15 working days
Low Complexity
Product
30 User Stories
per Sprint
Medium Complexity
Product
23 User Stories
per Sprint
High Complexity
Product
10 User Stories
per Sprint

17. 17
4 17
Considerations Based on Historical Data
from A Company’s Projects
1. Projects that use TDD have an average
increase between 90 to 115% in the
codification effort of each user story in the
first 105 working days
2. After this period, the increase is reduced to a
value between 40 and 60% and is maintained
until the end of the project
Extra
Codification Effort
Computational Model

18. 18
4 18
3. In projects with TDD, the rework rate for
developing user stories is recorded
between 7 and 9%
4. In projects without TDD, the rework is
registered between 15 and 27%
Rework Rates
Computational Model
Considerations Based on Historical Data
from A Company’s Projects

19. 19
4 19
Typical Learning Curves of Projects from A Company
Computational Model

20. 20
imagem: https://blogs.aca-it.be/
Roadmap
20
Case StudiesA
Implementation9
Context & MotivationB
4 Computational Model
Results & DiscussionW
ConclusionY

21. 2121
Discrete Event Simulation Software
Implementation9

22. 2222
Discrete Event Simulation Implementation
Implementation9
Creating user-story entities
Scrumban Development Process

23. 2323Implementation9
Planning meeting of sprints (part A)
Discrete Event Simulation Implementation
Scrumban Development Process

24. 2424Implementation9
Productivity adjustment - Learning Curve
Discrete Event Simulation Implementation
Scrumban Development Process

25. 2525Implementation9
Stages of development, testing and delivery of the software
Discrete Event Simulation Implementation
Scrumban Development Process

26. 26
imagem: https://blogs.aca-it.be/
Roadmap
26
Case StudiesA
Implementation9
Context & MotivationB
4 Computational Model
Results & DiscussionW
ConclusionY

27. 2727
Scenarios of Case Studies
Cases of StudiesA
Case Studies 1 2 3
Scenarios 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Product Complexity l l l l l l m m m m m m h h h h h h
Project Duration S S M M L L S S M M L L S S M M L L
Adopts TDD o o o o o o o o o
l=low complexity
m=medium complexity
h=high low complexity
S=short term
M=medium term
L=long term

28. 28
imagem: https://blogs.aca-it.be/
Roadmap
28
Case StudiesA
Implementation9
Context & MotivationB
4 Computational Model
Results & DiscussionW
ConclusionY

29. 2929
Story Points Developed and Delivered by the Team
Results & DiscussionA
*SP=Story Points *WD=Working Days

30. 3030
Time Productivity Variation in Case Study 1
Results & DiscussionA
*SP=Story Points *WD=Working Days

31. 3131Results & DiscussionA
*SP=Story Points *WD=Working Days
Time Productivity Variation in Case Study 2

32. 3232Results & DiscussionA
*SP=Story Points *WD=Working Days
Time Productivity Variation in Case Study 3

33. 3333
Theoretical Guideline for TDD Adoption
Results & DiscussionA
LowMediumHigh
Short-term Medium-term Long-term
NotRecommended
Dependson
Breakdownpoints
Recommended
ProductComplexity
Project Duration
TDD adoption increases productivity
TDD adoption decreases productivity
It needs analysis

34. 3434
Recommendation of TDD using a Fuzzy Logic
Results & DiscussionA
Product
Complexity
Fuzzification
TDD
Fuzzification
% Low Complexity User Stories
(1 or 2 story points)
% Medium Complexity User Stories
(3 or 5 story points)
% High Complexity User Stories
(8 or 13 story points)
Project Duration
(working days)
Product Complexity
(low, medium, high)
Adopts TDD?
(not recommended,
indifferent,
recommended)

35. 3535
Fuzzy Logic: determining the complexity
Results & DiscussionA

36. 3636
Fuzzy Logic: recommendation of TDD
Results & DiscussionA

37. 3737
Fuzzy Logic System: 3D Model
Results & DiscussionA
Project DurationProduct Complexity
AdoptsTDD

38. 3838
1. The data sample from this study is restricted to a single
company
The proposed model can be applied in other companies
and teams. It is only necessary to obtain the historical
data and to adjust the simulation parameters
Limitation of this Study
Results & DiscussionA

39. 39
imagem: https://blogs.aca-it.be/
Roadmap
39
Case StudiesA
Implementation9
Context & MotivationB
4 Computational Model
Results & DiscussionW
ConclusionY

40. 40
Y 40
The results showed that both factors, project duration and
product complexity influence the productivity of the software
development team that adopts TDD practice -> H1 & H2
• In the case of short-term projects (<=60 WD), in all scenarios
of product complexity, the adoption of TDD results in a
productivity lower than non-adoption
• In the case of long-term projects (> 255 WD), also
independent of the complexity of the project, the adoption of
TDD is more productive than non-adoption
Conclusion
Conclusion

41. 41
Y 41
• However, medium-term projects (>61WD & <= 255 WD)
require a more detailed analysis for decision making, since,
depending on the complexity of the product, the breakdown
point in favor of adopting TDD occurs at distinct times of
the project
Conclusion
Conclusion

42. 42
Y 42
• We consider the inclusion of the impact analysis of
product quality to the theoretical model
• The entry and exit of members of an agile software
development team
• Simulation of the theoretical model using the agent-
based approach
Conclusion
Future Work

43. Thanks!
Fernando Sambinelli
fersambi@gmail.com
/fernandosambinelli