improving the user story agile technique using the invest criteria

1. 23 International Workshop on Software Measurement (IWSM) and 8th International Conference on Software Process and Product Measurement (MENSURA) Ankara (Turkey) - October 23-25, 2013 Improving the User Story Agile Technique Using the INVEST Criteria Luigi Buglione Alain Abran www.eng.it

2. INVEST Grid Goals of the presentation 1. Discuss the estimation issue as typically dealt with in the Agile Project Management (APM) context 2. Introduce Mike Cohns 6 INVEST criteria for evaluating a User Story (US) 3. Propose a refinement the INVEST Grid for a more quantitative evaluation, to better balance the set of US within a Sprint 2 IWSM-MENSURA 2013 October 23-25, 2013 2013 Luigi Buglione & Alain Abran www.eng.it

3. ETS - GELOG At a glance gelog.etsmtl.ca gelog.etsmtl.ca 3 IWSM-MENSURA 2013 October 23-25, 2013 2013 Luigi Buglione & Alain Abran www.eng.it

4. Engineering At a glance www.eng.it www.eng.it 4 IWSM-MENSURA 2013 October 23-25, 2013 2013 Luigi Buglione & Alain Abran www.eng.it

5. INVEST Grid Introduction Agenda Key Issues: The Agile Manifesto (15 years later) Some basic questions 1. Sizing Units 2. Historical Data 3. Requirements INVEST: Grid & Process Lessons Learned from Experience Conclusions & Future Works Q&A 5 The INVEST Grid The INVEST Process Definitions, Level of granularity Estimation by experience/analogy, Limited attention to test coverage Agile Project Management (APM) concepts IWSM-MENSURA 2013 October 23-25, 2013 2013 Luigi Buglione & Alain Abran www.eng.it

6. A bit of humour URL : http://www.enagility.com Introduction 6 IWSM-MENSURA 2013 October 23-25, 2013 2013 Luigi Buglione & Alain Abran www.eng.it

7. Introduction The Agile Manifesto (15 years later...) agilemanifesto.org agilemanifesto.org http://goo.gl/3p6ky0 http://goo.gl/3p6ky0 7 IWSM-MENSURA 2013 October 23-25, 2013 2013 Luigi Buglione & Alain Abran www.eng.it

8. Introduction Some basic questions... Are agile estimates based on objective assumptions (e.g. sizing units)? Are such estimates feasible and repeatable? How are requirements managed and validated? Which best practices are in place? Which standards? Source : Buglione L. & Abran A., Improving Estimations in Agile Projects: issues and avenues, Proceedings of the 4th Software Measurement European Forum (SMEF 2007), Rome (Italy), May 9-11 2007, ISBN 9-788870-909425, pp.265-274, URL: http://www.dpo.it/smef2007/papers/day2/212.pdf 8 IWSM-MENSURA 2013 October 23-25, 2013 2013 Luigi Buglione & Alain Abran www.eng.it

9. INVEST Grid Introduction Agenda Key Issues The Agile Manifesto (15 years later) Some basic questions 1. Sizing Units 2. Historical Data 3. Requirements INVEST: Grid & Process Some Lessons from Experience Conclusions & Future Works Q&A 9 The INVEST Grid The INVEST Process Definitions, Level of granularity Estimation by experience/analogy, Limited attention to test coverage Agile Project Management (APM) concepts IWSM-MENSURA 2013 October 23-25, 2013 2013 Luigi Buglione & Alain Abran www.eng.it

10. Key Issues Results from a Root-Cause Analysis (RCA)... The 3 main issues from a RCA to improve agile estimations... 1) Sizing Issues Story Points (SP): estabished locally & impacted by local conditions not repetable, they estimate the effort (not the size) for an US The typical logical chain is: Q T C 1. Determine the Quantity/ies according to attributes to be sized with their units sizing 1+ attributes 2. Based on history: determine Productivity (Q/T), possible to determine the working time (T), both as Effort (E) as well as Duration (D) 3. According to T (E, D) and knowing costs models (fixed+labour costs), possible to determine the project/activity Costs (C) 2) Historical Data In real life any estimation comes from historical data, even if not formalized (experience) Since ICT project should be in a middle way between real life and rocket science, why is it so hard to collect project historical data at the project closure phase? Workaround (while waiting to collect your own data) access an external repository, also for benchmarking purposes (e.g. ISBSG, PROMISE) 3) Requirements FUR + NFRs (see ISO 25010 for a product quality model) Need to analyze in depth NFRs: often hide a relevant amount of effort, not apparently visible to estimators or thought as implicit underestimation & litigation between parties, because of variance between estimates and actuals 10 IWSM-MENSURA 2013 October 23-25, 2013 2013 Luigi Buglione & Alain Abran www.eng.it

11. Introduction Key Issue Dealt with (all) Requirements US Title Implementation Priority Relative Productivity /Estimation Functional Test High Level FUR Functional Req (FUR) Non-functional Reqs (NFR) Org/Project related Reqs 11 IWSM-MENSURA 2013 October 23-25, 2013 2013 Luigi Buglione & Alain Abran www.eng.it

13. INVEST INVEST From the Criteria to the Grid Need for Evaluating Requirements in Agile contexts Make INVEST criteria more quantitative 13 INVEST: 6 criteria from Mike Cohn for evaluating each US, i.e. qualitative checklist before approving it in the Planning game between the Product Owner (customer rep.) & Scrum master (providers PM) I Independent N Negotiable V Valuable E Estimable Source : Cohn M. User Stories Applied: In Agile Software Development, Chapter 2: Writing Stories, Addison Wesley, 2004, URL: http://goo.gl/zN2jg S Small T - Testable The INVEST Grid next slide - tries to satisfy that need Create your own definitions over an ordinal scale (e.g. 0-3 as in ISO 14598) Fill cells as in a maturity model for each criterion Customer & Provider have to jointly evaluate the achieved level US will move into production & will be assigned to an iteration/Sprint only when the agreed thresholds for the 6 criteria will be achieved IWSM-MENSURA 2013 October 23-25, 2013 2013 Luigi Buglione & Alain Abran www.eng.it

14. INVEST The INVEST Grid 0 1 2 3 Poor /Absent Fair Good Excellent UserStoriesshouldbe asindependentas possible The startofconstruction of aUSistiedto thecompletion of at leastone other US The completion of a US hinders the start of construction of at least one other US The US is fully independent, and it can be realized and released with any constraint N Negotiable UserStoriesshouldbe "open", reporting any relevant details as much aspossible The US contains enough detail to be a technical specification (Design phase), leaving no room to negotiate any element The US is written with enough detail to be a functional specification (Analysis phase), leaving no room to negotiate any element V Valuable UserStoriesshouldpro vide valueto end users in terms of the solution The functional part (F) of the US does not contain all the functionalities requested by the customer E Estimable EachUser Storymust be able tobe estimatedin terms ofrelativesize andeffort S Small EachUser Storyshouldbe sufficiently granular,and not defined at toohigh a level The US shows only its functional (F) part, filled in by the customer, but without sufficient detail to allow the provider to fill in the Q/T parts The USis very large, and cannotbe completed withina Sprint The functional (F) part of the US expresses mostly qualitative (Q) and technical (T) requirements about the system, and needs to be more developed in terms of functional requirements The US shows only its functional (F) part, filled in by the customer, but validated with the provider The US can contain any constraint, but its release can be constrained by the completion of at least one other US The US is written with informative content defining a User Requirement in a consolidated manner, yet shared between Customer and Provider The functional (F) part of the US expresses mostly the functional requirements requested by the Customer, but also includes qualitative (Q) and technical (T) requirements The US has been completed by the provider with respect to Q/T issues, but still needs to be validated jointly with the customer The size of the US is such that it can be completed within a Sprint, jointly with other US, but it is too small to create overhead about the Testing phase INVEST Description I Independent T Testable 14 EachUser Storymust beformulatedin an effort to stress useful details for creatingtests The USdoes not includetips about AcceptanceTests The USis very large, and can be completed withina Sprint, but cannot accommodate the creation/delivery of other US The USincludesa formal indicationofAcceptance Tests,but yet to be completed The US is written with the informative content typical of a high-level need, allowing feedback between customer and provider The functional (F) part of the US correctly expresses only the functional requirements requested by the customer All the useful parts of the US (F/Q/T) are shown, allowing the effort need to size and estimate it, and validated by both parts The size of the US is such that it can be completed within a Sprint, jointly with other US, ensuring an appropriate balance between development and testing activities The USincludesan indicationof completed and validated AcceptanceTests The USincludesan indicationof AcceptanceTests which are complete,but yetto be validated Source : Buglione L., Meglio Agili o Veloci? Alcune riflessioni sulle stime nei progetti XP, XPM.it, February 2007, www.xpm.it IWSM-MENSURA 2013 October 23-25, 2013 2013 Luigi Buglione & Alain Abran www.eng.it

15. INVEST The INVEST Grid Target Profile (example) 0 1 2 3 Poor /Absent Fair Good Excellent UserStoriesshouldbe asindependentas possible The startofconstruction of aUSistiedto thecompletion of at leastone other US The completion of a US hinders the start of construction of at least one other US The US is fully independent, and it can be realized and released with any constraint N Negotiable UserStoriesshouldbe "open", reporting any relevant details as much aspossible The US contains enough detail to be a technical specification (Design phase), leaving no room to negotiate any element The US is written with enough detail to be a functional specification (Analysis phase), leaving no room to negotiate any element V Valuable UserStoriesshouldpro vide valueto end users in terms of the solution The functional part (F) of the US does not contain all the functionalities requested by the customer E Estimable EachUser Storymust be able tobe estimatedin terms ofrelativesize andeffort S Small EachUser Storyshouldbe sufficiently granular,and not defined at toohigh a level The US shows only its functional (F) part, filled in by the customer, but without sufficient detail to allow the provider to fill in the Q/T parts The USis very large, and cannotbe completed withina Sprint The functional (F) part of the US expresses mostly qualitative (Q) and technical (T) requirements about the system, and needs to be more developed in terms of functional requirements The US shows only its functional (F) part, filled in by the customer, but validated with the provider The US can contain any constraint, but its release can be constrained by the completion of at least one other US The US is written with informative content defining a User Requirement in a consolidated manner, yet shared between Customer and Provider The functional (F) part of the US expresses mostly the functional requirements requested by the Customer, but also includes qualitative (Q) and technical (T) requirements The US has been completed by the provider with respect to Q/T issues, but still needs to be validated jointly with the customer The size of the US is such that it can be completed within a Sprint, jointly with other US, but it is too small to create overhead about the Testing phase INVEST Description I Independent T Testable 15 EachUser Storymust beformulatedin an effort to stress useful details for creatingtests The USdoes not includetips about AcceptanceTests The USis very large, and can be completed withina Sprint, but cannot accommodate the creation/delivery of other US The USincludesa formal indicationofAcceptance Tests,but yet to be completed The US is written with the informative content typical of a high-level need, allowing feedback between customer and provider The functional (F) part of the US correctly expresses only the functional requirements requested by the customer All the useful parts of the US (F/Q/T) are shown, allowing the effort need to size and estimate it, and validated by both parts The size of the US is such that it can be completed within a Sprint, jointly with other US, ensuring an appropriate balance between development and testing activities The USincludesan indicationof completed and validated AcceptanceTests The USincludesan indicationof AcceptanceTests which are complete,but yetto be validated Source : Buglione L., Meglio Agili o Veloci? Alcune riflessioni sulle stime nei progetti XP, XPM.it, February 2007, www.xpm.it IWSM-MENSURA 2013 October 23-25, 2013 2013 Luigi Buglione & Alain Abran www.eng.it

16. INVEST The INVEST Process Not only the Grid, related Process but also a As for INVEST criteria - 6 steps: 1. Determine the US type some US could only be about NFR (beginning/end of iteration/Sprint) 2. Fill the FUR typical US elicitation 3. Fill/complete NFRs - (not all the needed details about NFRs could be present from the 1st version; e.g. ISO 25010) 4. Apply the INVEST Grid evaluate the whole US (FUR+NFR) with the 6 criteria but as in the grid 5. Ok or change FUR? Go/No-Go for closing the US writing and estimation 6. Allocate US to a Sprint if everything is OK, according to an agreed profile for the 6 criteria (0-3 values), US can be deployed 16 IWSM-MENSURA 2013 October 23-25, 2013 2013 Luigi Buglione & Alain Abran www.eng.it

18. Some lessons learned Experience Attention Points Definitions Level of granularity Estimation by experience/analogy Limited attention to proper test coverage vs requirements APM (Agile Project Management) concepts 18 Realignment of definitions of working items & NFR between customers/providers Impact on the Small criterion Be consistent in the way to define granularity e.g. elementary process Manage CRUD/CRUDL (Create-Read-Update-Delete-List) Impact on the Small criterion SP are not repeatable, because set up on local basis Experience + Analogy Risk to understimate some hidden reqs, in particular on the NFR side Need of historical project data each iteration/delivery could be a mini-project to be coordinated into a wider (high/level) project/program Attention to the Testable criterion goal: reduce the CONQ by introducing the proper number of test cases Look at the right/feasible test coverage threshold Burndown chart vs Earned Value (absolute) time tracking, not only the deliverable production/deployment as a progress criterion The INVEST Grid can help to rethink the Requirements Elicitation phase determine the right quantities to be produced and the related project schedule IWSM-MENSURA 2013 October 23-25, 2013 2013 Luigi Buglione & Alain Abran www.eng.it

20. INVEST Grid Conclusions & Future Works Agile Estimations Requirement Management & the INVEST Grid/Process Estimations in the typical Agile contexts: often based on qualitative approaches The introduction of techniques/approaches more quantitative-oriented could improve estimates, reducing the estimation error Need to maintain the known agile way, but introducing new ways than actual Requirements are key need to be complete from several viewpoints INVEST is a known acronym and series of 6 criteria for evaluating User Stories (US)...but it is still a quantitative way The INVEST Grid introduces the ISO 4-levels ordinal scale for rating each criteria determining a profile against an agreed predefined target goal: make US complete as much as possible but looking at more criteria at the same time The INVEST Process is a 6-step process giving guidance about the interplay between customer and provider for achieving the best possible combination of USs per iteration/sprint Next Steps Refine & tailor definitions across the 4 levels for the 6 INVEST criteria Obtain empirical feedback from various industry domains ...try & see! All models are wrong. Some models are useful. All models are wrong. Some models are useful. (George Box, Mathematician , , 1919-2013) (George Box, Mathematician 1919-2013) 20 IWSM-MENSURA 2013 October 23-25, 2013 2013 Luigi Buglione & Alain Abran www.eng.it

21. Lessons Learned... URL : www.dilbert.com INVEST Grid 21 IWSM-MENSURA 2013 October 23-25, 2013 2013 Luigi Buglione & Alain Abran www.eng.it

22. INVEST Grid Q&A lginiz iin teekkrler ! Thanks for your attention ! 22 IWSM-MENSURA 2013 October 23-25, 2013 2013 Luigi Buglione & Alain Abran www.eng.it

23. INVEST Grid Our Contact Data Luigi Buglione Engineering.IT/ET S Alain Abran ETS Montral [email protected] [email protected] 23 IWSM-MENSURA 2013 October 23-25, 2013 2013 Luigi Buglione & Alain Abran www.eng.it

improving the user story agile technique using the invest criteria

Technology