Showing posts with label requirement log. Show all posts
Showing posts with label requirement log. Show all posts

Saturday, November 18, 2023

Agile Project Management - Requirement Log, Issue Log and Test Log

Post Index

2023-11-18


Agile Project Management

Requirement Log, Issue Log and Test Log

How to use make use of simple Excel log files 
to 
manage data analytic project



With the fast growing world, agile project management is very common nowadays and it has a lot of advantages over waterfall project management, in particular to data analytic project.  One of the apparent reasons is that data analytic project usually involves data exploration and data analysis which is not possible to define all requirements beforehand.  It, in fact, involves a number of try-and-error to understand the relationship of data and try to figure out patterns and methods that are useful for business users to find insights.  To make it simple, it would be easier to understand by the phase "seeing is believing", i.e. creating a mockup dashboard will win over a thousand words to describe the details.  Thus, in agile data analytic project, a number of sprints/cycles is in place to develop, to mockup, to revise, to enhance until the ultimate and desired dashboard is completed.  Unless, there are explicit requirements.  Usually, a time-box approach will be used.  More often, a rough estimation is proposed for initial requirements and based on the development sprints, more in-depth discussion will take place to finalize the dashboard.

However, how to manage the detail and discussion? In this article, I will share how I use the simple documents to keep track the status and details on this kind of agile data analytic project.  The documents include:

  • Requirement Log
  • Issue Log
  • Test Log

These are Excel documents for easy maintenance.  Definitely, the same concepts can be applied into project management application.  It depends on what is available in your organization.


Requirement Log 

Requirement log by its name is to log the requirements.  Its main purpose is to keep track of the discussion of requirements from initial high level discussion to detail on how to implement each charts in the dashboard.  It also includes the data mapping indicating the source table/view and field and description on how to derived new fields.

The requirement logs contains of two sheets:

  • Requirement Log - the detail and status of the requirement.
  • Screen Capture - to provide screen capture/pictures for requirement.
  • # - it is ID of the requirement.
  • Log Date - it is the date that the item is logged.
  • Raised By - it is who provides the requirement.
  • Follow up by - it is who to follow up the implementation of the requirement.
  • Last Follow Up Date - when this item has been last updated.
  • Priority - the priority to indicate the importance.
  • Status - New, In Progress, Pending Confirmation, Completed, etc, i.e. a status that can indicate the situation.
  • Description - the details of the requirement.
  • Remark - additional information to supplement the item.
  • Screen Capture - it is providing a reference number of the screen capture, e.g. #1

To highlight a bit on the description, it is in the format like below:


YYYY-MM-DD (Who logged)
Details


The description is accumulated.  Therefore, whenever, there is an update of the requirement or there is any discussion, it will be logged down in the description.  As a result, there is a very clear trace of the requirements.  And the requirement can be started very high level, e.g. a dashboard for support cases to use major KPI.  And this item can be Closed while it is further broken down into other items to continue the follow-up.  The description can simply reference to the # number to indicate the trace.  It looks simple but it also requires experience to wisely use this requirement log.



For the screen capture, normally, it is very difficult to put this into Excel because when there is a long description, it requires more space and it leads to the misposition of the screen capture and eventually mess up the entire document.  A wiser approach would be freely to put the screen capture into another sheet with a # number.  And when required, it can locate the screen capture.  When you try it out, you will find its beauty.



All items must be completed or closed before it can go into the testing/UAT stage.
In the requirement log, it also contains table and field, derived field as a requirement.  Here, I do not go into details of this as it is quite common to have a list fields to be used and how they will be renamed as business name.  But, it should be emphasized that it can add more sheets as a support of the requirements.  It aims at having a single truth of requirements.


Issue Log

Issue log is very similar to requirement log to have two sheets including issue log and screen capture.  It aims at tracking all the issues arise in the project.  The issue log contains the follow columns:

  • # - it is ID of the issue.
  • Log Date - it is the date that the issue is logged.
  • Raised By - who reports the issue.
  • Follow up by - who is following up the issue.
  • Last Follow Up Date - when this issue is last followed up.
  • Category - which area this issue is belonging to.
  • Status - New, In Progress, Resolved, etc, a status to indicate the progress.
  • Description - the details of the issue.  It has similar format to requirement log having date, who and details for each follow up.
  • Action - what actions have been done to fix the issue.  It has similar format to requirement log having date, who and details for each follow up.
  • Screen Capture -  it is providing a reference number of the screen capture, e.g. #1
To reduce the number of document, requirement log and issue log could be combined into a single document for easy management and follow-up.
All items in the issue log are required to be resolved before it can go into testing stage.


Test Log

Test log is also very similar to the requirement log but the details are focusing on the testing issues.  It contains the following columns:

  • # - it is ID of the testing issue.
  • Log Date - it is the date that the test issue is logged.
  • Raised By - it is who finds out the issue.
  • Follow up by - it is who to follow up the fix.
  • Last Follow Up Date - when this item has been last updated.
  • Description - the details of the issue.
  • Status - New, In Progress, Pending User Check, Pending Fix, Fixed, etc, i.e. a status that can indicate the situation.
  • Screen Capture - it is providing a reference number of the screen capture, e.g. #1

All items in the test log must be completed before it can start the migration process to production.


Conclusion

These three documents including requirement log, issue log and test log can already tackle majority of agile data analytic project.  This simple framework is still required experience on how to write the details in a meaningful way.  One rule of thumb is to bear in mind of MVP, i.e. minimal viable product.  In other words, it should not have redundant details.  All details should be neat and simple.  However, it depends on your understanding and how you can ignore the "noise" and irrelevancy.  I have been using this for a few years and working fine and there are a number of fellow also available to pick this up and continue this kind of neat and MVP approach.  Try this out and see if you can ride on the concepts for your data journey.





I hope you like the sharing.  Thank you for reading!  Drop me a message for discussion.