Estimation and testing

After more than a decade since Agile Manifesto was published there is a wide spread adoption of agile practices in software industry. Although it had been more prevalent in small and start up companies but in last 2-3 years even banks and big companies have been learning the agile ways. With this increase in agile popularity there is a surge in failures attributed to agile methodology. As part of a research it was established that how unsuccessful Agile has proven to be, the key points from the report are available here. But there are reason for these failures, a great article “How To Fail With Agile:” explains possible causes behind these failures and how teams can avoid these pit falls.
    Being a QA on various agile teams I have observed that even for successful agile projects, teams find it difficult to extend agile practices to the test/QA teams. These teams usually have their dev teams following agile but their QA team will still be in waterfall. The reason being, QAs are not able to catch up with the dev team and are lagging behind to cover up with automation and manual testing.
   One of the important reasons for this gap is the way teams do estimation. All agile teams follow story or feature estimation as part of their planning process. There are varied number of ways that one can do estimation which can represent either complexity or time. In scrum methodology estimation activity is called planning poker and usually the stories are estimated in fibonacci numbers series : 1, 2, 4, 8…. or they could be S, M, L, XL sizes. During iteration planning meetings (IPM) developers throw these numbers for a given story to get estimation. 


Leave a comment