Version 3 (Current as at 17 APR 2013):
Project Schedule earlier versions:
The schedule will be complemented with the burn-down chart of each sprint, calculating the schedule ratio and adhering to the response actions of each ratio value.
= Remaining Time / Remaining Effort
= Number of hours that developer would spend * Days left in SPRINT * No. of Personnel Available
||Ahead of Schedule
||Redefine Sprint backlogs
|0.8 - 1.2
||Within healthy schedule range
||No actions required if ratio is about 1. Monitor tasks closely if ratio is below 1 and prepare to re-allocate the following tasks for the following sprint.
||Team is behind schedule
||Project Manager identifies the root cause and impact of the delay. Communicate with the team and client(if necessary). Set up more working meetings and discuss with lead developer for more pair-programming sessions.
Our Objective is to ensure the quality of our project through minimising the number of bugs present.
A bug is defined as an error/s in a line of code, resulting in an anomaly in the functioning of the application.
Refer to the Bug Metric Documentation.
= (2 X No. of low severity bugs) + (4 X No. of medium severity bugs) + (10 X No. of high severity bugs)
||Errors with page aesthetics. Feature/story can still work, but at a sub optimum level
||Errors that prevent an entire feature/story from working
||Errors that prevent more than 1 feature/story from working
|less than 6
||Developers resolve issues within the Sprint on their own accord
|7 - 9
||If bug is discovered in a feature that is not a core feature, Project Manager to schedule debugging during buffer.
|10 or more
||Developers attempt to resolve bug immediately. Project Manager to relieves member of his current task and set him in charge to resolve bug
Regression testing is any type of software testing that seeks to uncover new software bugs, or regressions, in existing functional and non-functional areas of a system after changes, such as enhancements, patches or configuration changes, have been made to them
The intent of regression testing is to ensure that a change such as those mentioned above has not introduced new faults. One of the main reasons for regression testing is to determine whether a change in one part of the software affects other parts of the software.
Team Chm uses regressive testing to ensure the quality of our product - Mobisupermarket, and each testing is done after each sprint as documented below;
||Level of Impact (out of 10)
||The estimation of story points by the team for each storyboard is not accurate, resulting in an inaccurate gauge of the planned sprint backlogs
||Schedule will be severely affected. Storyboards may have to be pushed back to the next iteration
||Project Manager to re-plan the resource and schedule allocation
||The developed product is not able to be installed like a plugin, as per requested by the client.
||Too much time spent on designing codes appropriately
||Lead developer to ensure that all committed codes adhere to stated guidelines & PM to ensure that schedule is kept to closely.
||Due to personal reasons, client Prof Shim may have to make short trips back to Korea
||Prof Shim may not be contactable at times when we have urgent matters
||Set up regular meeting time slot with the client
Email the client when we are not able to talk to her personally
||Project would take longer to complete due to learning curve
||Start learning technologies now and practice on dummy sites
||Business Rules such as creating of campiagns and designing of [hooks] do not adhere to marketing practices as we are unfamiliar with it
||Misunderstanding business rules resulting in an inaccurate result
||Meet up regularly with marketing professors and users testing
||Users may not know how to use the software the first time they use the application
||Users may have a difficult time adapting to the new software
||Have a soft copy of a user manual or incorporate a guide in the software to guide the users
||The steep learning curve for magento may prevent us from progressing according to our schedule
||Project would be difficult to integrate and code and thus take a longer time to complete
||Project Manager to schedule more time for Magento workshops and peer learning
||Go Daddy Server Fails
||Project cannot be deployed and thus take a longer time to complete
||Project Manager to obtain working copy from repository and redeploy
||Project Repository unavailable due to technical faults
||Project cannot continue
||Project team members to obtain last known working copy from teammates
||Lack of manpower because it is expected that Leonard is required to go over a competition (unable to predict as the dates are not confirmed yet)
||Productivity of the team may decrease
||Ensure that everyone stays healthy by planning sufficient rest time for the team
||As this is the first time the team members are working together, different working styles of the team members may clash with each other.
||Productivity of the team may be severely affected.
||Set common ground rules to ensure transparency amongst the team.
Have bonding time to understand more about each team member and strengthen the bonds within the team.
A Magento-based online e-commerce store, coupled with social media platforms (Facebook) that is developed along with an Business Intelligence (BI) tools application. This application allows marketing professionals and students to analyze the effectiveness of marketing strategies and campaigns being launched in the Magento e-commerce online store.
LARC would be able to use this application mainly as an education / learning tool for Singapore Management University (SMU) marketing majors students.
The project deliverables would be two-fold: a plug-in for the Magento eCommerce store, and the other is a Business Intelligence (BI) tool that will be developed on top of the existing Magento Admin
For more details about the project schedule, please click [here]
More details coming your way...
Project Management Framework
SCRUM is an iterative and flexible software development method for the management of software projects and product or application development.. The process is explained by the following flow chart and SCRUM terminology list. For a more visual description click here for a youtube video, otherwise the following describes the process;
1. Roles & Responsibilities
SCRUM process flow of events
- The Product Owner (Prof Kyong Jin Shim) is responsible for the business interest and value of the project.
- The SCRUM Master (Project Manager) takes charge of managing the product backlog and the team’s productivity.
- The team is a self-managed entity that ensures that the work gets completed.
2. Product Backlog
- The process is first triggered with a wish list of requirements drawn up by the product owner (Client).
3. Sprint Planning / Sprint Backlog
- Next, Team Chm pulls out a list of to-do items from the [product backlog] and places it in the sprint backlog.
- Each story of a sprint has an in charge, and he shall see through the development and testing of the story.
- He needs to update the status of the story in the product backlog.
- A sprint is a duration that the team takes to complete the tasks selected in the sprint backlog.
- Team Chm sprint duration is can vary from 4 to 27 days.
- Once the Sprint Backlog is up, the team scrambles to work on the sprint.
5. Weekly meetings
- Instead of having daily meetings as depicted in the original SCRUM process, Team Chm has a weekly SCRUM meeting instead to customise to its current needs.
The SCRUM process then repeats itself until the product backlog is cleared.
Further your knowledge of SCRUM via Scrum Alliance
, where Team Chm has referenced the contents of this section from.