Updated timelines for Omni Features

Sharing this document to inform that some of the features Omni team is working on are a little  behind schedule. We understand that as our customers you might have planned your future plans on these features in your Omni software. We apologize for the delay. 

In order to address these unforeseen circumstances, We have also taken some immediate actions and some planned some future actions so such delays can be avoided in future 

Please do not hesitate to contact the support team if you have any questions about the new timelines, any other details.

Team related reasons 

Campus Hiring 

Massive effort by the Development team and QA team went into campus hiring. In taking multiple online interviews, campus visits etc. Campus hiring got closed recently.

New development team

New Joinees of last year joined our dev team around July, team herachiry got changed. 

Senior SDE2 developers became leads, whose main responsibilities became planning and mentoring. 

New SDE-1 were assigned all the development tasks.

This sprint was the first ever sprint after training et 

This caused 4 inevitable effects as

1. Poor timeline estimation as new developers take more time learning the code base

2. More back and forth in Dev review, Strict-er code review in initial days. 

3. More time in QA, as more small small issues. And New QAs themselves. 

4. Difficulty in managing who is doing what, at what time. I.e Lesser visibility 

Specific feature related reasons

Multiple Units of Measure UOM and Handling, Eaches and Packs

Previously we had said that we will be able to deliver the UOM feature by ~mid of October. 

We have been working on the UOM feature since around August 6th. 

Reasons for delay

Poor Scoping on Bulk Break Part

Bulk break functionalities were not planned in depth when we communicated the timelines. Edge cases were not thrashed out for some scenarios like expiry etc. When we did that part of planning we realized that effort is a lot more than previously considered.

Major QA effort 

UOM feature has major changes in Inventory reservation workflow, we are adding new buckets and doing soft allocation to support bulk break.

This means all the flows involving these line items have to be done QA. Since inventory is involved, it's almost all the inwards, outwards, returns, inventory management etc.  

Expiry and Virtual combo has added a lot of complexity and also a lot of new cases, which are difficult to test. 

Immediate Actions

JIRA Roadmaps

We have Upgraded JIRA plan, now we have access to advanced Roadmaps feature. 

With Jira Advanced roadmaps we will be able to break large tasks into smaller chunks and assign dependencies. JIRA roadmaps will give us visibility of who is doing what and allow us to have better visibility over timelines.

We are now implementing the same for our current sprint itself. 

QA Data creation automation

Most of our time is spent in making the test cases data for each and every case. If we are able to automate this, we will be able to save about 40% to 50% time in QA. 

We are immediately starting to implement data creation automation at least (as a poc) for UOM QA so maybe then UOM over timeline will get early, if that is successful we will update with new timelines again. 

Future Actions

Team SOPs

With JIRA roadmaps in place, we will be creating new SOPs for the team on what all things to do for planning large features.

QA automation

We are moving towards full QA automation. One part of the QA team will only write new Automation test cases for new features and functionalities, the other part will just run the pre-defined scenarios for new features.

Updated Timelines