The measurement of change, the expected and the implemented, are best
expressed as numbers. The numbers might represent different aspects in different
situations; in different phases, sprints, pushes, periods or whatever you prefer
to call them. The number themselves are more important to the team, «For
philosophical reasons, I refuse to break the team into sub-atomic particles»
than external elements, and in more cases than not become the pivot around which
the development revolves and evolves. Much to our delight, these numbers seem to
be very important to managers and clients for obvious reasons, and both ends of
the river meet. Its such a nice place to live, this world ain’t it? Be
forewarned.
There are some numbers that I would decide upon, if I just
started developing a robust «lets hope» software product.
1. Features completed/ Feature backlog
Very basic metric.
Divide each iteration into a number of features. While developing, find out
whats the % age of work completed in terms of features. The one flavor that
really helps is the weighted %. Assuming all features are not equivalent, assign
a weightage to each feature. And then calculate the work done % age. This
becomes complex with the 2nd iteration when bugs start coming in. You need to
add bug fixes as features too. Some people call them «tasks», whatever.
2. Test cases failed %
Another important metric. In
subsequent iterations (to the first one), one might want to look at this metric
to know the quality of the development, the stress areas, and most importantly,
which module requires pair programming. One very important push monitoring this
metric should give is the urge to follow TDD to the core. And ofcourse a better
design and good distribution of features iteration-wise.
3. Velocity of development
This is a metric followed by
some people to track the expertise of the team, their proficiency to code. To
add another parameter here, I would like to add the proficiency to understand.
This makes it number of features ( x weightage preferably) / «time frame» per
developer. Definitely very helpful one the team chart.
4. Team meeting time and its effect
An XP team should
meet. Meetings are called with a goal in mind. Without discussing the types of
meetings, it must be noted that one has to find out the effect of such meetings,
on the overall or iteration-wide goal. The time spent on each meeting must be
recorded, and its effect «if there is one expected» should be measured using one
of those numbers above.
5. Number of change requests
Change requests
are one of the bitter truths of programming. To measure these is again an
important decision. Considering them as features is another. But thats not the
point. This metric is essential to note down the requirement gathering design
issues involved. Another product of this metric is to keep the team updated with
their mistakes «if any» .
6. Time spent on change requests
The time spent on
change requests is another important metric, which highlights the design issues,
extensibility factor. Noormally a good design should allow a speedy recovery
path, for all such requests.
There are other
mainstream metrics, that accompany the Agile RUP process which might be useful.
One must not forget that keeping a chart, and updating it with the current
metrics is the most important part of a development process. Ultimately, passers
by should feel the enthusiasm and excellence of a team just by looking at the
chart. It should be something the team must be proud of.