Bugs – An agilist’s dilemma

The question is - ‘Is it ok to size bugs and consider it like any other story while calculating capacity, When bugs would be planned for successive sprints?’

When I entered in to a team recently I found them not sizing their bugs. But I personally thought that bugs should be sized. 
Why because,

• ·Those bugs are of huge effort
• Then only we can identify the actual effort
• ·Then only we can identify the capacity
• ·Then only we can ensure if all our metrics related to effort, capacity and normalized capacity are correct.

However I am not a purist. An purist- Agilist working on offshore model? Laughingstock.

Still, there is a limit and degree for compromises. So, I investigated and understood the reason why they are not sizing bugs.

• ·They claim credit for stories which are having MINOR defects with the approval of PO.
• ·Any defects reported at last few days of sprint are moved to next sprint without sizing.
• ·Both PO and SM are in agreement with Team to fix the issues without credit.

But, what I noticed was, somehow the team had forgotten that such a conditional compromise is accepted only for MINOR, last minutes bugs.

I am still working with this team to ensure that efforts beyond a degree should be sized.

But, beyond which degree? That’s something the team to decide and the PO to be in agreement.

What if they won’t do this? Then they will never know their capacity and normalization

      Ideally, the team should strive to deliver without defects.

An elevator pitch..

I got another opportunity for an elevator pitch. I could see this senior executive was a man of illustrations. So I chose to give an illustration on the classic questions. Agile Vs Waterfall.
I said -Waterfall projects are like making a table and agile projects are like growing a tree and got his attention immediately. I continued. 
When you decide to make a table you would prepare a design on paper before going to homedepot to get timber, nails and paint. Then you would follow the design to make the table. You have lot of experience in table making. It is under your control. There is no scope for this to grow beyond your design. There is no risk involved in this implementation as you have done this earlier.
On other hand, you don’t have an exact design to grow a tree. You can plan on which tree, which location etc. But the growth and yield of the tree is not in your hand. All you can do is to provide fertile land and selected seed and water and sun light. The tree will adapt to the environment by reaching for sunlight or by shedding leaves. Growing is a new activity every time. Your plans may not be fully implemented during the tree growing process.
Making a table is inorganic and growing a tree is organic.
Creating Software is not like making a table. You don’t create the same software repeatedly. Since the environment is dynamic the requirements may change at any point of time; like growing a tree.
We continued to discuss outside the elevator as well..