Agile-4-FSM - Improving estimates by a 4-pieces puzzle

1,247 views
1,203 views

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,247
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
16
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Agile-4-FSM - Improving estimates by a 4-pieces puzzle

  1. 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. 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. 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 estimates3 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
  4. 4. Introduction Some initial questions...Why does it seem so difficult to apply FSM methodsto Agile projects? What about the maturity of my organization in the ‘sizing & estimation’ process?What about NFRs? Do they need to be sized andmanaged? 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. 5. Agile-4-FSM Some pieces of the puzzle... 2. NFRs 1. Requirements 3. Size Measures 4. Estimating & Planning5 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
  6. 6. Agile-4-FSM Piece #1 – Requirements (US – User Stories) US Title Implementation Priority RelativeFunctional 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. 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. 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. 9. Agile-4-FSM Piece #1 – Requirements (INVEST) 0 1 2 3INVEST Description Poor /Absent Fair Good ExcellentI -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 USN – 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 ProviderV - 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) requirementsE – 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 partsS – 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 activitiesT – 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. 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. 11. Agile-4-FSM Piece #2 – NFRsIFPUG 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 2011ITPC webpage: http://ifpug.org/about/ITperformance.htm 11 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
  12. 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/2012Source::ITPC, Software Non-functional Assessment Process (SNAP) – Assessment Practice Manual (APM), v1.0, September 2011ITPC webpage: http://ifpug.org/about/ITperformance.htm 12 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
  13. 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 differently13 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
  14. 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.pdf14 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
  15. 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. 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. 17. Agile-4-FSM What is (should be) Agile?17 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione
  18. 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. 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.it19 IFPUG Agile IG – May 17, 2012 – © 2012 L.Buglione

×