Release tracking with YOXEL SW: Monitoring iteration progress

This is my 3rd post in the series on “agile product management with YOXEL SW”. The previous two posts were: Release planning with YOXEL SW: Starting a new release , and Release planning with YOXEL SW: Collaborative planning session .

After a successful planning session an iteration plan has been created and agreed upon by all release members, the implementation phase of our project/release/iteration has started.

Thorough planning is very important for the success of your project but that is not all. We all know that software development is not manufacturing but design work and usually things do not go exactly how you planned, you are designing and you are uncovering unforeseen challenges along the way. The important thing is to always have a clear picture of your project status, know if a problem has occurred, what its impact is, and be able to react promptly. By having a shorter term for your incremental release, by having done detailed prioritization of the tasks in the plan (down to the exact order 1,2,3,4,…), and by using estimates you have already tried to minimize your risks. The goal now is to stick to your short term plan and learn as you go.

I believe that being able to track and monitor your project/iteration health in real time, and collaborate pro actively is not less, or even more important than being able to create a good plan. By “real-time” I mean that any time a developer or a tester changes status of his/her request (fixed, % completeness, verified, more_info) the project status reflects that immediately (updates the project summary, re-computes timetables, re-generates charts). In most cases this is only possible when your project tracker is integrated with your request tracker. In our case, YOXEL SW is basically one system all together (release manager + request tracker), plus it can synchronize with your external web-based bug-tracker (Bugzilla/Mantis/GNATS/Jira/FogBugz/…).

One very useful capability is for the project tracker to be able to automatically re-compute its timetable for the remaining part of the project (for not completely implemented or tested requests). This allows you to predict when the project may be finishing.

Monitoring and reacting

Here is how you as a release member/owner could be using Yoxel’s release tracker:

1. Visit the implementation/testing phase progress panel regularly. For each release item (request/task) in the list Yoxel shows originally planned start and finish dates. Yoxel always compares planned start/finish dates vs. actual start/finish dates (when request status turned into ‘in_work’ and ‘fixed’) and highlights in red those items that do not behave as planned (work has not started yet as planned / work has not finished yet as planned).
2. For any release item highlighted in red take appropriate action to find out what is going on. Click on the item to get a detailed description of the request and check if the developer/tester has added any comments recently. Contact the developer/tester/manager directly or discuss these requests in an appropriate meeting. Unless the release priorities have changed you should try to stick with the original plan.
3. Check BurnDown chart to see if your project is constantly making progress. Yoxel draws an ‘accumulated-bars’ chart where for each day during your iteration you see a distribution of requests by states (10 open, 4 assigned, 3 in_work, 2 fixed, 1 verified, …). I know agile teams like this chart but I personally prefer our simple comparison table (see #1 above). Because Yoxel always compares the actual vs. planned dates you will detect immediately that there is a potential delay in your project. With the burndown chart it may take you a few days to notice a trend.
4. Check Gantts charts to see what Yoxel thinks of the project finish date. Is that acceptable? Once again, the timetable for unfinished requests is automatically recomputed based on current states of all requests (including % completeness), and you will see how certain gantts bars start sliding behind your deadline date if you experience delays with some requests in your queue.
5. Use release history log panel to collaborate with other release members on topics related to the project. Of cause direct personal interaction is always preferred, but it is still a good idea to capture the topics discussed live in this log so that other people (and distributed team members) could see what was going on.
6. At some point you may be in a situation when it is pretty clear that some of the requests can not meet your planned deadline. It is your judgment call whether to de-commit the remaining items or violate the release deadline. Most common practice is to continue release work until all ‘must have’ requests are done and de-commit the rest. This all depends on your methodology and your preferences, our release tracker allows you to do both.

Two-phase tracking

Yoxel allows you to track the release work over multiple execution phases. The default project template assumes two phase execution of your plan: ‘implementation’ and ‘testing/acceptance’. This means that release testing phase will start after implementation phase has finished (after 1st code freeze). This assumption should not worry you though because as a release member you can move the tracking to the testing phase any time you like. Such a two-phase approach is used to be a little more conservative during prediction of remaining release work. Many development teams do actually start system testing after their initial code freeze so it is better to plan and account for that.

So once your implementation is done (all requests are ‘fixed’ but not all are ‘verified’) or you have decided to start the testing phase anyway you can move to tracking your testing/acceptance phase. At this point your QA should get heavily involved unless they have not done that yet. The tracking progress panel will look the same, only the comparison of planned start/finish vs. actual start/finish dates will be for the testing work instead of implementation.

Iteration is done

Once your testing phase has finished (all requests are ‘fixed’ and ‘verified’) you will be able to officially finish the release and mark it as ‘done’. Yoxel will take you to a summary/statistics page where you should spend some time looking at the numbers that will help you learn and plan your next release better.

My next post will be dedicated to the summary/statistics page, what you can learn from your iterations and how you can use that knowledge to plan your next iteration better.