Release statistics with YOXEL SW: What can we learn?

May 30, 2007

For now this is my last post in the series on “agile product management with YOXEL SW”. The previous three posts were: Release planning with YOXEL SW: Starting a new release , Release planning with YOXEL SW: Collaborative planning session, and Release tracking with YOXEL SW: Monitoring iteration progress .

Agile approach is all about adapting, that is why you always see a short “baby step” (iteration / incremental phase of development) then a “feedback step” (analysis of your previous step and lessons learnt) and then again the next iteration with certain adjustments and re-factoring. The feedback step is extremely important. And essentially, incorporating the feedback into your product is the main reason for having short incremental cycles and “agile movement” in general.

One type of feedback is the customer feedback related to your product. You show your new product version to your customers, advisers, or your internal people representing customers, and they tell you what is good and what is bad, what they expect and what you missed. This process may change your current product requirements or generate new ones, and overall is driving the re-prioritization of your backlog which forms content for your next iteration. Your product manager will most probably be responsible for this process.

The other type of feedback is internal. The statistics gathered, after an iteration has been concluded, can be quite useful to understand capabilities and specifics of your team better. The knowledge can help you create a more realistic plan for the next release/iteration or make proper adjustments to your team. I believe that this is another responsibility of your product manager (may be secondary or indirect one but nevertheless quite significant) to study the statistics and learn your team capabilities. Actually over a course of a few iterations all members of your team should start getting better understanding of what amounts of work they can accomplish in one iteration (what agile methodologies call ‘team velocity’).

YOXEL SW generates a release summary page after you have finished your release implementation&testing phase. Besides some interesting statistics this summary page can also be useful for creating your release notes as it lists the following categories of requests:

  1. Originally planned and successfully implemented&tested
  2. Originally planned but uncommitted requests (could not implement or test)
  3. Unplanned requests that were implemented&tested during the period of the iteration (these are usually critical support requests or the ones that were closed in between iterations).

Besides the content related summary there are some numeric statistics (Key Performance Indicators ). Some of the statistics Yoxel gathers rely on the quality of your input so before you base your conclusions on them please have a quick sanity check. Here is a recommended way of using the statistics page:

  • Look through all originally scheduled requests. These are the ones for which your team members entered their estimates during planning phase. Examine ‘e/a’ columns, these are ‘estimated vs. actual hours‘. If possible make sure everyone has entered their actual numbers and they make sense (enter perfect work hours). As a manager you may override some of these.
  • For the items where estimated is very different from actual check with your developer/tester to understand why. That will be useful for the future projects.
  • Now, scroll to the bottom and examine per developer/tester statistics:
    1. planned/done – how many items were assigned to a person and how many he/she has done
    2. avg e/a hrs – on average how many hours per task he/she estimated and how long it actually took. This might help your members estimate better in the future.
    3. reported/total hrs – how many hours a developer/tester worked during the release. This might be useful in determining % of time your resource actually spent on planned project requests (we call this % ‘time share’) vs. other unplanned stuff. Reported numbers that are higher than total may indicate overtime work or incorrect reporting.
  • Examine those statistics averaged (over all developers/testers): planned/done, e/a hrs, reported/total hrs. Next time you are starting a new release in Yoxel you can drive the preliminary plan generator better with these.

Just to summarize, with these KPIs you can probably get a good idea of:

  • team velocity and planned vs. unplanned work load
  • individual performances
  • individual estimation tendencies

Then it is up to you to account for what you have learnt, during the next release planning session, and work with your team on improving performance, if required …

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: