Difference between revisions of "IS480 Team wiki: 2016T2 LickiLicky Final Wiki"
Line 317: | Line 317: | ||
<b>Dan Dan Thio</b> | <b>Dan Dan Thio</b> | ||
!style="background: white; text-align: left; font-weight: normal"| | !style="background: white; text-align: left; font-weight: normal"| | ||
− | Managing stakeholders' expectations was a challenge, and due to the lack of experience and ignorance, we made the poor decision of developing full features before proper validation. Our target market was initiately set too wide and that gave us the illusion of making progress, and when we narrowed it down, some developed features were not as applicable. The lack of quantitative goals and metrics to guide our development were things that we quickly picked up after mid-terms. Making sense of users' feedback was time-consuming and difficult, however, it definitely gave us direction. Unfortunately, there was little time left to recover. I've learnt that the devil's in the details, and the search for product market fit as a startup is tough as hell. If I | + | Managing stakeholders' expectations was a challenge, and due to the lack of experience and ignorance, we made the poor decision of developing full features before proper validation. Our target market was initiately set too wide and that gave us the illusion of making progress, and when we narrowed it down, some developed features were not as applicable. The lack of quantitative goals and metrics to guide our development were things that we quickly picked up after mid-terms. Making sense of users' feedback was time-consuming and difficult, however, it definitely gave us direction. Unfortunately, there was little time left to recover. I've learnt that the devil's in the details, and the search for product market fit as a startup is tough as hell. If I am to do it over again, I would have slapped myself and defined my target market smaller, collect quantative data, and make development decisions based on metrics from the onset. |
|- | |- | ||
|[[Image:LickiLicky_stanley.png|90px]]<br> | |[[Image:LickiLicky_stanley.png|90px]]<br> |
Revision as of 22:49, 9 April 2016
HOME | ABOUT US | PROJECT OVERVIEW | PROJECT MANAGEMENT | DOCUMENTATION |
Main Wiki | Midterm Wiki | Final Wiki |
---|
Project Progress Summary
Finals Slides: Coming Soon
Current Iteration: 15
Total Iterations: 16
Iteration (Current) Dates: 2 April 2016 to 15 April 2016
Iteration (Final) Dates: 16 April 2016 to 22 April 2016
Project Highlights
- Successful deployment in Google Play Store. Download Tictacts at https://play.google.com/store/apps/details?id=lickilicky.app.android.contacts&hl=en
- 5 user testing conducted. User Test 4 and 5 conducted with actual users (financial consultant).
- User Test 4 and 5 allows the team to gain insights about the market, users' needs and wants.
- User Test 4 and 5 allows the team to validate application idea with target market.
Project Challenges
- Difficult to reach out to actual users who has Android devices, with Android version 5.0 and above.
- Lack of standardise as-is process or working tools makes it challenging for team to identify market pain points.
Project Achievements
- Application features and idea validated with target market.
- Gaining insights on which features are preferred by financial consultants.
Project Management
Project Scope
Scope Change
- As the team shifted our focus on user testing and market validation, the originally scheduled function, cloud backup was removed from iteration 13 and shifted to the Good to Have category.
- Suggest Group (Related Field) is shifted to Good to Have as UT2 and 3 result shows that this function is not highly rated.
Project Timeline
Planned |
---|
Actual |
---|
Schedule Highlight
- UT 4 and 5 were scheduled to be conducted on Iteration 13 and 14 respectively
- Cloud backup and visualisation of statistic was removed from iteration 13 and 14 respectively
Project Metrics
Schedule Metrics
Iteration | Planned Duration (Days) | Actual Duration (Days) | Schedule Metric Score | Action Taken | Status |
---|---|---|---|---|---|
3 | 14 | 16 | 0.88 | More time needed to complete suggest group function. Follow up action: Schedule slip was presented during Acceptance presentation. No delay to overall schedule as there are no major function to be developed in Iteration 4, which was scheduled to be preparation for Acceptance. Supervisor was informed of the slip after project was Accepted. |
Completed |
7 | 14 | 16 | 0.88 | More time needed to develop filter search function. Follow up action: Supervisor informed about delay. More hours was put into developing the function. No major delay in overall schedule. |
Completed |
11 | 14 | 17 | 0.82 | More time needed to develop Hashtags. Follow up action: Supervisor informed about delay. More hours was put into developing the functions. No major delay in overall schedule. |
Completed |
View our Schedule Metrics Here!
Bug Metrics
Iteration | Bug Count | Bug Summary | Action Taken |
---|---|---|---|
5 | 12 7 Low 3 High 2 Critical |
A major regression testing was perform after acceptance which causes the spike in bug count. The 2 critical bugs are "new contacts added not reflected under suggest group" and "reminders and notes not backup upon app updates". | Resolve bugs immediately. No major delay was caused as iteration 5 was scheduled for post acceptance debugging. |
6 | 9 5 Low 3 High 1 Critical |
1 critical bug was due to app crash when reminder was set for a non-existing group and there is a notification for this reminder. | Resolve bugs immediately. No major delay was caused as iteration 6 was scheduled for post acceptance debugging. |
8 | 2 2 High |
2 high bugs were "expired reminders continue to remain in reminder list" and "recurring reminders did not take on new date/time" | Resolve bugs immediately. No major delay was caused as iteration 8 was scheduled for post acceptance debugging and development of only 1 function, birthday reminder. |
9 | 9 4 Low 5 High 0 Critical |
The spike in bug score (122) presented during midterm were bugs that were reported during User Test 2 combined with regression testing bugs. The above bug score for iteration 9 is base on regression testing. | Resolve bugs immediately. PM scheduled a "debugging (backlog)" task and allocated the Lead Developer to resolve these bugs (both UT and regression testing bugs) while the other 2 Backend Developers develop the functions that were scheduled for Iteration 9. |
10 | 6 4 High 2 Critical |
The critical bug was an app crash while performing a series of actions using Note 3. | Resolve bugs immediately. Critical bug did not occur again after new APK was released. Similar action was performed but bug did not replicate. |
11 | 9 1 Low 3 High 5 Critical |
The bug score presented during midterm were bugs that were reported during User Test 3 combined with regression testing bugs. The critical bugs were app crashed such as when user tried to upload video to his note, filter search caused app crashed searched for a wide range for age / income, and when user select the "call" option when a reminder notification was sent to the user but it was not assigned for any particular contact. | Resolve bugs immediately. PM scheduled a "debugging (backlog)" task prior to UT3 and allocated the Lead Developer to resolve them while having 2 Backend Developers to develop the remaining functions. The crashes did not occur during UT3. However, UT3 participants reported several UI bugs (low) which include keyboard blocking what user is typing, "attach" icon blocking their screen. |
12 | 21 6 Low 12 High 3 Critical |
To prevent the previous mistake that the team committed during the earlier UTs (crashes during UT), a more rigorous regression testing, performed with additional test cases, were conducted. The critical bugs were app crashed after selecting back button from link contacts, image deleted from gallery and thereafter reopen from notes caused app crashed, and app crashed after selecting back button from group view. | Resolve bugs immediately. No major delay was caused as there are no functions to be developed so developers can concentrate on debugging. Other bugs which will not affect UT given its scenario will be develop in next iterations. |
13 | 12 5 Low 7 High 0 Critical |
The remaining bugs were inherited from previous iteration. The bugs did not affect UT. | Resolve bugs immediately. No major delay was caused as there are no functions to be developed so developers can concentrate on debugging. Other bugs which will not affect UT given its scenario will be develop in next iterations. |
14 | 6 3 Low 3 High 0 Critical |
The remaining bugs were inherited from previous iteration. The bugs did not affect UT. | Resolve bugs immediately. No major delay was caused as there are no functions to be developed so developers can concentrate on debugging. Other bugs which will not affect UT given its scenario will be develop in next iterations. |
Project Risks
Risk Description | Category | Impact | Mitigation Strategy |
---|---|---|---|
Team is unfamiliar with android development. | Low | Project may be potentially delayed due to time spent on learning. Quality of product may be affected. | This risk has been lowered from High (during Midterm) to Low. The developers are now more familiar with android development. However, this remain as a risk. Developers will share their knowledge with each other whenever a problem arise. |
Mismatch of product against market. | High | Developed product may not be what our target users or anyone in the market wants. | The risk has been brought from Medium (during Midterm) to High. Although more UT and validation are done with actual users, we still do not have a holistic picture of the entire market. |
Quick rise of direct competition | High | Google can easily integrate its contacts app with notes (i.e. Google Keep), reminders (e.g. Google Tasks) and even calendars. | The risk has been brought from Medium (during Midterm) to High. We are targeting a niche market and the team has enhanced knowledge about the Singapore market (financial consultant) which also allow us to remain competitive. |
Technical Complexity
Quality of Product
Deliverables
Stage | Specification | Modules |
---|---|---|
Project Requirements | Market Research | Market Research |
Project Management | Minutes | Minutes |
Metrics | Schedule Metrics Task Metrics Bug Metrics | |
Risk | Risks | |
Change Management | Change Management | |
Diagrams | Class Diagram Workflow Model Logical Diagram |
Diagrams |
Design | Low-Fi Prototype High-Fi Prototype |
UI Prototype |
Testing | User Testing 1 | User Test 1 |
User Testing 2 | User Test 2 | |
User Testing 3 | User Test 3 | |
User Testing 4 | User Test 4 | |
User Testing 5 | User Test 5 |
Deployment
- Tictacts is deployed and available at https://play.google.com/store/apps/details?id=lickilicky.app.android.contacts&hl=en
- Visit us at http://www.tictacts.com/
User Testing
User Testing | Date | Venue | Users | Link |
---|---|---|---|---|
User Testing 1 | 30 Oct 2015 | SMU SIS GSR2.1 | 2 | User Testing 1 |
User Testing 2 | 6 Jan 2016 - 12 Jan 2016 | On-site at SMU SIS Lift Lobby Bench and off-site | 32 | User Testing 2 |
User Testing 3 | 11 Feb 2016 - 16 Feb 2016 | On-site at SMU SIS SR 2.1 / GSR 2.1 on 12 Feb 2016. Off-site for rest of the days | 28 | User Testing 3 |
User Testing 4 | 7 Mar 2016 - 16 Mar 2016 | Conducted at financial consultant most preferred place | 11 | User Testing 4 |
User Testing 5 | 19 Mar 2016 - 28 Mar 2016 | Conducted at financial consultant most preferred place | 11 | User Testing 5 |
Reflection
Team Reflection As a self-proposed IS480 project, we learned to make use of this opportunity to learn how to run a start-up - the importance of gathering insights from actual users, validating ideas and features, followed by developing an application that caters to market needs. By realising our individual strengths, we were able to complement our weaknesses, and given the guidance of our supervisor, mentor, and reviewers, the team developed synergy that lets us overcome obstacles.
Individual Reflection