1. IFPUG Agile Interest Group (IG)
Webinar - May 17 2012
Improving estimates by a 4-
Agile-4-FSM pieces puzzle
Luigi Buglione, Ph.D.
Buglione
Process Improvement & Measurement Specialist
Industry Business Unit
Engineering.IT
www.eng.it

2. Engineering At a glance
_ The first Italian ICT player
_ more than 730 M/€ revenues Research and PA & HC Finance Industry TELCO Utilities
Development
_ 1000 clients
_ 6,300 IT specialists System Int. &
Consultancy
% 46 70 54 80 80
Outsourcing % 35 10 27 10
Software
% 19 20 19 10 20
ERP IT Security ECM
Plant Management
Managed Operations Broadband & Media
System
www.eng.it
www.eng.it

3. Agile-4-FSM Goals of the presentation
 G1. Introduce the ‘Agile-4-FSM’ puzzle
 G2. Analyze each piece of the puzzle
 G3. Propose possible solutions for improving estimates
3 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione

4. Introduction Some initial questions...
Why does it seem so difficult to apply FSM methods
to Agile projects?
What about the maturity of my organization in the
‘sizing & estimation’ process?
What about NFRs? Do they need to be sized and
managed? Eventually, how?
Which kind of changes do I need to introduce in my
Estimation process for achieving better estimates?
4 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione

5. Agile-4-FSM Some pieces of the puzzle...
2. NFRs
1. Requirements
3. Size Measures 4. Estimating &
Planning
5 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione

6. Agile-4-FSM Piece #1 – Requirements (US – User Stories)
US Title Implementation Priority
Relative
Functional Productivity
Test /Estimation
High Level
FUR
Functional Req
(FUR)
Non-functional Reqs
(NFR)
Org/Project related
Reqs
6 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione

7. Agile-4-FSM Piece #1 – Requirements (US2)
Functionality +
Q/T
complementary
issues
Type 1 (F/Q/T)
Type 2 (Q/T)
Architectur
al/Project-
related
issues, not
strictly
linked to a
functionalit
y
• US2 – 2°-generation User Stories
 A US writes and ‘sizes’ expressly only FUR, NFRs are implicit, not easily manageable
 At least, two types of US2 can be manage
 Reference: Buglione L., Meglio Agili o Veloci? Alcune riflessioni sulle stime nei progetti XP, XPM.it,
February 2007, URL: www.xpm.it (in Italian)
7 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione

8. Agile-4-FSM Piece #1 – Requirements (US2) – Type1/2
• US2 – Type 1
 This is a typical, complete US
 It includes the FUR-part (F) as well, after
the interplaying between Customer and
Provider, the related Q/T parts
 Its value besides in making visible those
NFR parts requiring effort, that otherwise
risk to be underestimated, even if taken
into account by experience
 The more you make explicit, the less the
probability for a higher estimation error
 Example: as in the left-side figure
• US2 – Type 2
 Looking at the typical activities to be run in
Software Life Cycle, also in iterative SLCs as
in Agile methods, some non-
functional/organizational activities that need
to be run, sizing zero (0) FPs but can be
generically classified as Q/T (non-functional)
 Since of course they need effort and must be
estimated and planned, a different way is
needed for being expressed
 They can be simply estimated in m/d or – for
the product NFR-requirements – using e.g.
The IFPUG SNAP method or an elaboration of
ISO/IEC 25010:2011 standard
 Example: as in the right-side figure
8 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione

9. Agile-4-FSM Piece #1 – Requirements (INVEST)
0 1 2 3
INVEST Description
Poor /Absent Fair Good Excellent
I -Independent User Stories should be The start of construction of The completion of such US represents a US can be produced with any constraint, US is fully independent, and it can be
as independent as the US is tied to the completion of at constraint for starting the construction of but its release can be constrained to the realized and released with any constraint
possible between them least another US at least another US completion of at least another US
N – Negotiable User Stories should be US is written with so much details to be US is written with so much details to be US is written with an informative US is written with an informative
"open" as much as a technical specification (Design phase), a functional specification (Analysis content defining a User Requirement in a content typical of a high-level need,
possible reporting not allowing to negotiate any element phase), not allowing a sufficient consolidated manner, yet shared between allowing a series of feedbacks between
any relevant details negotiation Customer and Provider Customer and Provider
V - Valuable User Stories should give a US functional (F) side does not contain US functional (F) side expresses mostly US functional (F) side expresses mostly US functional (F) side correctly
value for end users of the functionalities requested from the qualitative (Q) and technical (T) functional requirements as requested by expresses only functional requirements
solution Customer requirements about the system, needs to the Customer, but includes also as requested by the Customer
be more developed on the ‘F’ side qualitative (Q) and technical (T)
requirements
E – Estimable Each User Story must be able US shows only its Functional (F) side US shows only its Functional (F) side US is complete for Q/T issues by the US shows all useful parts (F/Q/T)
to be estimated in terms filled by the Customer, but without filled by the Customer, but validated Provider, but needs to be validated allowing to size and estimate needed
of relative size and effort sufficient detailed level for allowing the with the Provider jointly with the Customer effort, validated by both parts
Provider filling the Q/T parts
S – Small Each User Story should be US has a very large size, and it can US has a very large size, and it can be US has a size allowing to be completed US has a size allowing to be completed
sufficiently granular, not be completed within a Sprint completed within a Sprint, but it cannot within a Sprint, jointly with other US, within a Sprint, jointly with other US,
not too high-level defined allow to create/deliver other US but it’s so small to create an overhead assuring a proper balancing between
about the Testing phase development and testing activities
T – Testable Each User Story must US does not include tips about US includes formal US includes indication of US includes indication of
be formulated trying to stress Acceptance Tests indication on Acceptance Acceptance Tests, complete, yet to be Acceptance Tests, complete and already
useful details for creating tests Tests, still to be completed validated validated
• Evaluate Requirements – The INVEST Grid
 “INVEST” are six criteria from Mike Cohn for evaluating each US/US2
 The INVEST Grid (Buglione, 2007)
 Create your own definitions over an ordinal scale (e.g. 0-3 as in ISO/IEC 14598-x std)
 Fill cells as in a maturity model for each criterion
 Customer and Provider have to jointly evaluate the achieved level
 US/US2 will pass in production and be assigned to an iteration/Sprint only when the agreed
thresholds for the six criteria will be achieved
9 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione

10. Agile-4-FSM Piece #2 – NFRs
URL:
http://goo.gl/MIJZU
• NFRs – Non Functional Requirements
 NFR (IFPUG CPM v4.3.1) = Quality reqs + Technical Reqs (IFPUG CPM v4.2.1)
 Quality Reqs = “any requirements relating to software quality as defined in ISO 9126:1991”
 Tech Reqs = “requirements relating to the technology and environment, for the development,
maintenance, support and execution of the software”
 Non-Functional Reqs = “a software requirement that describes not what the software will
do but how the software will do it’
 ...SNAP (IFPUG Software Non-functional Assessment Process)
10 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione

11. Agile-4-FSM Piece #2 – NFRs
IFPUG CPM v4.3.1 (excerpts)
page 1-2: IFPUG Strategic Decision: "IFPUG’s method for function point
analysis is an ISO standard and must be conformant to ISO/IEC
14143-1:2007. The method can measure “functional size” only and
not “non-functional size”. This does not mean that the
nonfunctional size cannot, or should not, be measured, only that it
must be clearly stated as a separate measure (“A Framework
for Functional Sizing” [IFPUG, 2003]).”
page 4-20: "This maintenance includes a wide range of activities that are
performed during this phase of the application life cycle, some of
which involve functional changes that are applicable to FPA” (thus,
not all types of mainteinance)
page 4-21: Mainteinance requests: "Regardless of duration or level of
work effort required, it is the type of activity that determines how the
work is classified. Function Point Analysis should not be used
to size perfective or corrective maintenance work”
Source::
ITPC, Software Non-functional Assessment Process (SNAP) – Assessment Practice Manual (APM), v1.0, September 2011
ITPC webpage: http://ifpug.org/about/ITperformance.htm
11 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione

12. Agile-4-FSM Piece #2 – NFRs (SNAP)
 NFR unit of measure: SNAP Points (SP)
 Counting base: SCU (SNAP Counting Unit)
 4 categories and 17 sub-categories
o C1 – Data Operations (5 sc)
o C2 – Interface Design (4 sc)
o C3 – Technical Environment (4 sc)
o C4 – Architecture (3 sc)
 3 parts in the APM
o 1 – The method
o 2 – Examples
o 3 - Annexes
 Update: H1/2012
Source::
ITPC, Software Non-functional Assessment Process (SNAP) – Assessment Practice Manual (APM), v1.0, September 2011
ITPC webpage: http://ifpug.org/about/ITperformance.htm
12 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione

13. Agile-4-FSM Piece #3 – Size Measures
URL:
http://goo.gl/Qls7B
URL:
http://goo.gl/4UCht
• Size Measures
 Agile methods (ASD, APM) typically use time-based measures for estimating (Story
Points, Velocity, ...) and have not a standard definition for being consistently applied
 No/Few historical data also for using analogy estimates
 But the estimation logical chain is...
 Q (quantity)  T (Time: Effort  Duration)  C (Costs)
 FUR can be sized with a FSM method, but facing the requirement granularity issue
 FUR is only one side of the ‘story’
 ‘Functionalize’ NFRs  e.g. http://goo.gl/AWZjU
 Again, not all iterations/Sprints are the same, they plan and release differently
13 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione

14. Agile-4-FSM Piece #4 – Estimating & Planning
Sprint #1 Sprint #2 Sprint #3 Sprint #4
• Estimating & Planning
 Each iteration/Sprint can be managed as a ‘project’ (or a ‘sub-project’) because it has
different characteristics
 Not all iterations/Sprints are the same, they need to be planned differently
 Type-1 and Type-2 US2 are placed differently within iterations  use different
productivity levels according to the different balancing of FUR vs NFR related effort
 Nominal productivity’ (FP/Effort)  www.semq.eu/pdf/fsm-prod.pdf
14 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione

15. Agile-4-FSM Piece #4 – Estimating & Planning
• Splitting effort...
 Separate approx FUR vs
NFR-related efforts
 Increased R2 values
 Refine your own effort
data gathering
introducing some more
filters (e.g. # of layers
and/or peer components
measured)
 Start using SNAP and/or
other NFR-related
approaches!
15 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione

16. Agile-4-FSM Conclusions & Perspectives
• Agile & Requirements
 FURs represent a large part of User Stories, but not the whole
 NFRs need to be properly represented also in Agile environments, because the effort they take
 US2 is a simple way to start writing them and the INVEST grid could be a way to improve agile
planning, matching common-sense and a more quantitative view
• Agile & Sizing measures
 “Q T  C” is the common-sense, logical chain to be followed and ‘Quantity’ cannot be
skipped
 FSM methods can be easily applied to agile projects, many experiences yet ready and applicable
 ‘One size DOESN’T fits all’...Only FURs are not sufficient for representing the real PROJECT
effort
 Sizing NFRs is the next challenge  IFPUG SNAP is one possible way to start doing it!
 Agile & Estimating+Planning
 Classifying US2 in Type-1 and Type-2 can help in better allocating resources and schedule
iterations according to the distribution of FUR vs NFR-related effort
 Some lessons learned
 Agile is based on Experience  Experience means Data  Gather Data and share among the
organization
 Skill people on better eliciting requirements (e.g. CMMI-DEV RD process, ML3), separating FURs
and NFRs
 Share experiences and apply common definitions and levels of granularity across the several
agile project teams, overcomingis prerequisite for reliability
Simplicity the ‘Story Point’-syndrome...it’s about Simplicity!
(Edsger Dijkstra, Mathematician)
16 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione

17. Agile-4-FSM What is (should be) Agile?
17 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione

18. Agile-4-FSM Q&A
Grazie mille per l’attenzione!
Thanks for your attention!
18 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione

19. Agile-4-FSM Contacts
We care of your problems and we have in mind a solution
Luigi Buglione
Industry & Service Dept
Process Improvement & Measurement Specialist
Via R. Morandi 32 Tel. +39 - 06.8307.4472
00148 Roma Fax +39 - 06.8307.4200
Cell. +39 - 335.1214813
www.eng.it luigi.buglione@eng.it
19 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione