Improving feature estimation using scrum history data

Abstract

Agile software development companies react to the changes in their volatile business environment to satisfy customers to the best of their ability. Planning the releases of software versions, making promises to customers and deciding where to put resources are difficult tasks which require information about the current state of features and their estimated time of completion. Making schedules takes resources and is difficult because of the complex and changing environment. This research aims to identify problems of feature estimation in agile software development and discover solutions to these problems. The study was conducted as a qualitative case study for a Finnish agile software development company and the DSRM framework was used to provide guiding lines for the research. Information was gathered by reviewing the academic literature and interviewing the employees of the case company. An artifact which used the case company’s scrum history data as an input was created to improve feature estimation. The artifact was created in a form of a dashboard which displayed general information about the features currently being developed to the software product of the case company. The general information included for example name, responsible team, estimated completion date, completed percentage and the number of active developers. The estimated completion dates were calculated by using the company’s scrum history data and more specifically the user stories’ median cycle times. The results of the research provided identified problems regarding feature estimation in agile software development and a description how an artifact was made to solve these problems in the case company’s context. The performance of the artifact was evaluated comparing it to its requirements and by calculating average error of estimates. The accuracy of the estimates was on an acceptable level according to the case company and the artifact was seen beneficial. The transferability of the research and the generalization of the results is difficult because of the unique environment of the case company.

Ketteriä menetelmiä käyttävät ohjelmistoyritykset pyrkivät reagoimaan ailahtelevassa liiketoimintaympäristössä tapahtuviin muutoksiin voidakseen palvella asikaittaan parhaansa mukaan. Ohjelmistoversioiden julkaisemisen suunnittelu, asiakaslupausten pitäminen ja resurssien jakaminen ovat haastavia tehtäviä, jotka vaativat informaatiota toiminnallisuuksien tämänhetkisestä tilanteesta ja niiden arvioiduista valmistumisajankohdista. Aikataulujen tekeminen on myös haastavaa moniulotteisen ja muuttuvan liiketoimintaympäristön johdosta. Tämä tutkimus pyrkii tunnistamaan ongelmia, joita esiintyy ketterän ohjelmistokehityksen toiminnallisuuksien valmistumisarvioiden tekemisessä ja löytämään ratkaisuja näihin ongelmiin. Tutkimus toteutettiin kvalitatiivisena tapaustutkimuksena suomalaiseen ketteriä menetelmiä käyttävään ohjelmistoyritykseen. DSRM-viitekehystä käytettiin tutkimusprosessin vaiheiden määrittämiseen. Aineistoa kerättiin perehtymällä ketterään ohjelmistokehitykseen liittyviin akateemisten kirjoituksiin ja tekemällä teemahaastatteluita kohdeyrityksen henkilöstölle. Valmistumisarvioihin liittyvien ongelmien ratkaisemiseksi luotiin artefakti, joka hyödynsi kohdeyrityksen scrum historiadataa. Artefakti luotiin automaattisesti päivittyvän kojelaudan muotoon, joka esitti yleistä tietoa kohdeyrityksessä sillä hetkellä kehityksessä olevista toiminnallisuuksista. Esitettäviin tietoihin sisältyi esimerkiksi toiminnallisuuden nimi, kehitystiimi, arvioitu valmistumispäivä, valmiusprosentti ja aktiivisten kehittäjien määrä. Arvioidut valmistumispäivät laskettiin käyttämällä hyväksi kohdeyrityksen scrum historiadatasta löytyviä käyttäjätarinoiden mediaani läpimenoaikoja. Tutkimuksen päätelmiin sisältyi löydetyt ketterän ohjelmistokehityksen valmistumisarvioihin liittyvät ongelmat ja selvitys minkälainen artefakti rakennettiin korjaamaan näitä ongelmia kohdeyrityksen tapauksessa ja millä perustein. Artefaktin suorituskykyä mitattiin vertaamalla sen toiminnallisuutta kehitysvaiheessa luotuihin tavoitteisiin ja laskemalla valmistumisarvioiden keskimääräinen virhe. Keskimääräinen virhe oli kohdeyrityksen mielestä sopivalla tasolla, tavoitteet ja toiminnallisuus olivat linjassa ja kohdeyritys näki artefaktin hyödyllisenä heidän toiminnalleen. Tutkimuksen siirrettävyys toiseen kontekstiin ja tulosten yleistettävyys voi olla haastavaa johtuen kohdeyrityksen ominaisuuksista, jotka mahdollistivat tutkimuksen onnistumisen.