Agile Story-Point Estimation: Is RAG a Better Way to Go?

Probleemstelling

In de Agile softwareontwikkeling is het schatten van de inspanning voor taken (vaak uitgedrukt in "Story Points" of SP) een cruciale activiteit tijdens sprintplanning. De huidige standaardmethode, "Planning Poker", is een consensusgebaseerde, handmatige techniek waarbij het team taken bespreekt en schattingen maakt. Hoewel dit waardevol is voor het delen van kennis, kent de methode aanzienlijke nadelen:

• Tijdsintensief: Het kan 5-10 minuten per taak duren, wat bij grote projecten (zoals de Linux Kernel) maanden kan duren.
• Menselijke bias: Schattingen kunnen beïnvloed worden door dominante persoonlijkheden, senioriteit of optimisme, wat leidt tot kostbare overschrijdingen of inefficiënt gebruik van middelen.
• Beperkte schaalbaarheid: Het is moeilijk om consistent te schalen over grote teams of projecten.

Er is behoefte aan geautomatiseerde oplossingen die historische data gebruiken om consistente en objectieve schattingen te bieden. Eerdere studies hebben zich gericht op machine learning (zoals TF-IDF, Deep-SE) of clustering, maar deze missen vaak interpretatievermogen of vertrouwen op projectspecifieke vocabulaires. Dit artikel onderzoekt of Retrieval-Augmented Generation (RAG) een betere aanpak biedt.

Methodologie

De auteurs hebben een RAG-framework ontworpen dat bestaat uit twee hoofdcomponenten: een Retriever en een Generator.

1. Data:

   • Gebruik gemaakt van het dataset van Tawosi et al., dat 31.960 taken bevat van 26 open-source projecten (na filtering 23 projecten overgehouden).
   • Strikte filtering toegepast: taken zonder beschrijving, niet-opgeloste taken, en taken met Story Points buiten de Fibonacci-reeks (0, 1, 2, 3, 5, 8, ...) zijn verwijderd.
   • De data is chronologisch gesplitst in een trainingsset (80%) en een testset (20%) om data-lekkage uit de toekomst te voorkomen.

2. Retriever (Zoekmodule):

   • Voor een nieuwe taak worden embeddings gegenereerd voor de titel en beschrijving.
   • Twee embedding-modellen werden getest: BAAI (bge-large-en-v1.5) en SBERT (all-mpnet-base-v2).
   • De module zoekt de top_k meest vergelijkbare historische taken op basis van cosinus-ähnelijkheid.
   • Variatie in parameters: top_k (aantal geretrieveerde taken: 2, 3, 4) en temperature (generatierandomness: 0, 0.1, 0.2, 0.3).

3. Generator (Generatiemodule):

   • Gebruik gemaakt van Llama-3.2-3B-Instruct.
   • De generator ontvangt de nieuwe taak samen met de top_k geretrieveerde vergelijkbare taken (inclusief hun titels, beschrijvingen en oorspronkelijke Story Points).
   • Door middel van prompt engineering wordt het model geïnstrueerd om een Story Point te schatten die past bij de Fibonacci-reeks, gebaseerd op de complexiteit van de referentietaken.

4. Evaluatie:

   • Prestaties gemeten via Mean Absolute Error (MAE) en Median Absolute Error (MdAE).
   • Vergelijking met vier bestaande baselines: TF-IDF, Deep-SE, LHC-SE en LHCtc-SE.
   • Statistische toetsing: Kruskal-Wallis test (voor projectgrootte en embedding-modellen) en Wilcoxon signed-rank test (voor vergelijking met baselines).

Belangrijkste Bijdragen

• Eerste studie naar RAG voor Story Point schatting: Het artikel introduceert een nieuwe aanpak die expliciete voorbeelden (titels en beschrijvingen) ophaalt om de generator te voeden, wat inzichtelijkheid biedt in de schattingslogica.
• Uitgebreide empirische evaluatie: Analyse van 23 open-source projecten, onderverdeeld in kleine, middelgrote en grote projecten.
• Parameter-optimalisatie: Onderzoek naar de invloed van top_k en temperature op de nauwkeurigheid, en of deze optimaal verschillen per projectgrootte.
• Vergelijking embedding-modellen: Een directe vergelijking tussen BAAI en SBERT in de context van RAG voor software-engineering taken.

Resultaten

De resultaten tonen aan dat de RAG-aanpak competitief is, maar geen statistisch significante overwinning boekt op de bestaande methoden:

1. Invloed van Parameters (RQ1):

   • De optimale instellingen voor top_k en temperature variëren per projectgrootte en embedding-model. Er is geen universeel optimale configuratie.
   • Bijvoorbeeld: Voor grote projecten met BAAI was top_k=4 en temperature=0 het beste, terwijl kleine projecten met SBERT top_k=4 en temperature=0.1 prefereerden.

2. Invloed van Projectgrootte (RQ2):

   • Er was geen statistisch significant verschil in prestaties (MAE) tussen kleine, middelgrote en grote projecten (Kruskal-Wallis test: p > 0.05).
   • Hoewel middelgrote projecten iets lagere gemiddelde MAE-waarden hadden, was de variantie in kleine projecten groot, wat suggereert dat de methode niet consistent beter of slechter presteert op basis van schaal.

3. Invloed van Embedding-model (RQ3):

   • Er was geen statistisch significant verschil tussen de prestaties van BAAI en SBERT (Wilcoxon test: p = 0.16). Beide modellen leverden vergelijkbare kwaliteit voor het ophalen van context.

4. Vergelijking met Baselines (RQ4):

   • De RAG-modellen presteerden op individuele projecten soms beter dan de baselines (bijvoorbeeld 7 keer beter dan LHC-SE bij kleine projecten met SBERT).
   • Echter, bij statistische toetsing over alle projecten heen was er geen significant verschil tussen de RAG-aanpak en de bestaande methoden (TF-IDF, Deep-SE, etc.). De nullhypothese kon niet worden verworpen.

Betekenis en Conclusie

Het artikel concludeert dat RAG een haalbare en interpretabele methode is voor het automatiseren van Story Point schatting, maar dat het op dit moment geen statistisch superieure nauwkeurigheid biedt ten opzichte van gevestigde machine learning-methoden.

• Interpretatievermogen: Het grootste voordeel van RAG is dat developers de bron van de schatting kunnen zien (de geretrieveerde vergelijkbare taken), wat het vertrouwen in het systeem vergroot en het fungeert als een uitstekend beslissingsondersteunend hulpmiddel tijdens planningssessies.
• Beperkingen: Het volledig verwijderen van menselijke oordeelsvorming lijkt de prestaties te beperken voor numerieke schattingsopgaven. De huidige modellen missen mogelijk de nuance van menselijke ervaring.
• Toekomstperspectief: Verdere verbetering vereist mogelijk het opschonen van datasets (minder ruis), het fine-tunen van de generator op project-specifieke data, en het testen in industriële omgevingen met minder bias dan open-source projecten.

Samenvattend: RAG is een veelbelovende richting voor transparante schattingen, maar het is nog geen "beter" alternatief in termen van puur numerieke nauwkeurigheid vergeleken met de huidige state-of-the-art methoden.