A blog focused on Dynamics CRM aimed at project sponsors, users and non-technical administrators. Read three of my articles and if something is of interest, read more, otherwise check out some of the other excellent CRM blogs at https://community.dynamics.com/product/crm/b/default.aspx

Sunday, April 13, 2014

Treating Bug Management Like a Flow Problem

At the moment I am managing the bugs for a project. I am responsible for triaging the bugs, allocating them to the right resource and generally making sure they get attended to.

One interesting aspect of this process is trying to predict when the bugs will be completed. The issue reminds me of the flow problems I used to work on in my physics days.

The Physics of Bugs

The problem reminds me of a flow problem with sinks and sources. In this case our source is the inflow of new bugs and our sink is the bucket of closed bugs. The resolved state is like a leaky bucket with bugs flowing in from the active state and flowing out through a hole to the closed state.

The Maths of Flow Systems

Flow systems have rules of conservation. For us the rules are:

New bugs can only enter into the Active bucket

Bugs cannot be destroyed

All bugs eventually end up in the Closed bucket

Source and Sink Rates

Here are some mocked up data to see how we can apply our model to the bugs.

Date

Active

Resolved

Closed

Total

2014/03/17

25

11

6

42

2014/03/18

23

15

7

45

2014/03/20

21

18

7

46

2014/04/02

24

20

14

58

2014/04/04

22

25

16

63

2014/04/07

20

27

16

63

2014/04/09

11

34

20

65

2014/04/10

10

38

21

69

The data, in itself, is hard to gain insight from but the rates are a little more telling.

For us, we will look at the average flows over time. Firstly, the source and the sink rates.

Average Bug Creation Rate = (69-42)/24 = 1.125 bugs/day (source rate)

Average Close Rate = (21-6)/24 = 0.625 bugs/day (sink rate)

Here I have taken the difference in days, but you can also use ‘working days’ if this suits better.

This immediately tells us that bugs are being created faster than they are being closed. Therefore, if things remain the same, the bugs will never be finished. Let us revisit this a bit later.

Resolution Rate

All Active bugs must go to either Resolved or Closed so, with this information we can calculate the rate at which bugs are leaving the Active bucket i.e. the rate of Resolution

Rate of Leaving the Active Bucket = (59-17)/24 = 1.75 bugs/day

So we now have the

Rate of Bug Creation (1.125 bugs/day)

Rate of Resolution (1.75 bugs/day)

Rate of Closure (0.625 bugs/day)

What the Rates Tell Us

In the bug-fixing stage of a project, there is always pressure to get bugs closed. Often project payments are contingent on critical bugs being closed. Go-live dates put pressure on client and consultant alike to get the bug-fixing job finished.

Firstly, as we noted before, the Rate of Bug Creation is greater than the Rate of Closure. Bugs are flowing into the system faster than they are ending up in the Closed bucket. This means, if things continue as they are, there will always be Active and Resolved bugs in the system and they will continue to grow.

However, the Rate of Resolution is larger than the Rate of Bug Creation so the consultants are actioning the Active bugs but they are staying in the Resolved bucket with only a trickle into the Closed bucket. The consultants are doing what they can but the client is dragging the chain on closure. This is excellent information for a project manager to know, who may be negotiating the situation with the client or having to report to their bosses on why the project is getting delayed.

Conclusions

The model employed here is quite a simple one. For example, if the client does not accept a Resolution, the bug will return to Active, but it provides a foundation for analysing bugs through rates of change and gaining insights which otherwise may not be apparent. Other extensions of this model may be rates of change of the flow. For example, it is reasonable to expect the rate of bug creation to taper to zero as testers run out of things to test, that is, the rate of bug creation will decelerate over time. This can be calculated and fed into the model for greater accuracy.

See how you go and, if like above, you find out that there is more to the picture than too many bugs and not enough action, your team will thank you for it. Good luck.

About Me

I'm a Dynamics CRM Consultant based in Sydney, Australia. I've been working with CRM systems for over ten years and with Dynamics CRM since version 1.0 beta.
In October 2009 I was honored with the MVP award for CRM from Microsoft.
If you think you could use me, feel free to call me on +61 4 1134 8229 or email me on leon dot tribe at gmail.
Views expressed are my own.