Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a A replicated study on agile team velocity in story and function points
Semelhante a A replicated study on agile team velocity in story and function points (20)
Último
Último (20)
A replicated study on agile team velocity in story and function points
- 1. A Replicated Study on Correlating Agile Team Velocity in Function and Story Points Hennie Huijgens Delft University of Technology and Goverdson The Netherlands
- 2. A Learning Cycle for Software Engineering Projects Project Estimate Project Control Project Close Benchmark & Analysis Measurement Repository
- 3. In 2013 we published a paper on Best-in-Class Software Releases
- 4. We focused at 26 software releases that outperformed in comparison with our measurement repository -100% 100% 300% 500% Cost / Duration Matrix 300% 200% 100% 0% -100% % Cost Deviation from Mean Cost over Time Bad Practice Good Practice Time over Cost % Duration Deviation from Mean
- 5. 14 Of these releases were counted in both Function Points and Story Points Period FP SP A Aug 11 22 - A Sep 11 26 - A Oct 11 49 - A Nov 11 31 - A Dec 11 47 - A Jan 12 16 - A Feb 12 14 26 A Mar 12 21 57 A Apr 12 13 75 A May 12 48 48 A Jun 12 41 29 A Jul 12 32 45 A Aug 12 55 27 Period FP SP B Aug 11 52 - B Sep 11 28 - B Oct 11 30 - B Nov 11 9 - B Dec 11 30 - B Jan 12 5 43 B Feb 12 18 35 B Mar 12 24 25 B Apr 12 20 51 B May 12 25 45 B Jun 12 41 21 B Jul 12 57 14 B Aug 12 10 -
- 6. Function Points versus Story Points Function Points (FP) Story Points (SP) FP is a Size Metric SP is an Effort Estimate Objective (ISO standard for Functional Size Measurement) Relative (e.g. Fibonacci sequence) FPs cover functionality only SPs covers both functionality and NFR’s
- 7. In 2011 a paper by a group of Brazilian researchers was published on a comparison between FPs and SPs • ‘It was also realized a statistical correlation between FP and SP using 2191 stories and 18 iterations in a Brazilian public agency. • The conclusion drawn from this study was that function points, in that particular case, could be related with the initial value of the Story Points (…)’ • ‘The result cannot be generalized, but it supports an idea that Product Size = Functional Size + Non-Functional Size + Environments Variables Size, Story Points = Function Points + Non- Functional Size + Environments Variables Size.’
- 8. A comparison of FPs versus SPs in both studies 900 800 700 600 500 400 300 200 100 0 0 20 40 60 80 100 120 140 160 180 Santana et al. Bank Data A Bank Data B Function Points Story Points Where Santana et al. concluded a strong positive linear relation between FPs and SPs, we found a moderate negative one. It appears too early to make generic claims on the relation between FPs and SPs; in fact FSM-theory seems to underpin that such a relationship is a spurious one.
- 9. ‘Can we compare FPs with SPs?’ • The results of our study support the often heard saying that SPs cannot be (or should not be) compared with functional size measurements such as FPs. • FPs are assumed to be objective functional size measurements, based on standardized guidelines. FPs cover functionality only. • SPs are at best reliable within the scope of one software development team; results cannot be compared with other teams or companies. SPs cover both functional and non-functional requirements.
- 10. ‘Okay, if we can’t compare them, which ones do we throw away?’ • None! You need both… • Use SPs to estimate the work to be done and for communication to the business. They are a great tool for developers to describe the effort of a feature or user story in comparison to another within the scope of a development team. • Use FPs to track progress in portfolio management and for benchmarking purposes. FPs are an industry standard with proper guidelines and can be used worldwide across companies.
- 11. Thank you Hennie Huijgens h.k.m.huijgens@tudelft.nl www.goverdson.com
Notas do Editor
- Together with many colleagues from several software companies I collected historic data from finalized software projects, and stored all this information in a measurement repository. And once every month or quarter we analyzed our data and looked for trends on a portfolio level or organization level. And we learned from the knowledge that we collected as an estimate for newly started projects.
- Besides my work as measurement expert I started off doing a PhD at Delft University of Technology, and we published a study on the IWSM-Mensura 2013 conference on 26 best-in-class software releases that we identified in our repository.
- These 26 releases outperformed in comparison with all other software projects in our repository. We found that they scored better than average for both cost and duration, ending up in the good practice quadrant of this matrix.
- There was something interesting in these projects that we did not use in our IWSM-Mensura paper. During the measurement period of the 26 software releases, performed by two teams on different, yet comparable software systems, a transition was made from waterfall to scrum as the delivery approach. Meaning that for both teams we had 7 releases measured in both function points and story points. And we’d liked to find out whether we could find any correlation between both size metrics.
- Comparison function points versus story points.
- Yet when starting up this study, I found that there was already another paper on this subject, published by a group of Brazilian researchers on the XP 2011 conference. This study included a comparison of function points and story points, showing that – however not to be generalized – a strong positive linear relation occurred between both metrics. The researchers even suggested that in future automated translation from function points to story points, or the other way around, might be thinkable. We decided to replicate this study with our data of the 14 best-in-class software releases.
- And however our data showed a moderate relation, we found no match with the Brazilian study. Where they reported a strong, positive linear relation, we found a moderate, negative linear one. We wrote things down in a paper and send it to WETSoM 2014. And then something interesting happened. We got a reply from the organizers that our paper was accepted, followed by 8 pages of peer review remarks, stating among other things that in fact a relationship between function points and story points is a spurious one. We dived again in the FSM-theory, and indeed we do have to agree we missed a point here.
- So, to summarize the outcome of our study; it supports the idea that story points cannot be (or should not be) compared to function points. Function points are objective, based on formal counting guidelines and they cover functionality only. Story points on the other hand are to be used within the scope of a software engineering team. They should not be used for comparison with other teams or even with other organizations.
- So to finalize; if comparison is not an option, why don’t we throw away one of them? And it is good to realize that this is happening in many software companies nowadays. Since many companies go agile, I see a trend to opt for story points – often considered as modern and fancy – and to get rid of function points, together with its old-fashioned measurement dinosaurs. However, keep in mind that we need both. In many companies story points prove to be a reliable and easy to use instrument to support the estimation process. Function points on the other hands, are a good source for quantified portfolio management and internal and external benchmarking.
- So, however both metrics might be from different planets, maybe next time when you hear measurement guys talking about all sorts of points, performance improvements, dashboards and so on, remember my colorful paintings about raga’s. And realize that the golden mean is always ‘that what’s creating passion’.